Connection Drop after 10 Seconds, TCP, HTTP
-
You know, because… well, this just happens to noone but you, pretty much.
PFSense terminates sessions that are openning, if the machine behind pfsense doesnt respond within 10 seconds, period.
Errr…. huh. No.
-
if your not going to back up your responses with anything technical, then find someone else to not help.
-
if your not going to back up your responses with anything technical, then find someone else to not help.
Your current fix includes lowering timeout values well below the defaults?
-
Actually making them longer, its seems as the stack is building the report it doesnt respond at all untill the report is actually complete, and then sends it.
but the sending was happenning just after the timeout, so the reponse from the stack was getting blocked from going out, as its state had already been dropped.
stack = MySQL, PHP, Apache.
sidenote: i only came to this conclusion after thouroughly testing all of the timeout settings in PHP, and apache, and nothing i did made any difference to the issue. and as i was able to confirm with a proof-of-concept test file that simulated the same delay but without actually doing anything, the identical behavior was seen, this it isnt a load issue. A php file that slept 11 seconds then printed a word, would never actually print anything, if the sleep was lowered to 9 seconds it reponded every time, and at 10 seconds it would respond intermittently because it was right on the wire timing wise. A touch command inserted into the php file after the print, revealed that even when it failed to respond it was indeed processing to completion but pfsense was not allowing the data out due to the closing of its state. Further evidenced when i saw a outbound denial in the firewall logs with a source port of 80 and from the webserver, meaning it was a response to an http request.
-
I wonder why tcp.first & tcp.open made an impact since I assume tcp.established should be the only relavent parameter.
I'm too curious to leave it alone but I guess if it works, it works.
Why did you change state tracking to sloppy (or none?)?
-
I wonder why tcp.first & tcp.open made an impact since I assume tcp.established should be the only relavent parameter.
I'm too curious to leave it alone but I guess if it works, it works.
Why did you change state tracking to sloppy (or none?)?
ive switched it back to sloppy for the moment, if it still works set back to normal then i will move it there permanently, i set it that way in troubleshooting tho.