SSH Idle Session Timeout/Dropping Issues
-
Progress! Well kind of. If I completely disable all packet filtering (System->Advanced->Firewall / NAT-> Disable all packet filtering.), it seems to solve the problem. Could it be that "State Type" option in the rules and I am just not setting it for the correct rules?
-
If I completely disable all packet filtering (System->Advanced->Firewall / NAT-> Disable all packet filtering.), it seems to solve the problem.
Is pfSense actually doing anything useful on your network? Have hard time understanding your setup.
-
Sorry, I meant that it solves the problem but isn't a valid solution since it defeats the purpose of having it on our network. I am using it at the moment with pfBlockerNG to pull in a bunch of blacklists for now and possibly use Snort at some point in the future.
I believe I have fixed the issue though. I added a rule to Floating Rules, WAN Rules, and LAN Rules that passes the TCP protocol and in the advanced settings has the TCP flags set to "Any flags." and the State Type set to "sloppy state". The Floating Rule is being applied in the "out" direction on all interfaces but my management interface. I'm not sure if all three of the rules or what I have set in them are necessary, but the issue seems to be fixed. If it comes back up again, I will post again. Thanks for all your help! I really appreciate it!
-
I've encountered SSH timeouts every 30-40 secs but only on non-VPN connections to local servers.
There are no issues when the same ssh connections are made on the VPN. Isn't this odd? I don't recall making these settings for the VPN connection.
I've applied Conservative in System/Advanced/Firewall&Nat section but still trying to figure out what makes the local SSH connections timeout.Anyone else experienced this?
-
So your not talking a ssh session to pfsesne, your talking a ssh session inbound to a server behind pfsense. That you forward in from pfsense wan..
-
I was able to get it to work by adding a pass rule (I added a floating rule and a rule in both LAN and WAN) to allow for sloppy TCP states (under advanced options and set State type to Sloppy).
-
I'd fix whatever weirdness is on my network making that necessary but that's probably just me.
I would at least want to understand why.
-
Guess we are just weird like that Derelict ;) hehehe I would do the same thing.
-
Progress! Well kind of. If I completely disable all packet filtering (System->Advanced->Firewall / NAT-> Disable all packet filtering.), it seems to solve the problem. Could it be that "State Type" option in the rules and I am just not setting it for the correct rules?
Ahh, my young padawan, it does not solve the issue, it solves the symptom. I could tell this is what you meant with "Well kind of", but words can be important as they can influence how you think about a problem, even if you "know what you meant".
-
I'd fix whatever weirdness is on my network making that necessary but that's probably just me.
I would at least want to understand why.
Can you define what you mean by "network" weirdness, if pfSense is the cause of the problem?
Pardon me for jumping onto this thread, but I am experiencing the same problem, accessing a Cisco phone system on its voice VLAN 150, doing automatic routing through pfSense to VLAN 1.
pfSense is set as the gateway on VLAN 150 for the Cisco, and is set as the gateway for the desktop PC on VLAN 1.
Open SSH on VLAN 1 to the Cisco controller, and I can connect, but the connection only stays active 1-3 minutes and suddenly force-closes.
It kills the SSH session, even if the session is NOT idle but streaming data, such as dropping right in the middle of a "show tech-support" text dump.
VLAN 150 firewall config in pfSense is "pass all IPv4, all protocols, from any to any", setting it wide open to remove any possible flow restrictions.
pfSense still drops SSH anyway, even though I can ping the Cisco continuously from VLAN 1, no problem.
If I put a computer directly on VLAN 150, SSH works normally, sessions can stay open indefinitely, no problem.
-
It means "sloppy state" and "disabling pf" should never be necessary. I am not going to try to decipher that text, do the work, and make a diagram for you.
Look at the diagram in my sig to see the information necessary and make one and post it.