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



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



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



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



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



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



  • 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).



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



  • 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).



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



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


Log in to reply