VPN Server -> VPN client routing issue

[Jack Yaz]

Hi,

I have a VPN server that allows access to my LAN. One of the devices on my LAN uses policy rules (not strict) to send all internet traffic over VPN (provided by PIA). I have found an issue that I'm not sure if it is caused by a configuration issue, or simply the way it works.

Issue: If VPN Server restarts for whatever reason, clients connected to VPN Server can no longer access the LAN resource redirected by policy rules. Connection is restored after restarting the VPN Client.

Running tracert on the device that is redirected, to a VPN Server connected client, shows 2 hops, 1 to router, 1 to device. If VPN Server is restarted, the 2nd hop is no longer the device, and is instead an IP like 10.13.10.1. tracert returns to normal on restart of VPN client.

Does anyone have any ideas, or is this just how routing works and I need to remember to restart the VPN client when the VPN Server starts? I wondered if I might be able to leverage openvpn-event script, though I'm not sure how I would determine it's a server restart calling the script.

 

[Jack Yaz]

So far, I've found this in openvpn-event to do the trick:

#!/bin/sh

if [ "$1" = "tun21" ] ; then
    logger -s "Restarting VPN client 1 to allow access to VPN Server 1 clients"
    service restart_vpnclient1
fi

 

[st3v3n]

Jack Yaz, That behavior is typically what I see on our 3200; does your VPN server (or clients) restart sporadically, due to restart command, power issues, etc?

 

[Jack Yaz]

I haven't noticed any unintended restarts of the VPN Server, I think it's usually when I apply a config change or addition of a new user.

 

[st3v3n]

Yes, I'm pretty conservative when introducing new server addresses, configs, IPs, etc. There no actual dicate that I've ever found, that states a running config should be halted when one works on the other tunnel/config. I take the time to turn off the active tunnel, and save it before I work on either. A quick save has saved me from grief more than once.

I've never used PIA, but researched it now and then. Our providers configs usually work as suppled, but when they get balky, I've had luck varying the DNS (disabled/strict/relaxed/exclusive), policy rules (same) and compression level. Some of the VPNs advise against changing the settings; I read about it on the forum last year, and though YMMV, depending on the tunnel, a slight change can work wonders if your wireless or tunnel is dropping. The PIA forum used to be very generous with user experiences. Our provider upgraded to 10G servers nationwide, but it was rocky for a day. Yesterday wifi and tunnels dropped every 15 minutes.
One tunnel was set by the provider to use LZA adaptive, wasn't staying up so I experimented with compression and the other setting; I let them know the results. No one else had reported it, but soon thereafter they corrected their config settings to drop compression.

Our VPN server turned off once, interrupting an iPhone OTA update but didn't happen again. DDNS caused problems for a full day after I removed it when I was testing settings. The next day it was still trying to connect, but a reset finally fixed resolved.

What has caused more wifi/tunnel interrupts lately for unknown reasons, the DST date/time field resets suddenly. This week it leaped forward to the 3rd Sunday in November. Wifi began dropping, then the tunnel failed. Since there's no setting that has a direct access to the field to affect it; a few others have mentioned it, another user also believed this may be part of a hack. Now whenever wifi interrupts or a tunnel goes down, I first check the date/time field before anything.

I've tried to heed your advice, more breaks for easier reading. I hope it's a bit easier to comprehend. Good luck & Cheers.

 

[Jack Yaz]

Yes, I'm pretty conservative when introducing new server addresses, configs, IPs, etc. There no actual dicate that I've ever found, that states a running config should be halted when one works on the other tunnel/config. I take the time to turn off the active tunnel, and save it before I work on either. A quick save has saved me from grief more than once.

I've never used PIA, but researched it now and then. Our providers configs usually work as suppled, but when they get balky, I've had luck varying the DNS (disabled/strict/relaxed/exclusive), policy rules (same) and compression level. Some of the VPNs advise against changing the settings; I read about it on the forum last year, and though YMMV, depending on the tunnel, a slight change can work wonders if your wireless or tunnel is dropping. The PIA forum used to be very generous with user experiences. Our provider upgraded to 10G servers nationwide, but it was rocky for a day. Yesterday wifi and tunnels dropped every 15 minutes.
One tunnel was set by the provider to use LZA adaptive, wasn't staying up so I experimented with compression and the other setting; I let them know the results. No one else had reported it, but soon thereafter they corrected their config settings to drop compression.

Our VPN server turned off once, interrupting an iPhone OTA update but didn't happen again. DDNS caused problems for a full day after I removed it when I was testing settings. The next day it was still trying to connect, but a reset finally fixed resolved.

What has caused more wifi/tunnel interrupts lately for unknown reasons, the DST date/time field resets suddenly. This week it leaped forward to the 3rd Sunday in November. Wifi began dropping, then the tunnel failed. Since there's no setting that has a direct access to the field to affect it; a few others have mentioned it, another user also believed this may be part of a hack. Now whenever wifi interrupts or a tunnel goes down, I first check the date/time field before anything.

I've tried to heed your advice, more breaks for easier reading. I hope it's a bit easier to comprehend. Good luck & Cheers.

No further problems since I put the script in. While it doesn't solve my gap in knowledge as to why it happens, it's a fix nonetheless.

Re. compression, I found I had to turn this off for my VPN server, SMB transfers would drop to 0KB/s in a sustained transfer. After disabling compression, transfers complete as expected. Side effect is increased data usage, but I'll take that vs an unusable trasnfer. I might add FTP was unaffected by the compression setting and worked flawlessly.

Re. your time issue. It might be possible to write a daily cron job (or more frequent, if you prefer), that checks the nvram variables responisble for the DST and resets them, if required. I'm happy to have a go at putting a script together for you, if this would be of use?

 

[st3v3n]

Thanks, it's an kind offer and I'll give it some serious thought. Wife is trying to assist my work on the new PfSense installation, and I'm trying to get it configured before I go into the hospital, so the time is getting more compressed than usual. They keep sending more paperwork though I keep advising them I can no longer fill it out. Voice recognition only goes so far. Funny how they don't have any sense of humour. Like email and posting, no sense of irony between the lines. Regardless how decrepit I looks, receptionist keeps shove paperwork on clipboards at me when I can't hold the pen. It does present challenges, and it helps that we all look/sound alike on the web. Cheers.