@Tedd404 Hello Tedd, thanks for your help.

 

1. it is not strictly necessary to put the ER605 behind a NAT. I get ADSL service, so I need a modem, I cannot use the ER directly. In the modem, the ER605 is completely exposed, meaning that the only thing that is translated is the IP address; all ports are fully forwarded, and the ER is fully exposed to the internet. The only caveat is that the ER thinks that the WAN IP is 192.168.0.2, while in reality my public IP is different. Handshake works, so I believe we can exclude that the root cause of the issue lies here.

2. Setting the 192.168.0.2 is the only way to get a handshake. If I use 10.0.0.1, I do not even get an handshake.

3. Correct, my only client is set up as 10.101.0.2/32 both on the client itself and on the ER605 (allowed address). On client side, the allowed ips is set to 0.0.0.0/0, which should mean to route all traffic through the interface.

 

Thanks for the link, but that article is not very clear/useful. First of all, it refers to standalone mode, while I work in managed mode, and the options are different. The Windows section is not applicable, as currently my only client is iOS, and in general it does not explain fully well what happens under the hood.

I mostly refer to the arch linux wiki article for Wireguard, as it is thoroughly explained.

 

Most importantly, when you want to use wireguard as a VPN, and not a point-to-point tunnel, you need one of the peers - the "server" - to give all the other peers access to LAN. The way this is normally achieved is by setting allowed IPs to whatever you need, and setting up the routing table on the "server".

 

I believe that for some reason - perhaps bad configuration on my side - the routing table is being setup to route my client on the WAN side of the ER605, rater than the LAN side. There is no explicit option that I can see - in general I would expect to be able to "bridge" the wireguard interface to any LAN or WAN, but the choice seems not to be there.

Hello Tedd, I will be able to make the screenshots later today - I did not create any routing rule as I assumed that the Wireguard "plugin" would perform that by itself, I believe it is not mentioned in the documentation... But to be fair, it is something that is not strictly needed depending on how you want to use wireguard. Now that you mention it, it makes perfect sense to create a routing rule from 10.101.0.0/24 to 10.0.0.0/16 - I will try that out. Thanks a lot for your help.

  @Tedd404 

 

ER605 LAN = 10.0.0.1/16

ER605

[Interface]
PrivateKey = 123
Address = 192.168.0.2
DNS = this setting is not part of the interface on the ER

[Peer]
PublicKey = ABC
AllowedIPs = 10.101.0.2/32
Endpoint = not set

 

Client:

[Interface]
PrivateKey = 321
Address = 10.101.0.2/32
DNS = 10.0.x.x (I have DNS in my LAN)

[Peer]
PublicKey = ABC
AllowedIPs = 0.0.0.0/0?
Endpoint = 217.x.x.x (my public facing IP)

 

No routing set up

Hello Tedd, thanks for your input. With this setup I have the same - internet access but no LAN access. Using a public DNS works better only because I cannot access my local DNS normally, but changing the IP ranges doesn't seem to do much - nor reducing the AllowedIPs range. Moreover, keep in mind that client side routing only 10.0.0.0/16 with a DNS which is outside of the routing range does not seem like a good approach to me - I guess it can work though. I am more and more convinced that I need to add a routing rule from 10.101.0.0/24 to 10.0.0.0/16 somehow; but I want this attached to my wireguard interface, not to the WAN interface...

Hello Deeo; thanks for your input. Let me see if I understand correctly - I have to create an additional “fake” peer, no client associated with it, and both the interface and the peer need to live on the same subnet, which must not clash with anything. That said, what about the additional peers? Should the allowed ip be in the same subnet, or can I use anything I like?