OpenVPN Stopped Allowing Local Network Access

[BruinsFan]

I've been running OpenVPN on my DS1621xs+ for about 8 months. I only connect to it remotely when I'm traveling for work, which is maybe 1-3 times per month.

Recently I've started having an issue where I can VPN in, connect to DSM via the browser, but can't access anything on my LAN. I've verified that my IP addresses are not in conflict between my Laptop's WiFi and my subnet on my home LAN.

I took the obvious approach of toggling the "Allow clients access to server's LAN", but every time I try to change that, it fails and I get the attached error. Strangely, if I reboot DSM, the checkbox remains on/off based on what I intended for it to do before the error. In any case, it isn't solving the issue.

Is there any documentation for what that checkbox does? Is there an easy way to reset all the network routes? I'm not currently using the NAS for anything besides a file share and cloud sync.

DSM Version: DSM 7.1-42661 Update 3
Synology VPN Server Version: 1.4.6-2892

Thanks in advance!

 

[Rusty]

Is there an easy way to reset all the network routes?

Have you just tried to stop/start VPN package so you don't have to reboot the NAS?

 

[WST16]

Hi,

A shot on the dark, but do you have a valid certificate? Also did you try logging in to the NAS using the IP address (instead of DDNS) to try this “toggling”.

Personally, my next move would be to uninstall the VPN server and reinstall it

 

[BruinsFan]

Thanks for the suggestions. I have uninstalled the VPN Server and reinstalled it. I also generated a new export, so the cert is good until August 2023.

Same behavior for the most part, except I'm seeing a new pattern. When I first connect to the VPN, I'm able to ping a resource on my LAN For exactly 1 ping. My comments in square brackets below.

ping 192.168.1.201 -t
Request timed out. [before connecting to VPN]
Request timed out. [before connecting to VPN]
Request timed out. [before connecting to VPN]
Request timed out. [before connecting to VPN]
Request timed out. [before connecting to VPN]
Request timed out. [before connecting to VPN]
PING: transmit failed. General failure. [While connecting to the VPN]
Reply from 10.8.0.6: Destination hot unreachable [While connecting to the VPN]
Reply from 192.168.1.201: bytes=32 time=85ms TTL:126 [Immediately after connecting to the VPN]
Request timed out. [Directly after, still connected to the VPN]
Request timed out. [Directly after, still connected to the VPN]
Request timed out. [Directly after, still connected to the VPN]
Request timed out. [Directly after, still connected to the VPN]
Request timed out. [Directly after, still connected to the VPN]

Pretty strange, huh?

 

[WST16]

ping 192.168.1.201 -t
Request timed out. [before connecting to VPN]

Where are you pinging from? Are you on the same subnet? If not, why do you expect a reply (or are you not)?

If it was working before and suddenly misbehaved, then either there were some changes on the server side or the client side. Think back and try to recall any changes you've done recently.

• Did you configure the VPN for all traffic or are you on a split tunnel?
• Do you have any static routes defined?
• Do you have the firewall enabled?
• Try a different client just for testing.

 

[BruinsFan]

• Did you configure the VPN for all traffic or are you on a split tunnel?

That did the trick, thank you! It was defaulting to a split tunnel, the second I changed it to force all traffic through the VPN, it began allowing me to access LAN resources.

If it was working before and suddenly misbehaved, then either there were some changes on the server side or the client side. Think back and try to recall any changes you've done recently.

That's the strange part, besides DSM updates, DSM package updates, and OpenVPN Windows Client updates, I haven't made any configuration changes this year. I actually spent a few hours tonight configuring logging on my Unifi USG to see if any of my firewall rules were dropping the connection, but nothing came of that.

 

[WST16]

That did the trick, thank you!

Glad it’s working again, you’re welcome

I don't know how your network(s) are setup, but usually if you're using the same subnets on both sides (e.g. 192.168.1.x) and you have a split tunnel, your client will try to reach the local subnet. Might not be related to your case.

I always configure different subnets on different locations (e.g. location A 192.168.5.x, location B 192.168.8.x and so on).

 

[BruinsFan]

You're right, I have several networks/subnets with different purposes. I suppose keeping 192.168.1.x should've been avoided for one of them. Today I also learned that my Samsung S21 Mobile Hot Spot issues IPs in the range of 192.168.30.x, which is hardcoded and unchangeable. That happens to overlap with my security camera subnet, which I have locked down the most, which is why I went down the firewall log route earlier tonight.

Hopefully this thread is helpful to others that may also encounter quirks with one of the updates on DSM/VPN Server/OpenVPN Client that happened in the last 30-60 days.