Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    Super strange NAT problem that occurred for no reason at random

    Scheduled Pinned Locked Moved NAT
    8 Posts 4 Posters 3.0k Views 6 Watching
    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.
    • U Offline
      uncleasbestos
      last edited by

      Yesterday at around 2PM I got a call from one of our offices saying they are no longer able to receive inbound calls. Our system is a Mitel Office 250 that has been working fine for the past several years with no issues on a pfSense firewall made from a Dell Optiplex. None of the rules have changed in the firewall, our SIP provider confirmed it is our firewall blocking their traffic and I'm out of answers. I have tried rekeying all the rules from scratch, including the IP aliases (which I have confirmed several times match our providers suggest list of IPs to allow) and changed how the NAT rule is configured, even just enabling the "pass" option in the rule creation field and attempted to manually create a matching rule myself. All packets that are supposed to be allowed are being blocked by default deny rule. I'm about at the point where I'm going to reflash pfSense or replace the unit entirely. Screens below, any suggestions? Thanks a lot!
      Screenshot 2026-06-10 190902.png Screenshot 2026-06-10 190932.png Screenshot 2026-06-10 191056.png Screenshot 2026-06-10 191335.png

      KOMK GertjanG 2 Replies Last reply Reply Quote 0
      • KOMK Online
        KOM @uncleasbestos
        last edited by

        @uncleasbestos First thing I would try it to take the aliases out of the picture entirely. Rejig your rules to allow those explicit IPs instead of the alias. Post a redacted screen of your WAN rules. Are you using pfBlocker, or an IDS like Snort/Suricata? If yes to any, temporarily disable them.

        1 Reply Last reply Reply Quote 0
        • GertjanG Offline
          Gertjan @uncleasbestos
          last edited by

          @uncleasbestos

          fact-check the ISP (and any equipment upstream) : Go here : DiagnosticsPacket Capture
          and fill in the greens :

          916f7734-9a76-43bd-b643-3f64759dc3ee-image.png

          Instead of "1234" use your SIP destination port, and hit go ...

          As soon as SIP traffic traffic arrives at the WAN interface, you will see an output on the packet capture page. This is the "10 seconds check incoming NAT traffic" test.
          If nothing arrives at the pfSense WAN then ... undo everything, pfSense is fine, the issue is upstream.

          The 5 seconds test is even simpler :
          Look at your WAN firewall rules :
          0d5456f3-f504-48d7-ae02-df2a2325c8c9-image.png

          See the green counter in front of them ? That means the rules have found a match and are getting 'used'. If the counters stay zero, then they didn't match .... and finally the default firewall action (rule) kicks in : the "Default deny rule IPv4" message gets logged.

          No "help me" PM's please. Use the forum, the community will thank you.

          1 Reply Last reply Reply Quote 0
          • stephenw10S Offline
            stephenw10 Netgate Administrator
            last edited by

            That SIP traffic should be passed there if the source IP matches the hosts in the alias. But we can't see that in the redacted screenshots.

            Since it's not matching and hitting the default rule I have to assume the source IPs do not match the alias.

            1 Reply Last reply Reply Quote 0
            • U Offline
              uncleasbestos
              last edited by

              Hey, I really appreciate all the responses. pfBlocker and Snort are disabled in the sample I uploaded. I ran a packet capture as suggested and the SIP requests were definitely getting through to the firewall and being blocked by it. Also, no states were being created and the traffic counter stayed at 0 the whole time. I double checked the aliases and they were correct, but I took the step suggested above and rekeyed the rules using the actual addresses instead of an alias, traffic passed successfully.

              I have no idea at all why the alias would all of a sudden stop working correctly as I've never had that happen, but I'm glad we figured it out regardless.

              Thank you everyone and may your status lights stay bright and green.

              UncleAsbestos

              KOMK GertjanG 2 Replies Last reply Reply Quote 0
              • U Offline
                uncleasbestos
                last edited by

                Also, thank you for being kind in your responses.

                1 Reply Last reply Reply Quote 0
                • KOMK Online
                  KOM @uncleasbestos
                  last edited by

                  @uncleasbestos Happy to help. Glad you got it working.

                  1 Reply Last reply Reply Quote 0
                  • GertjanG Offline
                    Gertjan @uncleasbestos
                    last edited by

                    @uncleasbestos said in Super strange NAT problem that occurred for no reason at random:

                    I double checked the aliases and they were correct

                    So it looks like the firewall using rules with aliases, doesn't match these alases.

                    First, a less know secret : a firewall doesn't work or understand hosts names or aliases. A firewall can only work with IP addresses, when it concerns a source or destination.

                    Have a look at this file : /tmp/rules.debug.
                    This is the actual file, a list woth rules instructions, loaded into 'pf' the pfSense firewall.
                    Search for BCM_SIP.
                    You should find this :

                    ....
                    table <BCM_SIP> {   a.b.c.d ...... }
                    BCM_SIP= "<BCM_SIP>"
                    ....
                    

                    The a.b.c.d is (are) the IP addresses that were resolved from teh alias, if the alias contained a host name.
                    When I create a alias called :

                    534f6509-ba44-4387-80f3-3150b67e542e-image.png

                    Note : you saw :

                    FQDN hostnames are periodically re-resolved and updated. If multiple IPs are returned by a DNS query, all are used

                    and use it in a WAN firewall rule like :

                    31aff0a2-3bda-4dd8-b36d-73d7234ef5b0-image.png

                    I can find this in my /tmp/rules.debug :

                    ....
                    table <BCM_SIP> {   1.2.3.4 }
                    BCM_SIP = "<BCM_SIP>"
                    ....
                    

                    if the "BCM_SIP" was a FQDN, or something like "www.whatever-fqdn.tld" then this hos name is resolved every 5 minutes or so (see system settings for the frequency) and the resolved IP is entered into the firewall rule table.

                    Read : Alias Features and Limitations as it mentions important info.
                    There are still people out there that make an alias with 'www.facebook.com' and then find out it doesn't work as intended 😊

                    Anyway, now you have even more tools to check.

                    No "help me" PM's please. Use the forum, the community will thank you.

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