SSH Disconnecting Over OpenVPN

[raptor01uk]

Hi,

I have an OpenVPN client connected to Pfsense and everything works fine apart from SSH.

If I SSH to a public server then the session stays active.
If I SSH to a server at the other end of the VPN, after 20 - 30 seconds the session disconnects.
If I'm connected locally to the network with the server on and SSH directly then the session stays active.

I've tested MTU as the google suggests but all hops report 1500. I've tried setting a lower TCP MSS size (1300, 1400, 1450) but then I lose the ability to ping all together and there is an MTU related error on the client when the session starts. There are no logs on the server that suggest a reason for this and Pfsense logs say that everything is fine.

This happens with all servers and they are all running Centos 7.

Has anyone had this issue before and can suggest something that doesn't require me to change the default network settings on the servers.

Thanks for any help guys and girls.

[raptor01uk]

Further developments:

I've tested SSH to a router in the same subnet as the servers and the SSH stays active. Looks like this is related to Centos/ Linux servers only.

[Pippin]

Could you be suffering from this:
http://sites.inka.de/bigred/devel/tcp-tcp.html

[johnpoz]

I vpn into my home network from work all the time… I will fire up a centos 7 vm and see if I can duplicate this problem.. Be my little fun project at work today - if I don't get pulled into real work nonsense ;)

[johnpoz]

Ok… I installed centos 7 min on vm

Ran yum update

Currently connected over a vpn to my home from work...  SSH'd in over this vpn... Not having any issues..  Not typing anything so not keeping it alive, etc..  Every so often did a date on the remove machine so you can see how much time was going by between commands, etc..  Clearly connected for well over your 20-30 seconds without disconnect..

See attached - sorry I can not duplicate your problem.  Maybe you just have a bad connection across this vpn...

edit:
So I connected back in and just left it as a window on my other monitor... Well over an hour still connected

C:>ssh root@192.168.9.228
root@192.168.9.228's password:
Last login: Wed Mar  7 12:24:15 2018 from 10.0.8.2
[root@centos ~]# date
Wed Mar  7 12:47:41 CST 2018
[root@centos ~]# date
Wed Mar  7 13:56:27 CST 2018
[root@centos ~]#

[raptor01uk]

Thanks so much for putting so much effort into helping!!!

I've done some more testing this evening and it would appear that it's only servers in a certain subnet that are affected. I have around 8 different subnets behind this firewall and i've tested 4 with no issues. So, I think this might be some kind of strange routing issue like a flapping interface or a route dropping out of the network.

If I get to the bottom of it then I'll let everyone know that it was something stupid that I should have spotted.

Thanks

[johnpoz]

Well without more details of the setup of this network, not possible to help..  Did you try a simple packet capture… These can be very informative even when the actual data is encrypted.  Maybe your seeing packet loss, maybe your seeing a RST sent.. Maybe you see interface flap?  etc. etc..

[raptor01uk]

I can't go into loads of detail about the setup but I knocked up this quick Visio (attached) to show the various networks involved.

SSH from 192.168.5.0/24 works fine to any network.
SSH from VPN to 10.150.55.0/24 works fine.
SSH from VPN to 192.168.2.0/24 works fine.
SSH from VPN to 192.168.5.0/24 works fine.
SSH from VPN to 192.168.1.0/24 connects then after 30 - 60 seconds drops.

My home network is 192.168.0.0/24 so no conflicts. The firewall is the only thing doing NAT the rest is all routed with BGP or statics in the case of the firewall.

The diagram is a Layer 3 representation of the networks but I can place a VM in both 192.168.1.0/24 and 10.150.55.0/24. This is my next step to see if the ssh session remains active on both or drops on one/both.


[ssapfsense]

In my case, the users weren't able to connect to the server through SSH because their traffic was going through the Secondary WAN address. I have 2 WAN ips configured on my pfsense firewall.
I used tracert google.com on the client system to check the path. This is how if foundout that the traffic is going through the secondary WAN address. So I added both WAN ips in the SSH access list and the issue got resolved. Now we are able to connect via ssh without any problem.