PfSense still blocking some request when NAT shoud allow them
-
I've setup pfSense (2.2) to NAT ports 80 and 443 to my server on the LAN. First I though it was working fine. I was able to access my site from my external test locations fine.
Then I started getting reports from users that they had connectivity issues. After some research this pointed to being able to connect when at home, but not when at work. Could pfSense block proxied requests?
Strange, but I dug into the firewall log and I find several requests to post 80 and 443 being blocked. I don't understand why though. The protocols are TCP:A, TCP:FA, TCP:RA, TCP:RAC see attachment.
I've also attached my NAT roule setup.
-
F and R are not a huge issue because they are reset and FIN packets, meant to kill connections, but plain old ACK packets is important. In order to get an ACK, you first need a SYN to get through. To me this means the states are getting created, but then die after a bit.
Do you have multi-WAN? asymmetric routes are the most common cause. What are you firewall rules and how is your network setup? A diagram would be great, but any other way that can easily and correctly convey your setup would be fine.
-
My network is very simple. I get internet via fibre. The fibre modem/router is setup in bridge mode and passes all traffic into the wan port of pfSense. The lan port is connected to a switch which leads to various wired devices as well as a WiFi access point. Single wan, single lan, not vlan, nothing fancy at all (see image).
The only rules I have are the default drop for non-reserved IP's and the corresponding rules for my NATed ports (se previous post). 192.168.10.2 is a server connected to the switch which is running the web sites some users are having issues accessing.
-
I'm not noticing anything off. At this point, you may need a packet dump of WAN and potentially LAN during the entire lifetime of one of these TCP connections that suddenly die.
-
Blocking out of state is common. Do you have it set to reset states on loss of monitor. You could try turning that off.
There are plenty of reason why a connection could be out of state.
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
If your resetting your states.
Advanced, misc
The monitoring process will flush states for a gateway that goes down if this box is not checked. Check this box to disable this behavior. -
Blocking out of state is common. Do you have it set to reset states on loss of monitor. You could try turning that off.
There are plenty of reason why a connection could be out of state.
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
If your resetting your states.
Advanced, misc
The monitoring process will flush states for a gateway that goes down if this box is not checked. Check this box to disable this behavior.This seems a bit different than the other out of state questions. Since ACKs do not need to be ACK'd, there the only reason I can think of that would result in the other side sending ACKs is that the other side is still receiving data. I don't mean the FA packets, I mean the A packets, all from the same source port.
-
You need a state for there to be allowed traffic!! Period!!
syn,
syn,ack
ackWould be typical handshake.. But your nothing getting through the firewall if the state is not there. If you reset the states or the state has expired then packets are dropped!
-
I still wonder if he has an asymmetric path.
It was my understanding that ACKs happen only response to receiving data. If the external device is sending back ACKs, then it must be still actively receiving data. If the states have been cleared, then what is still sending data since out of state should also be blocking LAN side.
-
The client is public internet to webserver behind a nat.. If I want to get a page, that would be an ack.. Look at a typical datastream. If his firewall timeout the state or they were all reset because the gateway went down. Then connection coming from the client would be blocked.
Server would be not creating connections to the client. This is not a big issue because the client should just open a new connection that would create a new state via syn.
