Many fin_wait_2 states
-
A webserver in my dmz has a basic test page that pulls some info from a sql server database in another zone.
When I look at the state table in pfsense for port 1433 (port for sql server), I see a lot of connections in fin_wait_2 even after the browser is closed.
Immediately after page load:
Proto Source -> Router -> Destination State
tcp 192.168.10.8:1433 <- 192.168.12.4:3933 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3934 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3935 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3936 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3937 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3938 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3939 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3940 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3941 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3942 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3943 ESTABLISHED:ESTABLISHED
tcp 192.168.10.8:1433 <- 192.168.12.4:3944 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3933 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3934 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3935 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3936 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3937 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3938 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3939 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3940 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3941 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3942 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3943 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHED
tcp 192.168.12.4:3944 -> 192.168.10.8:1433 ESTABLISHED:ESTABLISHEDOnce page load was completed and browser was closed (approximately 15 seconds later):
Proto Source -> Router -> Destination State
tcp 192.168.10.8:1433 <- 192.168.12.4:3933 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3934 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3935 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3936 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3937 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3938 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3942 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3943 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.10.8:1433 <- 192.168.12.4:3944 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3933 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3934 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3935 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3936 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3937 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3938 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3942 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3943 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.12.4:3944 -> 192.168.10.8:1433 FIN_WAIT_2:FIN_WAIT_2It takes several minutes for these fin_wait_2 connections to go away and nothing to show up when filtering on '1433'.
When the pfsense state filter is showing all the states in fin_wait_2 (in the second list) I only see a single connection for 1433 on the webserver and database when I run netstat.
I've searched the forums and the config menus in pfsense extensively but haven't found anything relevant. Any suggestions would be a big help.
-
#1 - Upgrade to RC1 or RC2
#2 - Setup a LAN rule and set the advanced option "State Timeout in seconds" to 1. Be sure to set the LAN rules destination of the server in the DMZ in question. This will tear down the state much quicker. -
Thanks. I'm running RC1 currently, but will upgrade to RC2 this weekend.
My current test traffic is:
Workstation on LAN -> Webserver on DMZ (192.168.12.0/24 subnet) -> ODBC call to database on LAN (192.168.10.0/24 subnet)The state records showing fin_wait_2 all appear to be going from webserver (192.168.12.4) to database (192.168.10.8:1433). I have a rule setup on the DMZ to allow the webserver to talk to the database (allow 192.168.12.4 any port -> 192.168.10.8:1433) and I assume it is the rule to update with the 1 second state timeout?
I modified that rule but it still appears that the fin_wait_2 states are taking a substantial amount of time to expire. Since you explicitly mentioned having the rule on the LAN, I also tried putting a rule there with a 1 second timeout, but couldn't tell any difference.
Is there something else I'm missing?
-
The rule needs to be changed on the INCOMING interface. So if the webserver is talking from the DMZ to the LAN (which is generally a bad idea and defeats the idea of a DMZ to begin with) then you need the rule on the DMZ interface. In addition the rule needs to be on the top of the list.
Also one other alternative is to change the state type from keep state to none.
-
I hate having the DB in my LAN, but unfortunately the mobo on my test box doesn't have space for anymore nics so I can't create another zone.
Ok, it sounds like I have the rule setup correctly then so I'm not sure why the fin_wait_2 states are taking so long to timeout.
For testing purposes I just hit the page again a single time and closed the browser as soon as it loaded (less than one second). I filtered the pfsense state table for '1433' and it took over a minute for all the records to be purged (kept refreshing it throughout in case it was latency in the gui being updated).
After the browser was closed I noticed several new connections being established from webserver to db on 1433, but I'm not sure what that was about yet.
I just saw your comment about set state to 'none', so I will try that as well. I had considered it when I saw the option, but figured it might actually increase the number of states for pages that make multiple database hits.