Is router-generated traffic considered inside NAT?

Dan,

Usually router uses "closest" interface. For example, if you are trying to ping something on the Internet, it will use an Outside interface's IP address as the source. For "ping" command you can use an "advanced configuration" (issue ping command without parameters), and specify a source interface, but I don't think it will go to NAT translation, since NAT INSIDE is configured on the physical interface.

Good luck,

Mike

Yep. NAT is applied to packets that cross the router from an inside to an outside interface, and also to locally generated packets. Packets from the router's telnet daemon are caught by the second case.

It's not true. There are a "track" how packet goes. First it enters the interface, then it applies "in" access list, if packet matches access-list for NAT, then packet is sent to "NAT engine". After translation takes place, packet presented to routing engine, which makes decision where to send the packet. In case of internal traffic, the packet sent directly to "routing engine" without been treated by NAT, since it's never "enters" the "nat inside" interface.

There is a way to do NAT independently. It's named "NAT on the stick". You configure loopback interface, and create policy based routing to send all packets to the loopback interface. In this case if you define loopback interface as "nat inside" or "nat outside", the packet will be NAT'ed, and then sent to the routing engine.

If you want to make sure it's true, do "debug ip packet" on the router, and try to ping something. You will see source and destination of packets when they go through the router.

Good luck,

Mike

| It's not true. There are a "track" how packet goes. First it enters the | interface, then it applies "in" access list, if packet matches access-list | for NAT, then packet is sent to "NAT engine". After translation takes place, | packet presented to routing engine, which makes decision where to send the | packet. In case of internal traffic, the packet sent directly to "routing | engine" without been treated by NAT, since it's never "enters" the "nat | inside" interface.

It doesn't seen to be that simple. Picking xx on the same subnet as an existing address of e0 with no other nat configuration on the router:

int e0 ip address xx 255.255.255.0 secondary ip nat outside exit

ip nat inside source static tcp xx 23 xx 9999

Now "telnet xx 9999" from a machine on e0's network connects to the router's telnet server, at least with IOS 12.2(32). Somehow packets from the telnet server are getting to the "NAT engine." I don't know if it would make a difference if I used the primary address. Some other tests with "ip nat outside source static" appeared to produce bogus mappings so it may be that you can neither rely on internal traffic to be NAT'ed nor rely on it not to be NAT'ed. :(

Dan Lanciani ddl@danlan.*com

Here it is with debugs and using E1/0's address. You can see port translated from 232323.

***************** DHCP_Server#sh runn int e1/0 Building configuration...

Current configuration : 85 bytes ! interface Ethernet1/0 ip address dhcp ip nat outside ip virtual-reassembly end

DHCP_Server# DHCP_Server# DHCP_Server#sh runn | i ip nat ip nat outside ip nat log translations syslog ip nat inside source static tcp 192.168.1.102 23 192.168.1.102 2323 extendable DHCP_Server# DHCP_Server# DHCP_Server#deb ip nat IP NAT debugging is on DHCP_Server#deb ip nat det IP NAT detailed debugging is on DHCP_Server# DHCP_Server# DHCP_Server#deb ip pa IP packet debugging is on DHCP_Server# %IPNAT-6-NAT_CREATED: Created tcp 192.168.1.102:23 192.168.1.102:2323 192.168.1.100:42129 192.168.1.100:42129 NAT*: o: tcp (192.168.1.100, 42129) -> (192.168.1.102, 2323) [2021] NAT*: o: tcp (192.168.1.100, 42129) -> (192.168.1.102, 2323) [2021] NAT*: TCP s=42129, d=2323->23 IP: tableid=0, s=192.168.1.100 (Ethernet1/0), d=192.168.1.102 (Ethernet1/0), routed via RIB IP: s=192.168.1.100 (Ethernet1/0), d=192.168.1.102 (Ethernet1/0), len 60, rcvd 3 IP: tableid=0, s=192.168.1.102 (local), d=192.168.1.100 (Ethernet1/0), routed via RIB IP: s=192.168.1.102 (local), d=192.168.1.100 (Ethernet1/0), len 44, sending NAT: i: tcp (192.168.1.102, 23) -> (192.168.1.100, 42129) [40284] NAT: TCP s=23->2323, d=42129 DHCP_Server#u all All possible debugging has been turned off DHCP_Server#

