Page MenuHomeVyOS Platform

Split WireGuard endpoint into proper host and port nodes
Closed, ResolvedPublicFEATURE REQUEST


set interfaces wireguard wg0 peer foo endpoint ip:port

WireGuard is the only system that has both remote endpoint and port on the same node, this makes validation hard using outr standard validators.

CLI must be changed to have a unique remote and a unique port node - a migrator for this is required but it gives a better CLI experience

New syntax:

  • set interfaces wireguard wg0 peer foo address <ip-address>
  • set interfaces wireguard wg0 peer foo port <port>


Difficulty level
Normal (likely a few hours)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)
Issue type
Improvement (missing useful functionality)

Related Objects

Event Timeline

c-po changed the task status from Open to In progress.Apr 3 2020, 4:31 PM
c-po claimed this task.
c-po triaged this task as Normal priority.
c-po created this task.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Config syntax change (migratable).
c-po moved this task from In Progress to Finished on the VyOS 1.3 Equuleus board.

This change has removed the ability to specify a wireguard endpoint by hostname, rather than IP address. Is there an alternative resolution which maintains this ability?

Actually, specifying wireguard peer as a hostname only worked on initial setup. The reason for this is that the hostname is resolved only on initial startup of the wireguard tunnel. On boot the ip stack is not fully operational resulting in wireguard beeing unable to resolve hostnames. (But this avtually could depend of the execution time of the initialization scripts) .. a better alternative to this is to make a initialization script that is delay'd and then resolves the hostname and inserts the correct ip in wireguard when the router is fully booted. This could be created using a custom script called from the post-bootup script or something like that.

This breaks with standard configuration convention in Wireguard. Also, no documentation has been updated to reflect this breaking change.

The field descriptions in the CLI is also misleading at best, I would say it's wrong. You're not listening for anything, that would suggest you're binding to a specific interface or address. You're sending data/connecting to a specified ... endpoint.

I suggest that you either revert this entirely or at least patch it so that it's backwards compatible with endpoint.

@vagardx thank you for this rant.

We like constructive feedback but I can not agree. Why is breaking standard WireGuard configuration? Its simply a different representation. Also this is properly documented in the docs.

If something in the CLI helpers or Docs is missing, please feel free to submit a PR for improvement.

This breaks with common configuration patterns/naming in Wireguard. Nobody will know what you're talking about when you say address and port in this context. And the CLI helpers adds documentation that would lead you to believe you are listening for connections, see line 105 in nterface-definitions/

And from what I can tell the user is also able to set either the address or port, and then it will just silently drop the endpoint from the peer. If you need this for simplifying validation wouldn't it make more sense to make address and port inputs of endpoint, and also make both values required in order to commit and save?

cpo@LR1.wue3# commit
Both Wireguard port and address must be defined for peer "foo" if either one of them is set!

If one is configured so must be the other. What VyOS version are you using?

erkin set Issue type to Improvement (missing useful functionality).Aug 30 2021, 7:46 AM
erkin removed a subscriber: Active contributors.