acl based natting

[hashbang]

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]

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

[hashbang]

@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]

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

[hashbang]

@dennis_s
ty, can it be blocked with acl ?

[Derelict]

@hashbang

Can what, specifically, be blocked?

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

[hashbang]

@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

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