Forgot to add version for both routers, sorry.

vals1me2dk

fma@vals1me2dk:~$ show ver
Version:          VyOS 1.2.0
Built by:         Sentrium S.L.
Built on:         Sun 27 Jan 2019 19:08 UTC
Build ID:         795d6338-c1ce-4ebb-992f-d064f5af9309

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  QEMU
Hardware model:   Standard PC (i440FX + PIIX, 1996)
Hardware S/N:     Unknown
Hardware UUID:    Unknown

Copyright:        VyOS maintainers and contributors

glos1ce1dk

fma@glos1ce1dk:~$ show ver
Version:          VyOS 1.2.0
Built by:         Sentrium S.L.
Built on:         Sun 27 Jan 2019 19:08 UTC
Build ID:         795d6338-c1ce-4ebb-992f-d064f5af9309

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  To be filled by O.E.M.
Hardware model:   To be filled by O.E.M.
Hardware S/N:     Unknown
Hardware UUID:    Unknown

Copyright:        VyOS maintainers and contributors

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

As you only have one peer inside each tunnel you also actually could set allowed-ip's to 0.0.0.0/0 on each side. We will not autogenerate routes based on the allowed ip's setting as is done with wg-quick on linux and android...

Also, what is the output of the 'show interface wireguard' commands?

In T1226#32008, @runar wrote:

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

That is not how wireguard works ? that is how ipsec and openvpn works.
The config is based on a working setup i had with vyos 1.2.0 rc4 so it is a regression bug or a complete protocol change.
It will work with these routes:

router 1 with 10.0.90.1/24 as IP on wg3
set protocols static interface-route 10.0.100.0/24 next-hop-interface wg3

router 2 with 10.0.100.1/24 as IP on wg3
set protocols static interface-route 10.0.90.0/24 next-hop-interface wg3
}

Output of show interface wireguard

router 1


fma@glos1ce1dk:~$ show inter wireg wg3
interface: wg3
  public key: secret
  private key: (hidden)
  listening port: 54321

peer: secret
  endpoint: 83.151.x.x:54321
  allowed ips: 172.20.1.0/24, 10.0.0.0/8
  transfer: 0 B received, 1.70 MiB sent


router 2

fma@vals1me2dk:~$ show inter wireg wg3
interface: wg3
  public key: secret
  private key: (hidden)
  listening port: 54321

peer: secret
  endpoint: 85.204.x.x:54321
  allowed ips: 172.20.1.0/24, 10.0.0.0/8
  transfer: 0 B received, 690.86 KiB sent

That is not how wireguard works ? that is how ipsec and openvpn works.

This is how ipv4 works :) and have nothing to do with wireguard, ipsec etc. Actually the config you have applied eill in some situations work, but that relies on the handling of the packets inside the kernel and is not following the tcp/ip principles... If you take a look on the quick start guide on the wireguard webpage you se it there aswell... https://www.wireguard.com/quickstart/.

As for what i can see packages are not making it trough to the other side, have you verifies that all accesslists are permitting this traffic? If you use policy firewall it will hit the LOCAL rules.

Do you have a nat device between your peers?

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

In T1226#32033, @hagbard wrote:

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

I have not tested on rolling yet due to time restraints.

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

In T1226#32102, @hagbard wrote:

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

I will still need help but i will test later today with rolling release.

Any rolling release you prefer i test or just the current one ?

@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.

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.

@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.

The thing was that the packages never arrive on the wireguard interfaces. They would arrive on the WAN interfaces however.

Could it be because one of my installs is corrupt ?

Could it maybe be related to the static route bug ?
Is there any more tests i can run before i try to reinstall completely ?

@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.

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.

Cant be that. I have tried to regen keys aswell and tested agian with the updated public keys and it will still not connect at all.

I have even gone as far as to put the keys in a text editor to compare it (sublime text) to ensure it is the same.

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.

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

Could be a corrupted install had it through quite a few rolling release after having 1.1.8 on it for some time.

All right, let me know if you need help.

In T1226#32490, @hagbard wrote:

All right, let me know if you need help.

Alright i have done a complete reinstall with VyOS 1.2.0-rolling+201902110337

new image and install new problems:

fma@glos1ce1dk# set interfaces wireguard wg3 peer vals1me2dk allowed-ips '10.0.0.0/8'

  Invalid value
  Value validation failed
  Set failed

[edit]
fma@glos1ce1dk# comp
[edit interfaces]
+wireguard wg3 {
+    address 10.0.100.1/24
+    description vals1me2dk
+    peer vals1me2dk {
+        endpoint 83.151.X.X:12345
+        pubkey xigbpIoiea7CQ1gXdGzJFvsdzKd11oVkuSrrP7X4qSw=
+    }
+    port 12345
+}
[edit]
fma@glos1ce1dk# commit
[ interfaces wireguard wg3 ]
allowed-ips required on interface wg3 for peer vals1me2dk

[[interfaces wireguard wg3]] failed
Commit failed
[edit]
fma@glos1ce1dk#

You mentioned earlier that you made an enhancement to disable peers. Could that been part of it ?

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

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

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

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

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201902150337-amd64.iso has been tested.

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.

I tried recreating the setup i have on my GNS3 enviroment with rolling release images and no firewall rules, same problem.

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?

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.

@Maltahl any news on the traffic via vlan?

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.

Do you see now the udp arriving on both sides?

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 .

@Maltahl Do you receive the udp packets now?

No dice sadly. I think we have to close this since i have a feeling it might be more than 1 issue.
I think the problem with the bond vif interface not sending recieving is a critial error but i do not know how to report it correctly.
The other issue i think is related is the static routes not being applied.