acl based natting
example shows catchall kind of natting. I want to nat only based on acl. kindly advise how to do it.
thanks and regards
ty, My purpose is to limit outbound nat on some subnets. where do i apply acl on outbound if or inbound if.
@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.
ty, can it be blocked with acl ?
Can what, specifically, be blocked?
Please be specific. Source protocol/address/port, Dest protocol/address/port, Interface numbering, etc.
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.
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:
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 126.96.36.199/24 enable nat outside nat pool interface outside0 route ipv4 table ipv4-VRF:0 route 188.8.131.52/24 next-hop 0 via 184.108.40.206 # no NAT route 0.0.0.0/0 next-hop 0 via 220.127.116.11 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 18.104.22.168/24 via outside0 directly.
It creates a problem that 22.214.171.124 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 126.96.36.199/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.