This is going to become more and more of a problem as wireguard adoption continues. Most major Wireguard VPN services provide a FQDN as their endpoint, not IP:

As for openvpn i dont know, but if the app itself does dns queries on connect it will work quite fint (as i think it does)

As i tried to say, this fix will only work in some scenarios, and this comes down to the implementation of the app were configuring. And to be clear, wireguard does NOT support dns, but the wg config utillity does. On execution time it reads the dns name and tries to resolve it once, and only once. When it fails things would not work.. this is the same with eg. Nhrp that works exactly the same.. using this has raise conditions with getting ip up and running and not only on the host file. We do not wait for dhcp to delegate an address or dns servers.. these could come many ms/sec after wireguard is configured.. this is even true in the case when you change the priority.. and the length of the config/execution time also comes in as an parameter in this raise condition.. so, if you ask me, revert the priority and instead create a dns daemon thing that could read the config and populate the entry when it has failed.

Shouldn‘t OpenVPN have a similar problem?

This should be reverted, as the change is breaking. After more testing, I found some problems due to things like static routing being applied before wireguard now. So the wireguard tunnel works, but in some cases any routing that shouldbe going over the tunnel does not work.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb or next rolling release should fix the issue.

Yep. Changing the priority fixes the issue completely

@kroy You can quickly test it via setting Priority to 999 in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireguard/node.def. It's currently 459. Let me know your results, please.

@runar This isn't a routing issue though.

Changing the priority will only change a portion of this. It.. could fix the situation there the user have static ip and a default route, but will not give effect when the user has dhcp or uses bgp el.. so my wote goes to not changing priorities on this. This is a loosing race as long as we dont have a daemon el. That manages the connections..

Could we raise WireGuard Priority to 999? So it is launched very late?

There is not really an up or down, there is only a verified handshake and the transferred bytes. If you haven't sent and received anything, the interface is in 'unknown' state in terms of wireguard, even if it's 'up' if you look via iproute2. All can could do it checking if the endpoint resolves and if it does, send a packet and see if the handshake completes.

Changing when the tunnel comes up isn’t an option? For whatever reason the tunnel comes up before DNS resolution works. Using a hostname when the system is running works perfectly

yes, you need to be either able to resolve your endpoints name or have it in /etc/hosts mapped. The name is being resolved (or tried) when the wg command configures the tunnel. There is unfortunately not too much I can do against, unless implementing a probe service or something like that ( could be as simple as ping).

PR #142

Guess? Wireguard coming up before vyos-hostsd?

\h is the short hostname, I thought we want to have the full one (\H)

Sorry for duplicate, after T1531 seems this feature broken.
Proposed solution: change for vbash PS1='${debian_chroot:+($debian_chroot)}\u@\H:\w\$ ' to PS1='${debian_chroot:+($debian_chroot)}\u@$(hostname -f):\w\$ '

Duplicate of T1310. It worked in 1.2.2 but its not working as expected in 1.2.3 after using vyos-hostsd

I have rebuilt the router and this appears to be working as expected now. Marking as resolved.

PR https://github.com/vyos/vyos-1x/pull/137, using vyos-hostsd-client instead of typical adding record to /etc/hosts

Symptoms which cause no configuration of the device after booting into 1.2:

PR to fix this: https://github.com/vyos/vyos-1x/pull/136

Also exist additional issue, if we add system static host-mapping all dhcp records will be erased.

Thanks for the contribution, Please use VyOS 1.3 tag as this won't be backported to crux easily

Pull request created: https://github.com/vyos/vyos-1x/pull/133

PR merged https://github.com/vyos/vyos-1x/pull/131

Please share a pre and post-commit config block for me for testing.

The loading error is caused by bridging a l2tpv3 interface, didn't see the cause at first because of the other errors. Since the bridge is now created at priority 470, and l2tpv3 is 800, when before an interface would be added to the bridge as it is created.

Pull request added: https://github.com/vyos/vyos-1x/pull/131

After adding the vif to bridge member interfaces, I get a config load error on boot. Running config, load, commit, works. Something to do with the order the configs get applied?

Just noticed bridge has a member interface parameter now. The vif bridge-group config was not migrated.

Thanks for testing.

@hagbard
In VyOS 1.2-rolling-201909190545 all work. Fixed. Thank's.

@sever I see that the new package hasn't been autobuild in our CI, I see to get that fixed. If you are in urgent need of the change, please build and install vyos-1x manually.

In release VyOS 1.2-rolling-201909180118 I dont see this command

Tomorrows rolling ISO will have the patch applied.
Please test and let me know how it goes.

@sever Issue found and working on a patch.

ifname  | called-sid |    calling-sid    |     ip      | ip6 | ip6-dp | rate-limit | state  |  uptime  |        sid       
----------+------------+-------------------+-------------+-----+--------+------------+--------+----------+------------------
 bond0.51 | bond0.51   | 08:00:27:82:43:ae | 192.168.0.2 |     |        |            | active | 00:01:03 | d060220ce77252a9

Auto creation of vlans failed.

@hagbard in first my message actual config for bond1 with client-subnet 10.3.0.0/23 and authentication mode "local".
I plan to use several vlan's for several services.
You use it without vlans.

everything works without issue as far a I see.

@sever Yeah, sorry about the typo. You need to define an IP pool and an authentication method if you are not using a RADIUS server for that.
(I have bond0 in my lab so you need to change that to bond1 if you copy).

@hagbard bond0 - is WAN interface without vlans/tags. For DHCP listening I use bond1 interface, not PPP.
A try man https://vyos.readthedocs.io/en/latest/services/ipoe-server.html

@sever Can you please try: set service pppoe-server interface bond0 vlan-id 55. And have a look into /var/log/messages what accel is reporting there once the dhcp reply arrives. I'm going to lab up your config and test as well.
Also you need to define an IP pool a client can get an IP address from.
https://vyos.readthedocs.io/en/latest/services/ipoe-server.html
(btw: show config comands gives you a nicer config overview)

In T1664#43564, @hagbard wrote:

@sever Can you please also share your pppoe-server config?

@sever Can you please also share your pppoe-server config?

In T1660#43438, @c-po wrote:

Please test again with the rolling release from 2019-09-14. Thanks for reporting the issue.

Please test again with the rolling release from 2019-09-14. Thanks for reporting the issue.

PR https://github.com/vyos/vyos-1x/pull/128

I think encapsulate the udp based traffic into tcp is more than counter productive and makes it an easy DoS target.

Actually somebody made a nifty websocket tunnel named wstunnel (similar to stunnel conceptually, but websockets is more natural for tunneling generic binary protocols thanks to webRTC...) that seems to work alright for Wireguard.

I was thinking some more along the lines of stunnel and wrapping wireguard that way but it would require additional packaging and integration on the vyos side. Luckily whatever outbound filtering is in place for this specific implementation seems to be relatively basic and limited to port blocking/whitelisting.