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

    Created WAN NAT but still seeing Default deny rule IPv4 (1000000103)

    Scheduled Pinned Locked Moved NAT
    7 Posts 3 Posters 281 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.
    • midnightfmM
      midnightfm
      last edited by

      I am trying to open up the pfSense to allow LDAP/S to populate a user directory in our spam-filter as part of the email journaling process. I've already created the LDAP service account and I've created the NAT/WAN Rules in pfSense.

      NATs:
      Type: Port Forward
      Enabled: Yes
      Interface: WAN
      Protocol: TCP
      Source Address: The public IPs and IP ranges specified by the spam-filter company (there are multiple NATs, one for each host or range)
      Source Ports: *
      Dest. Address: The private IP of the domain controller
      Dest. Ports: 636
      NAT IP: The private IP of the domain controller
      NAT Ports: 636

      Rules:
      Type: WAN
      Enabled: Yes
      Protocol: IPv4 TCP
      Source: The public IPs and IP ranges specified by the spam-filter company (there are multiple rules, one for each host or range)
      Port: *
      Destination: The private IP of the domain controller
      Port: 636
      Gateway: *
      Queue: none

      In the spam-filter I entered the public IP of the domain controller as the LDAP host and 636 as the port. The test fails to connect and I can see in the pfSense logs that the traffic is being blocked by the Default deny rule IPv4 (1000000103), which I understand applies at the bottom of the rule list. I made sure the NATs and WAN Rules are enabled and the changes have been Applied, so I'm not sure why traffic is seemingly not being picked up by my NATs and Rules, when I can clearly see the source IP in the logs matches the IP in NAT/Rule.

      Any help is appreciated. Thanks.

      Aaron

      V N 2 Replies Last reply Reply Quote 0
      • V
        viragomann @midnightfm
        last edited by viragomann

        @midnightfm said in Created WAN NAT but still seeing Default deny rule IPv4 (1000000103):

        In the spam-filter I entered the public IP of the domain controller as the LDAP host and 636 as the port.

        Dest. Address: The private IP of the domain controller
        Dest. Ports: 636

        So the destination in the NAT rule has to be the public IP, not private.
        in the filter rule, the you have to state the private IP (behind NAT) if you configure it manually.

        1 Reply Last reply Reply Quote 1
        • N
          NickD 0 @midnightfm
          last edited by

          @midnightfm On your NAT rule change the Dest. Address to the public IP you have chosen for your DC. If that is your firewall WAN address then use that or the built-in "WAN Address" alias. The firewall processes NAT before firewall rules so the NAT rule needs the public IP of the DC. This doc will help:

          https://docs.netgate.com/pfsense/en/latest/nat/process-order.html

          Also, you can change the Source Address in the NAT rule to be * ANY since your firewall rule is already restricted to the spam-filter source addresses. That will simplify troubleshooting and eliminate any ambiguity. You note in the NAT source address there are multiple NATs one for each host or range, if you change the source address NAT to * ANY then you only need the single NAT rule. Then you simply rely on your firewall rules to handle the filtering.

          midnightfmM 1 Reply Last reply Reply Quote 1
          • midnightfmM
            midnightfm @NickD 0
            last edited by

            @NickD-0 I really appreciate your response. The change of the dest. address from private to public/WAN address makes sense to me since the NAT points to the private IP as the redirect anyway. I've also consolidated the NAT rules into a single NAT using "Source: * ANY" and then made sure to disable the WAN Rule that was automatically created.

            So now I have a single NAT Port Forward using Source: * ANY, Dest: DC public IP, and Redirect: DC private IP, and several WAN Rules that route the spam-filter hosts/ranges to "WAN address" on 636, and I made sure to apply the changes.

            I wish I could say that fixed my issue, but I'm still seeing the Default Block Rule being applied in the System Logs. I went back in and tried changing "WAN address" to the DC public IP, but same results.

            I also ran netstat -aon | find "636" on the DC and confirmed nothing is listening.

            Aaron

            N 1 Reply Last reply Reply Quote 0
            • N
              NickD 0 @midnightfm
              last edited by

              @midnightfm said in Created WAN NAT but still seeing Default deny rule IPv4 (1000000103):

              and several WAN Rules that route the spam-filter hosts/ranges to "WAN address" on 636

              You need to use the DC's private IP address for the WAN filtering rule as the destination. Recall for inbound WAN traffic the rule order is NAT then filter, so your inbound WAN filtering rules see packets with the DC private IP as the NAT rules already translated the packets.

              I'm not sure why your DC doesn't have 636 listening but that's going to be an issue once you get the firewall squared away.

              midnightfmM 1 Reply Last reply Reply Quote 1
              • midnightfmM
                midnightfm @NickD 0
                last edited by

                @NickD-0 thanks, I see the Barracuda spam-filter traffic in the logs being passed now.

                I realized my choice of words regarding netstat was confusing. It's listening on 636; I should have said I wasn't seeing the spam-filter traffic when I run that command. Actually I'm still not and I'm still getting a "can't contact LDAP server" error in Barracuda, but it sounds like it may no longer be a firewall issue, so I'll raise a ticket with Barracuda.

                Appreciate all the help and patience.

                Aaron

                N 1 Reply Last reply Reply Quote 1
                • N
                  NickD 0 @midnightfm
                  last edited by

                  @midnightfm Good to hear the firewall side is resolved. Sounds like you'll need to dig into some Windows event logs to diagnose the barracuda LDAPS issue. I'd expect to at least see failed connection and/or authentication attempts on the DC in the event logs.

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