@Grimeton It seems to monitor the correct address of my WAN. Did you mean add the actual VPN server's IP as a monitor IP for the VPN gateways? Also, just had another disconnection and the only new lines in the logs are these: [image: 1581419053252-screen-shot-2020-02-11-at-13.02.18.png] [image: 1581419753304-screen-shot-2020-02-11-at-13.11.01.png] The WAN gateway is always green and ok so the problem is probably that the dpinger pings the internal virtual IP of the VPN (10.8.x.x), instead of its server's actual IP, right?

@JKnott Thanks. I used the ip addy and user authentication.

You do not need to force all traffic through the VPN to reach your Domain Controller / AD. -Rico

@Grimeton said in Wierd OpenVPN client behaviour causing disconnections: Networking issues, followed by an ICMP package containing proto or port unreachable. ICMP package coming from me out to the server or vice versa? @Grimeton said in Wierd OpenVPN client behaviour causing disconnections: Networking issues causing OpenVPNs internal timer to timeout and disconnect/reconnect. What should I do in such case? EDIT: I've noticed that it usually happens when one of the VPNs in the VPN group (of 2) is going down (for maintenance or whatever) and because both/all of them are marked as Tier1 it may cause such reconnection attempts...on the other hand that's why we have VPN groups and Tier priority LOL

@Pippin According to NordVPN guys, the cipher thing is not an issue and their servers also support GCM. The fact that my choice of SHA512 is not recognized/mentioned in the logs is wierd though... @Pippin said in Constant disconnections and "Restart pause" in the system logs: Also, showing a fragment of the log doesn't help. It's not a fragment. It's the majority of it and it just repeats itself from time to time.

Sniff traffic on the pfSense side to check if the client can even hit your OpenVPN server. -Rico

@Gertjan you are correct. I will just set everything to go thru the tunnel and be done with it. Thanks for pointing these things out.

@Pippin no I have several (12) user each one with a specific routing...

I'd also investigate a MTU mismatch etc... Here's my (potentially flawed) logic: Server on Side A has larger MTU than Server on Side B. (I assume you copy server to server) Initializing the transfer from Site (B) I can copy FROM a file server on Server (A) with roughly 20MB/sec which is great. I assume the server on Side B requests a small packet size... (Maybe Path MTU Discovery) Initializing the transfer from Site (B) I can copy TO a file server on Server (A) with roughly 20MB/sec which is great. The server on Side B sends data packets that are smaller than Server A maximum accept size. Initializing the transfer from Server (A) I can copy FROM a file server on Site (B) with roughly 20MB/sec which is great. The server on Side B will only send small packets (or packets that are smaller than what Server A can receive) ...but Initializing the transfer from Server (A) I can copy TO a file server on Site (B) with only roughly 8MB/sec Server A doesn't know that Server B can only receive small packets. The Firewall (VPN endpoint) on Side B now has do extra work breaking up large packets into smaller ones - which Server B can accept. So my guess would be fragmentation etc... MTU can be set on Host interfaces, too ... You could try reducing the MTU Size on Server A network interface. Also have a look at the pfsense option (Remove DF bit) https://www.reddit.com/r/sysadmin/comments/2mt3jc/reducing_mtu_value_to_fix_slow_cifssmb_over_vpn/

Ah, got it. I knew I was missing something simple. Thanks!

@ddbnj said in Cannot access beyond router via OpenVPN: 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 Yeah that would dick it up ;) Glad you got it sorted! Told you it wasn't pfsense ;) hehehehe The trick is getting the person to clearly see that themselves... Which is why the sniff proves to the user, hey pfsense is doing what its suppose to be doing... Have to look elsewhere..

If you do run your vpn server downstream, you can host route on devices on your local network that you want to create traffic from to your remote vpn clients.. Its not all that hard to do, depending on the such restrictions you might have on the actual local client.

@handleric I think that fixed the issue. Thank you!! This has been driving me nuts!

Hello, Over the past few days i've been doing a lot of research trying to remediate this issue and it seems there are a dozen or more threads for this same issue, is anybody from the development team investigating this?