@zsdc How quickly needs that to be resolved? It requires quite some work on the backend for the cli.

Since it's not a wireguard issue rather then a network issue between both systems, I'll remove it from 1.2 and put it into 1.3 .

That information is not easily visible, never been according to the openvpn folks.

Do you see now the udp arriving on both sides?

Ye it works fine. How else would it be able to work before with same routers, same ips, same config ? I can also access services no problem on the remote site (reverse proxy) but not services on the local network on the remote site.

@Maltahl any news on the traffic via vlan?

The wg traffic from host1 never reaches host 2, therefore wireguard can't function. Suggested to investigate the infrastructure to see if the traffic leaves actually the premises. Will put the task on hold meanwhile.

@danhusan IPv6 should not be affected. Workaround for IPv4:

Tested it myself and can't find any issues.

No idea what that could be, it's for sure a config problem since many others use it as well as myself with no issue at all. Is there any way I can access your env?

Tried both and they solved the issue but same problem with the tunnel not going up is the same.
I tried regen keys on both ends. No dice.

Should be in the latest rolling or here: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-13_all.deb

@hagbard is the patch for the validator issue in latest rolling or do you have a .deb i can apply ? :)

The client status file information is quite different compared to the one from a server config, I couldn't find a way yet to retrieve the information for the table.

@thinkl33t Please test the latest rolling which has openvpn2.4 installed.

I am affected too by this issue.

Ok, so that issue has been corrected, I used the wrong validator. (https://github.com/vyos/vyos-1x/commit/1842fc9fdbcfa877e42714eaf620dff18ff9859c)

Hmm, that (the IP validation) was a different change which was working. I'll have a look.

In T1226#32490, @hagbard wrote:

All right, let me know if you need help.

• vyatta-webgui removed from vyos-world (https://github.com/vyos/vyos-world/commit/dc9588ad4b49cc8f122075a2b6fe748e2f31af9c)
• vyatta-webgui removed from vyos-build submodules (https://github.com/vyos/vyos-build/commit/730f30c45fb0c1e5f5cb7576c54798941980a9d1)

All right, let me know if you need help.

@zsdc i meant test with 1.2.0 :-)

@danhusan , you can send the configuration to support@vyos.io with the theme "Phabricator T1148". Also, please check if a remote side of BGP peering run in active or passive mode?

We are seeing this issue mostly on BGP routers with Internet Exchange connections because at a reboot we are hitting max-prefix limits with a lot of peers.
At this moment it is not possible to upgrade to latest 1.2.0, still running 1.1.8.

Will try to reinstall the baremetal router since it is the most inconsistant of the two routers. The virtual one works with other peers.

Small config, just 4 interfaces with IPv4 and IPv6 + some BGP config. I am running the VyOS instance in ESXi with some fairly modern hardware.
Unfortunately I cannot just reboot this device at will. If you provide your email I can send over the config.

@thinkl33t Can you please test?

@hagbard we need to remove all old stuff including lightttpd
we going to replace it with nginx as per T808

Hello @danhusan!
How big is your configuration at all? Can you provide depersonalized config? Which hardware or virtual machine using for VyOS? Can you provide full log of booting?
We can't confidently reproduce this bug. Looks like configuration can't load quickly enough or something like this.

Received the following commit error:

Hmm. That's weird, I tested some rolling releases and 1.2.0, directly connected and via 5 hops, I can't reproduce what you see. If your crypto is ok and you have the the interface up and running, there won't be an issue. I would also see way more bug tickets here. So , I still believe yoru setup is incorrect, however it's hard to say where it fails. If the wg interface has no incoming and outgoing traffic, it's most likely routing. If inside the wg interface traffic goes out but is not answered but received on the upstream interface, somet6hing is wrong with the crypto. In your sho interface output is shows that traffic is being sent, but nothing recveived, that means the traffic you receive on the WAN side can't be authenticated, so that is an crypto issue. Either the traffic can't be decrypted or there is no existing setup for this public key. If the public key fits, then you can always decrypt with with your private one.

In T1226#32251, @hagbard wrote:

@Maltahl That smells more like an issue with your key setup. The wg interface listens on any interface which is up and running. If the traffic inside the wg interface doesn't show anything, that means it can't decrypt the traffic with your private key.

@Maltahl That smells more like an issue with your key setup. The wg interface listens on any interface which is up and running. If the traffic inside the wg interface doesn't show anything, that means it can't decrypt the traffic with your private key.

Ah, I misread, my apologies. Let me try.

@ekim rephrased: remove the DHCP-interface option and only use and configure the local-address to 0.0.0.0.

@hagbard i have tried removing all firewall rules on both routers and checked that the wireguard module was running. i have also tried allowing all traffic and also allowed udp for the wireguard port when it arrived.

Tested the config above with in 1.2, no issues found. Not sure what it is yet, but it looks like that either the traffic doesn't really reach the destination (aka endpoint) or vice versa. Awaiting some show output to check the key config etc.

No. The configuration 'dhcp-interface' and 'local-address' are mutually exclusive , so attempting to commit a configuration with both results in a commit error.

Can you try without dhcp-interface and set 0.0.0.0 as local-address?

@Maltahl You can use any rolling, I made an enhancement yesterday to disable peers, but other than that the code hasn't been touched for a while. If the rolling release works, I need to have a look into 1.2.0. I tested with your config above and everything was working as expected, but I'm around today so feel free to ping me on slack in 1hr.