Looks like it has changed already in ifconfig.py. Tested it successfully as well.
https://github.com/vyos/vyos-1x/commit/f5c04661e6c031baedb6092ecafee501cca7bc28#diff-def38e05f2ac1eb35139b37ec8d47338R1375

No problem, I had already made the change manually in the snmp.py file. Since then, the problem has not occurred.

I‘d simply override the set_state() function in derived WireGuard Class without that check. If more interface have this (possibly VXLAN) it could be added to baseclass with a flag that the particular code is not executed.

@cpo operstate will be unknown for wg interfaces, I think it's the only interface type having unknown. Anything else should be up or down, I think. I can re-implement with the wg class if that's better.
Let me know what you think, wg is working with no issues, so functionality isn't an issue here.

@bertleywjh wg state and link state is all is unfortunately all you will be able to see, plus like when was the last handshake and how many bytes were transfered. AFAIK there is no other way to see states of the handshake etc.

@hagbard

show interfaces wireguard wgN

This just shows general configuration info & link state.

@fvbrasileiro here you go: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201910102056-amd64.iso

@fvbrasileiro Yeah, we found that out too today, we are working on a solution already. Please be patient.

In T1705#44982, @hagbard wrote:

@fvbrasileiro Please test at your earliest convenience.

https://github.com/vyos/vyos-1x/commit/e45648cdd5a52569be7f3ac30473b0c7474a7894
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

Next rolling will have it: https://github.com/vyos/vyatta-op-quagga/commit/219265ae4c8886bb6997ffc79f34610d6e2ea2d0 or you can manually install from the source below, if it is an urgent matter.

The cli part for the routing suite is up for rewrite, json is only working because it's supported by frr and the cli doesn't filter it. I think getting show ip route tag 20 working shouldn't be a big deal, but I try to avoid to add too much to the cli, will make just the rewrite way harder.

@hagbard via a route-map for example. set policy route-map TAG rule 10 set tag 33

There were multiple complains about bgpd crashes, memory issues inthe forum. They used the workaround removing the tables from snmpd successfully.

@olofl How do you set the tag? via CLI?

I do not see this problem on a full table v4/v6 router with 2 cores 4 GB RAM. The question is why? Is removing the table a good idea? What was the state with 1.1.8?

@fvbrasileiro Please test at your earliest convenience.

I can confirm the issue. Actually it boils down to two individual ones.

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.

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.

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