Navigation

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

    acl based natting

    TNSR
    4
    8
    214
    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.
    • H
      hashbang last edited by

      Hi,
      example shows catchall kind of natting. I want to nat only based on acl. kindly advise how to do it.

      thanks and regards

      dennis_s 1 Reply Last reply Reply Quote 0
      • dennis_s
        dennis_s Netgate @hashbang last edited by

        @hashbang ACL and NAT are completely separate, so there is no "ACL based NAT". Explained in more detail here.

        H 1 Reply Last reply Reply Quote 0
        • H
          hashbang @dennis_s last edited by

          @dennis_s
          hi,
          ty, My purpose is to limit outbound nat on some subnets. where do i apply acl on outbound if or inbound if.

          thanks

          dennis_s 1 Reply Last reply Reply Quote 0
          • dennis_s
            dennis_s Netgate @hashbang last edited by

            @hashbang Selectively excluding traffic from NAT is not currently possible. I am not sure when it will be available, but this is something that is on our radar for future releases.

            H 1 Reply Last reply Reply Quote 1
            • H
              hashbang @dennis_s last edited by

              @dennis_s
              ty, can it be blocked with acl ?

              Derelict 1 Reply Last reply Reply Quote 0
              • Derelict
                Derelict LAYER 8 Netgate @hashbang last edited by

                @hashbang

                Can what, specifically, be blocked?

                Please be specific. Source protocol/address/port, Dest protocol/address/port, Interface numbering, etc.

                H 1 Reply Last reply Reply Quote 0
                • H
                  hashbang @Derelict last edited by

                  @derelict
                  ty, sorry for not being specific.
                  I want some subnets like managment vlans etc not be natted. So can i block them from being natted through acl on outbound interface.
                  thanks

                  C 1 Reply Last reply Reply Quote 0
                  • C
                    carton @hashbang last edited by carton

                    In IOS, the choice of NAT global address pool (or the choice of none at all to disable NAT) can be based on evaluation of an access list or a route map:

                    https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13739-nat-routemap.html

                    TNSR does not have named NAT pools, just one nameless global pool per VRF (and, I guess, a "twice-nat" pool per VRF). Unfortunately the capability to choose "no pool at all" was lost along with the capability to choose among pools!

                    That said I hope you will not emulate Cisco's NAT configuration because it's an incomprehensible disaster, especially when VRF are involved.

                    Some of these configurations could possibly be achieved more simply than Cisco by a feature to recirculate the packet:

                    interface looppair natswitch
                     instance 10
                    
                    interface loopnexthop10
                     enable
                    
                    interface looprecirculated10
                     enable
                     nat inside
                    
                    interface outside0
                     ip address 123.0.1.1/24
                     enable
                     nat outside
                    
                    nat pool interface outside0
                    
                    route ipv4 table ipv4-VRF:0
                     route 123.0.10.0/24
                      next-hop 0 via 123.0.1.2  # no NAT
                     route 0.0.0.0/0
                       next-hop 0 via 9.9.9.9 loopnexthop10 resolve-via-attached  # yes NAT
                    

                    Combined with a hypothetical policy-routing feature that could consider source IP in routing decisions this could handle having a mix of rfc1918 and globally-routable hosts behind a single "inside" interface. For example, route source IP 10.0.0.0/8 via loopnexthop10, and route source IP 123.0.20.0/24 via outside0 directly.

                    It creates a problem that 123.0.1.2 is directly attached to outside0 so, if NAT is wanted for that destination address, it's difficult to ignore outside0's automatically-added direct route. The hypothetical policy-routing(*) feature could fix that, too, by considering ingress interface in routing decisions. Ingress interface looprecirculated10 will use the VRF's ordinary table, while inside0 ingress interface will policy override and send 123.0.1.0/24 via loopnexthop10 at higher priority than the directly-attached route.

                    Recirculation solves most VRF problems with three simple rules:

                    • outside and inside interfaces don't need to be in the same VRF.
                    • to create or freshen a dynamic translation, the packet must enter a 'nat inside' interface and leave a 'nat outside' interface
                    • to match an existing static or dynamic translation, the packet must enter a 'nat outside' interface. It doesn't matter where it exits because that's not known at the time of translation. However the translation may move the packet to a different VRF before routing table lookup if the VRFs differed when the dynamic translation was created.

                    The only things missing are:

                    • policy routing
                    • nat static mapping ... route-table outside-vrf local-route-table inside-vrf
                      (yes, one could add a "via .. next-hop-table" route to <local address> pointing to the other VRF, but this is not general enough. There's no reason <local address> shouldn't still be reachable directly in outside-vrf. The nat static rule should not have to cast a shadow over it. Also there may be 10 inside-vrfs all having local 192.168.1.1 port 22 listening, and we want to use <external ip> port 2220, 2221, ... 2229 to reach each of them.)
                    • ability to bind 'nat pool' to 'nat outside' interface.

                    --
                    (*) Unfortunately if 'via classify <table>' was the syntax planned for policy routing, that syntax may not work intuitively because the directly-attached outside0 subnet route needs to be overriden, not passed through a layer of indirection.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post

                    Products

                    • Platform Overview
                    • TNSR
                    • pfSense
                    • Appliances

                    Services

                    • Training
                    • Professional Services

                    Support

                    • Subscription Plans
                    • Contact Support
                    • Product Lifecycle
                    • Documentation

                    News

                    • Media Coverage
                    • Press
                    • Events

                    Resources

                    • Blog
                    • FAQ
                    • Find a Partner
                    • Resource Library
                    • Security Information

                    Company

                    • About Us
                    • Careers
                    • Partners
                    • Contact Us
                    • Legal
                    Our Mission

                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                    Subscribe to our Newsletter

                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                    © 2021 Rubicon Communications, LLC | Privacy Policy