***************

Here it is again with a dynamic PAT. The telnet traffic matches ACL 1 and gets translated. This is a bad config because the port 23 gets changed to port 1, the telnet client is expecting port 23. This why you don't want to use 'permit ip any' in a NAT access-list

See these lines: NAT: i: tcp (192.168.1.102, 23) -> (192.168.1.100, 51288) [7255] NAT: TCP s=23->1, d=51288

The 'i:' says this is inside traffic as far as nat is concerned.

*************** DHCP_Server#sh runn int e1/0 Building configuration...

Current configuration : 85 bytes ! interface Ethernet1/0 ip address dhcp ip nat outside ip virtual-reassembly end

DHCP_Server#sh runn | i ip nat ip nat outside ip nat log translations syslog ip nat inside source list 1 interface Ethernet1/0 overload DHCP_Server#sh ip nat stat Total active translations: 0 (0 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet1/0 Inside interfaces: Hits: 175 Misses: 2 CEF Translated packets: 104, CEF Punted packets: 0 Expired translations: 3 Dynamic mappings:

-- Inside Source [Id: 2] access-list 1 interface Ethernet1/0 refcount 0 Queued Packets: 0 DHCP_Server# DHCP_Server#sh access-lists 1 Standard IP access list 1 10 permit any (72 matches) DHCP_Server# DHCP_Server# DHCP_Server#deb ip nat IP NAT debugging is on DHCP_Server#deb ip nat det IP NAT detailed debugging is on DHCP_Server# ... IP: tableid=0, s=192.168.1.100 (Ethernet1/0), d=192.168.1.102 (Ethernet1/0), routed via RIB IP: s=192.168.1.100 (Ethernet1/0), d=192.168.1.102 (Ethernet1/0), len 60, rcvd 3 NAT: Allocated Port for SYSTEM prot 6: 192.168.1.102, 0 IP: tableid=0, s=192.168.1.102 (local), d=192.168.1.100 (Ethernet1/0), routed via RIB IP: s=192.168.1.102 (local), d=192.168.1.100 (Ethernet1/0), len 44, sending NAT: Allocated Port for 192.168.1.102 -> 192.168.1.102: wanted 23 got 1 %IPNAT-6-NAT_CREATED: Created tcp 192.168.1.102:23 192.168.1.102:1 192.168.1.100:51288 192.168.1.100:51288 NAT: i: tcp (192.168.1.102, 23) -> (192.168.1.100, 51288) [7255] NAT: TCP s=23->1, d=51288 NAT*: o: tcp (192.168.1.100, 51288) -> (192.168.1.102, 1) [19] NAT*: TCP s=51288, d=1->23 DHCP_Server#u all All possible debugging has been turned off DHCP_Server#

**********************

Not quite correct. See NAT Order of Operation,

for the DS solution.

For Inside-to-Outside the packet is routed then natted.

For Outside-to-Inside the packet is natted then routed.

I think that this issue has appeared due to Cisco having changed the implementation of NAT fairly recently.

I noticed that my outside address was being PATted (to it's own address) which broke something that I was doing. This was new behaviour that I had not noticed before. [This was for something like a telnet from the router.]

It no longer seems necessary for traffic to pass from a nat inside interface to a nat outside one to get NATted.

I don't understand the new model yet so cannot really advise except that I fixed my unwanted NAT by adding a deny for the outside interface address to my nat list.

Look up NVI - Nat Virtual Interface.

I seem to recall that I asked what an NVI was on this list recently and got a nice reference URL in reply but I can't find it in google groups right now.

ip access-l ext ACL.nat deny ip inside-interface-range crypto-target-range deny ip host outside-interface any permit ip inside-interface-range any

Translating local traffic has been around for a long time, possibly forever, and certainly well before NVI was introduced.

I have seen this many times when people add NAT to the router, use an access-list like "permit ip any" for the NAT, and then find they can't telnet to the router from outside any more. Changing the ACL so it only matches what they want to makes it better.

Seen it, not quite got my head around it. NVI is not a new way to do NAT though. It's there to make NAT possible/easier with VRF I believe.

Thanks.

I guess that I had assumed that to get NATted traffic had to pass from nat inside to nat outside or vice versa.