Firewall blocking TCP:SA connections from DMZ to WAN despite rule

[tjbp]

Hi all, am looking for some assistance with some log entries I don't understand.

First of all, I have seen this link:
http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection%2C_why%3F

From what I gather, that affects TCP connections with the FIN flag, and potentially PSH or RST. Those do appear in my log (in the form of TCP:FPA), but not nearly as frequently as TCP connections with the SYN and ACK flags (TCP:SA). I get one TCP:FPA entry around every minute, and TCP:SA entries every 10 seconds on average. The source is a 192.168.x machine in my DMZ, from port 51248 (my BitTorrent client). The destination, obviously due to the workings of torrents, is an ever-changing list of IPs and ports.

These are the rules (in order) for my DMZ interface:

• Block bogon networks
• Reject all with destination IP of LAN subnet (prevents connections to my home LAN from the DMZ)
• Allow all with source IP of 192.168.2.2 (the DMZ machine with the BitTorrent client)

I've tried setting that last rule's proto to TCP/UDP (instead of "any") so I could enable all the TCP flag options in the advanced settings, but that had no effect.

Does the documentation I initially linked to still apply to this situation? I seem to be having trouble connecting to many peers on my BitTorrent client, and suspect these blocks may have something to do with it.

Thanks for your time.

[marcelloc]

Syn ack is part of three way hand shake

Syn ack is the response of syn win.

20:08:14.046422 IP 192.168.1.122.55361 > 192.168.1.133.80: Flags [ S ], seq 203542660, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:08:14.046507 IP 192.168.1.133.80 > 192.168.1.122.55361: Flags [ S. ], seq 2094335208, ack 203542661, win 65228, options [mss 1460,nop,wscale 7,sackOK,eol], length 0
20:08:14.046667 IP 192.168.1.122.55361 > 192.168.1.133.80: Flags [ . ], ack 1, win 16425, length 0

[tjbp]

@marcelloc:

Syn ack is part of three way hand shake

I see… so my firewall is blocking handshake responses, and thereby negating potential connections? If so, is it doing that because these packets are failing to be matched by any of my rules?

[marcelloc]

@tjbp:

I see… so my firewall is blocking handshake responses, and thereby negating potential connections? If so, is it doing that because these packets are failing to be matched by any of my rules?

Not at all, as you are using torrent on this server, maybe firewall is just doing his job denying access to fake syn ack connections without syn win first.

[tjbp]

@marcelloc:

Not at all, as you are using torrent on this server, maybe firewall is just doing his job denying access to fake syn ack connections without syn win first.

Well perhaps, but considering the source is 192.168.2.2, wouldn't that mean my own machine is sending fake SYN ACK packets?

[jimp]

They could be real but routed another way. The most common way to see those logs are when you have asymmetric routing.

A –- path1 ---> B
A <-- path2 ---- B

The SYN went on path1 some other way, the SYN/ACK went path2, and since it wasn't a SYN and there was no state, it was blocked.

Multi-homed hosts or multiple routers between the networks are two easy ways that can happen.

[tjbp]

I can see how that could happen, but the machine in question only has one network card, and there's only one gateway configured (the pfSense box). The WAN interface on the router does connect to another router (a modem), but that modem doesn't share a subnet with nor is it physically attached to the same switch as the DMZ, so I'm pretty sure there isn't an asymmetric route available…

[cmb]

Blocking SA is one of two things - either the firewall isn't getting the SYN (asymmetric routing most commonly), or it's a spoofed SYN ACK that wasn't preceded by a SYN.