Can't access clients connected through VPN

Hi Guys! Hope you're all well :slight_smile:

I've already posted this question on the Synology forums, since I'm using the VPN that comes with the NAS. Now I think that I should have come here at first.

I'm no network guru so as far as I've gotten is with some googling.

I've been using the VPN on my NAS (don't have Synology router) a long time. And untill now it was just a simple VPN back to my network and do whatever, as client.

Yesterday I was presented with a more demanding requirement.

On Location 1 I'm runing some software on my server that manages access controll on my physical location. Basically it controls users, wireless BLE locks and the wireless BLE gateways the locks use to go from BLE to 192.168.0.0/24. The gateways are pretty dumb when it comes to configurability. I can only set the IP and the software on the server does the rest.

On Location 2 I have to setup one of those gateways and locks. The gateway needs to have access to the server on the 192.168.0.0/24 network and the server back to it, while it's 80km away on 192.168.1.0/24.

So for Location 2 I've I grabbed a raspberry pi, got OpenWRT on it and got OpenVPN runing on it aswell. Connecting the RPI over wifi to the wireless router and connecting the gateway and my laptop through LAN. Everything works great when I want to access my Location 1 network. But anyone on Location 1 can't get to any client on Location 2.

So I first added a route route "add 10.8.0.6 mask 255.255.255.0 192.168.0.6", the 10.8.0.6 being OpenWRT and the IP it got from the VPN server, and 192.168.0.6 being synology nas. That way I could at least access the OpenWRT on Location 1 for now.

Then I tried "192.168.1.234 mask 255.255.255.0 10.8.0.6" to get to the BLE gateway which is on 234 IP. And that's where I got stuck. Tracert show's it goes directly to my Location 1 default gateway and nowhere near the NAS.

Any ideas where I'm doing it wrong?

1 Like

Route into a Open-VPN-Client Subnet - #2 by vgaetera

1 Like

Awesome! WireGuard works like a charm. Needed a bit to wrap my head around it. But man, this thing is awesome. And so fast!

1 Like

Just a question if you might have some information, so I don't make a new topic about this.

12 hours ago I shut everything down for the night. This morning I was able to connect with second peer but the first one would not connect. I had to restart wg0, then right away both the peers worked, not just the first. Also I didn't touch the client of the first peer, so no configuration error there, it just popped up in "wg show".

I'm thinking it has something to do with the second peer and/or AllowedIPs, but can't figure out what the issue is.

EDIT: I just noticed as soon as I connect with the second peer (mobile phone) something strange starts happening. The latest handshake goes well past the timer set in the client config, but they all still work somehow.

[Interface]
Address = 10.9.0.1/24
ListenPort = 5941
PrivateKey = <PRIVKEY>
SaveConfig = false

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE

# client
[Peer]
PublicKey = <PUBKEY>
AllowedIPs = 10.9.0.3/32, 192.168.0.0/23, 192.168.1.0/23



# client
[Peer]
PublicKey = <PUBKEY>
AllowedIPs = 10.9.1.4/32

It's the same IP range:

Ha,

That makes sense. Hopefully that was it.
Thanks :slight_smile:

1 Like

If the issue persists, check out the following workarounds:

It seems the issue is a bit more complicated. I have the server runing on an Ubuntu installation, and the client is from an OpenWRT installation on a raspberry pi.

I noticed that if I turn off the Rpi for the night, the other day it won't connect untill I restart wg0 on Ubuntu.

Might this be to an improper shutdown? Since I just unplug the Rpi from electricity? I don't know if Wireguard has a disconnect process.

Every other client I have connects without issues, but I have to restart WG0 on Ubuntu to get the RPI to connect. After restart it connects within a second.

There's a workaround script that you can run on the server:
https://git.zx2c4.com/wireguard-tools/tree/contrib/reresolve-dns/reresolve-dns.sh

Modify it to reload the connection when peer handshake is too old.

Seems the issue was that the time was wrong. The RPI has no internal battery and has to get the correct time from the internet. But the WG client has allowed IPs set to 0.0.0.0./0. And until it connects there's no internet as I guess it routes all traffic through WG.

I think I've solved this by setting only the local IP's from server side.

But now makes me think, if one would want to send all traffic through WG including internet, how would one go about this? Delay the WG startup? Something else maybe? Maybe there's an exclude to the allowed IP's, to let NTP server through?

I have mentioned above the method that works for my router.

Ugh, sorry for late reply, was swamped.

Yeah that worked!

Thanks for your help :slight_smile:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.