We have had ticket ID 481: How to restart OSPF?

It is an upstream issue so I agree totally in closing as wonˋt fix

Shall I close it as won't fix, given the fact that it is an upstream issue. Anything build around it, is in my opinion just a kludge, unless we would go with a separate daemon which can check and re-establish connections if they fail. The danger is that vyos becomes then more a server than a router. As workaround, a cronjob could do that as well, either setting an option via cli (wg-heartbeat or so since keepalive is a wg option already), which drops a cronjob onto the box and checks the wg endpoint periodically, if it fails it just calls diable/enable and checks again for X times, before it sleeps for let's say 24hs or so. @kroy would something like acronjob help you? Could be also set as a @reboot job and once the traffic flows it kicks itself out. Just wanna throw out ideas here.

https://github.com/vyos/vyos-1x/commit/cf499f958423919264884e9f1c5c1b593fd9de0e next rolling will have it fixed.

They have been committed at the same time, while I was using the current version if ifconfig.py and new one was published.
https://github.com/vyos/vyos-1x/commit/c24eb48c54b562fe7f78cdda82f2e245e9ab8506

Reason for the break is a different commit:

FYI: https://git.zx2c4.com/wg-dynamic/about/docs/idea.md

The Linux kernel has embedded name resolution, maybe this can be added to WireGuard itself. Its better then we design a patch for it.

reverted the commit. I'm not sure if a daemon would be a good idea. Another option is to allow only IP's entered via cli or checking the name whenever wg is executed, resolve the name and send it to hostd to get it written to /etc/host. That would solve at least the issue at reboot and in most cases the correct IP should be in /etc/hosts.

@kroy just to be clear, i'm not against using dns as endpoint for wireguard.. i'm for it, because i have the same issue as you do, but what i'm against is the way to getting there. As the wireguard protocol does not support dns in it self using this method is a loosing game.. what i'm not against is writing a daemon that does the name resolution for you when it comes available.. and available could mean after 1sec, 1m, 1h or even longer after the system is booted.. this daemon also could do re-resolving when the peer is down and the dns has changed...

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.

https://github.com/vyos/vyatta-cfg-op-pppoe/commit/195a478b7d826ec7ff1652b99abc75d49161a882

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

Can you please clarify. What is Vif mode dialing and what has a vlan id to do with multiple physical lines? Does that mean your problem is solved?

Tested, if using Vif requires more physical lines, and switches can use Vif mode PPPoE dialing, using macvlan does not require additional equipment

@sunser Did you try: set interfaces ethernet eth1 vif <vlanid> ... already?

https://phabricator.vyos.net/T1635 needs to be done first

…or, indeed, it'd be great to be able to restart FRR and have it get a new config when this happened just now:

It seems like this isn't needed anymore, as the test was deleted: https://phabricator.vyos.net/rVYOSONEX6ac5271e93d06712f6e318d2f6b96280ae16f040

As VyOS 1.2 rolling and also the upcoming VyOS 1.3 will use OpenVPN 2.4 (b/c Debian Buster ships OpenVPN 2.4.7) the workaround should work for quiet some time! Thanks for pointing this out.

@alainlamar as you seem to be the VyOS Wireless expert, you know why we have VLAN support on it?

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

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

Been pretty busy lately, but ran a quick test tonight. Wireguard keys are properly moved in my VM.

https://github.com/vyos/vyos-1x/commit/9b55f7c7b9ecc49e6efe075ad24a54baff719e8e

https://github.com/vyos/vyos-1x/commit/6956bfe0620638adbad36f8cdf6d312884ba82ff
https://github.com/vyos/vyos-1x/commit/0c6faf26823fb984b3e0a77ee014e20661163e44

I've tested it and can't reproduce. There are a few issues in the debian files and autoreconf, but other than that everything seems to work just fine.