Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 4 Posters 8.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tjbp
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • marcellocM
        marcelloc
        last edited by

        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

        Treinamentos de Elite: http://sys-squad.com

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • T
          tjbp
          last edited by

          @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?

          1 Reply Last reply Reply Quote 0
          • marcellocM
            marcelloc
            last edited by

            @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.

            Treinamentos de Elite: http://sys-squad.com

            Help a community developer! ;D

            1 Reply Last reply Reply Quote 0
            • T
              tjbp
              last edited by

              @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?

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                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.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • T
                  tjbp
                  last edited by

                  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…

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.