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

    Firewall blocking traffic TCP:PA

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 4 Posters 8.1k 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.
    • J
      jarlel
      last edited by

      I have some issues with traffic being blocked. It is listed in the system logs (firewall) as proto TCP:PA.
      I have read about this and that it helps changing the firewall optimization to "conservative", but it still blocks that traffic. I have also added rules that explicitly should let traffic from that device through.

      This traffic is TCP Ping (used for keep-alive between two devices) where a TCP packet packet is sent from one device with PSH/ACK where the other device is supposed to answer with ACK.

      Any ideas on how I can get this traffic through?

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        Can either side initiate the connection or is it one direction all the time? If it is bi-directional, then you will need to create a WAN rule and a LAN rule for traffic originating on the same side. On the WAN, you will probably also need to create a NAT rule unless it is in the WAN subnet.

        In the advanced section, there is a place to allow or disallow certain TCP flags. Perhaps you can utilize that.

        1 Reply Last reply Reply Quote 0
        • J
          jarlel
          last edited by

          Hi, thanks.

          It can be bi-directional. I have created a rule for the LAN-WAN communication and also a NAT-rule for the WAN-LAN communication (with auto-generated FW rule).
          I see that the packets have "IP Options" set (NOP), so I might need to check the box (Enable) beside the text "This allows packets with IP options to pass" in the advanced section?

          1 Reply Last reply Reply Quote 0
          • P
            podilarius
            last edited by

            Most likely. But you should only do that for the rule that passes this traffic. If you have a default allow rule, add one above it to handle only this traffic. You don't want that on all traffic.

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

              Odd way to do a TCP ping, that will fail on every worthwhile firewall. Not an active connection and not a SYN, every firewall will block that. Should send a SYN only as a TCP ping, get a SYN ACK in response, and RST that. Basically what hping does on a TCP ping.

              You can loosen up the acceptable TCP flags on a per-rule basis, but I'd be very specific on the rule where you do so. And keep in mind if any other firewalls are introduced at any point in between, they're going to block that too. If you can fix the TCP ping to be a proper TCP ping (SYN, SYN ACK, RST), that's a much more desirable solution.

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                Curious – what devices are they that do that?  Are they really designed to be on the same segment.  I would think any stateful firewall would block that by default.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                1 Reply Last reply Reply Quote 0
                • J
                  jarlel
                  last edited by

                  Thanks.

                  It's a Satellite modem and antenna controller using the OpenAMIP protocol. I managed to get the traffic through after adjusting the tcp flag options, allowing "any" flag to be set.
                  The initial communication establishment seems to be a standard SYN/SYN ACK sequence.

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