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

    Auto-creation of outbound NAT rule for OPT in Firewall->NAT->Outbound ?

    Scheduled Pinned Locked Moved webGUI
    10 Posts 4 Posters 5.9k 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.
    • R
      rcarr
      last edited by

      When I provisioned my OPT-1 interface as a DMZ (172.20.1.0/24), rules.debug shows an outbound NAT rule automatically created for it (last rule):

      nat on $wan from 172.19.1.0/24 to any -> (fxp0)
      nat on $DMZ from 172.20.1.0/24 to any -> (fxp2)
      nat on $wan from 172.20.1.0/24 to any -> (fxp0)

      But the WebGUI for Firewall->NAT->Outbound only shows the auto-created rule for the LAN interface.  (See attached jpeg).

      Should I expect to see a rule in the GUI for the DMZ outbound NAT?

      What is the middle rule above for?  That was created automatically when the DMZ interface was provisioned, too.
      no-dmz-rule.jpg
      no-dmz-rule.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • D
        databeestje
        last edited by

        The nat rules should normally only be created for opt interfaces with a gateway.

        This looks like a bug. Needs further chasing. However I do not think you will ever trigger traffic on the NAT rule.
        That, because your DMZ is that network. And no traffic from the specified network will ever leave the DMZ interface. e.g. the 172.20.1.0/24 only lives on the dmz interface so it will never match.

        1 Reply Last reply Reply Quote 0
        • R
          rcarr
          last edited by

          Cool.  So at least the DMZ-specific NAT is not something I need to worry about.

          The nat rules should normally only be created for opt interfaces with a gateway.

          Really?  Shouldn't an outbound NAT on interface $wan be created for every interface subnet?

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            This is the LAN -> OPT mapping.

            If you wish to remove this simply turn on advanced outbound NAT.  The system will populate the entries that it is using behind the scenes giving you absolute control over those.

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              Actually scratch that.  There was a bug lurking.

              Please test a snapshot (RELENG_1_2) at least two hours from now to give it time to build.

              1 Reply Last reply Reply Quote 0
              • R
                rcarr
                last edited by

                I installed the latest 1.2 beta from 4/22.

                The strange NAT-on-DMZ rule disappeared from rules.debug.

                The WebGUI Firewall->NAT->Outbound still only shows the rule for NATing outbound connections from the LAN subnet.  It does not show the NAT for outbound connections from the DMZ subnet (though the rule does exist in rules.debug).

                1 Reply Last reply Reply Quote 0
                • D
                  databeestje
                  last edited by

                  That would be correct, when you click "enable ipsec passthrough" it is in automatic mode.

                  That means any manual rules below will not be used. When you click "Enable advanced outbound nat" the rules below will be used instead of the ones we would otherwise generate automatically.

                  1 Reply Last reply Reply Quote 0
                  • R
                    rcarr
                    last edited by

                    Ok, I think I understand.

                    I just think that the WebGUI should be WYSIWYG as much as possible.  If NAT->Outbound lists an explicit rule for NATing outbound from the LAN subnet, but doesn't list one for the DMZ subnet, then I should expect that there is no rule in place for the DMZ subnet (which is incorrect).

                    1 Reply Last reply Reply Quote 0
                    • S
                      sullrich
                      last edited by

                      If you want this type of firm control over the rules switch to advanced outbound nat.

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

                        @rcarr:

                        I just think that the WebGUI should be WYSIWYG as much as possible.  If NAT->Outbound lists an explicit rule for NATing outbound from the LAN subnet, but doesn't list one for the DMZ subnet, then I should expect that there is no rule in place for the DMZ subnet (which is incorrect).

                        No, that should only be correct if you're using Advanced Outbound NAT (AON). If AON is disabled, the default behavior is that you will get NAT'ed out the WAN and any OPT interface with a gateway since those are treated as additional WAN interfaces as well. With AON disabled, which is how probably 98% of installs run, you won't see any rules on the Outbound page unless you add them yourself. Even if you do add them, they have no effect unless AON is enabled. That page isn't a display of how your outbound NAT is functioning if you aren't using AON. And there should be no NAT'ing other than what you explicitly define on the Outbound tab if AON is enabled.

                        There is one known bug related to this right now, see ticket 1289. It looks like the problem you noted may be another bug created by the attempted fix on this ticket.
                        http://cvstrac.pfsense.com/tktview?tn=1289,6

                        If you notice other discrepancies from what I described above, it's a bug that needs to have a ticket opened.

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