SSH Sessions getting cut off
-
Hi all, here's my layout.
pfSense 1.2.3, I have a server on the LAN segment which is an openVPN box. The LAN is 192.168.60.x, ovpn hands out 192.168.100.x addresses to the clients. We have a static route in pfSense telling any 100.x traffic to go to the LAN server IP and 100.x has a LAN rule allowing any traffic to go to 60.x. That works just fine, I've been on ovpn sessions all day long with no trouble, even long periods of inactivity.
We then have a project that is their own subnet and have a router in front to handle their traffic. So I have another static route saying any traffic for 130.x goes to the LAN address that is the WAN interface on their router. I also have a LAN rule saying any 100.x traffic is allowed to go to 130.x. From my LAN segment I can ssh all day long with no problems. When they connect via SSH from the ovpn segment, a connection is established and they go through user auth. After 5-10 seconds, their session behaves as if it were timed out. A wireshark trace at the client shows a retransmit come from the server, the client sends an ack back, but it never reaches the server because it appears pfSense is blocking it:
Oct 15 09:17:21 x pf: 338721 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 27916, offset 0, flags [none], proto TCP (6), length 508) 192.168.100.130.3408 > 192.168.130.22.22: P 0:468(468) ack 1 win 17268
Oct 15 09:17:25 x pf: 128393 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 35382, offset 0, flags [none], proto TCP (6), length 508) 192.168.100.130.3408 > 192.168.130.22.22: P 0:468(468) ack 1 win 17268
Oct 15 09:17:26 x pf: 650251 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 39449, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.130.3408 > 192.168.130.22.22: ., cksum 0x0e9e (correct), ack 1 win 17268
Oct 15 09:17:40 x pf: 170286 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 29481, offset 0, flags [DF], proto TCP (6), length 508) 192.168.100.130.3408 > 192.168.130.22.22: P 0:468(468) ack 1 win 17268
Oct 15 09:17:41 x pf: 189759 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 22829, offset 0, flags [DF], proto TCP (6), length 40) 192.168.100.130.3408 > 192.168.130.22.22: ., cksum 0x0e9e (correct), ack 1 win 17268
Oct 15 09:18:08 x pf: 585882 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 14806, offset 0, flags [DF], proto TCP (6), length 92) 192.168.100.130.3408 > 192.168.130.22.22: P, cksum 0x8655 (correct), 468:520(52) ack 1 win 17268
Oct 15 09:18:11 x pf: 1. 373152 rule 169/0(match): block in on em0: (tos 0x0, ttl 127, id 61099, offset 0, flags [DF], proto TCP (6), length 40) 192.168.100.130.3408 > 192.168.130.22.22: ., cksum 0x0e6a (correct), ack 1 win 17268I saw the 'blocked legitimate traffic' FAQ, but this isn't traffic that looks blocked, based on the behavior I'm seeing, it really is getting blocked. I added a rule specifically for my vpn connection to test this for any port, any protocol for the specific source and dest IPs. It allows the TCP:S but :A and :P are getting blocked. Turning on keep alive in Putty isn't helping anything. This is killing active sessions. Again, we get auth to happen, and have enough time to do an ls on a couple directories but eventually the session stops responding, then gets disconnected.
Can anyone point me to what I'm missing?
Thanks
-
Sounds like a pretty big routing mess… Why not do OpenVPN on the pfSense box?
Or why not put a route on the OpenVPN box that points the 130.x network where it needs to go directly, rather than making it bounce off another router?
-
Ovpn was already there when pfSense came online. We only recently moved over to pfSense from Smoothwall. This is a piecemeal development network where I'm just a hub for the larger projects. Those that have extensive setups or their own hardware are their own islands, I only provide ping/power/pipe to them. Nothing here is optimal.
I'm not big on having to keep two lists running. Meaning I need one on the ovpn box but I still need the one on pfSense for all the local traffic. However I hadn't thought about at least adding them directly on ovpn to test whether that corrects the issue.
We did a test this afternoon with a different project that allowed us to stand a server up inside their subnet and connected successfully with ovpn and the session did not time out. I have the other project re-doing their router to see if that clears things up. Based on a wireshark capture on the port their router is connected to, it seems that the client and server lose track of the session after the client loses a segment. 10.30 is the client, 30.22 is the server.
319 49.834072 192.168.10.30 192.168.30.22 TCP virtual-places > ssh [ACK] Seq=2573 Ack=9739 Win=15520 Len=0
332 51.321692 192.168.10.30 192.168.30.22 SSHv2 [TCP Previous segment lost] Encrypted request packet len=52
333 51.322359 192.168.30.22 192.168.10.30 TCP [TCP Dup ACK 316#1] ssh > virtual-places [ACK] Seq=9739 Ack=2573 Win=8576 Len=0 SLE=2625 SRE=2677
334 51.325522 192.168.10.30 192.168.30.22 SSHv2 Encrypted request packet len=52
335 51.326036 192.168.30.22 192.168.10.30 TCP [TCP Dup ACK 316#2] ssh > virtual-places [ACK] Seq=9739 Ack=2573 Win=8576 Len=0 SLE=2625 SRE=2729
338 51.474594 192.168.10.30 192.168.30.22 SSHv2 Encrypted request packet len=52
339 51.475145 192.168.30.22 192.168.10.30 TCP [TCP Dup ACK 316#3] ssh > virtual-places [ACK] Seq=9739 Ack=2573 Win=8576 Len=0 SLE=2625 SRE=2781 -
You have asymmetric routing so you need to check "Bypass firewall for traffic on the same interface" under System>Advanced.
-
@cmb:
You have asymmetric routing so you need to check "Bypass firewall for traffic on the same interface" under System>Advanced.
Sorry, should have mentioned that was already done. Needed that the first day due to other routes in the network.
