Re: Simple NAT Issue

From: Edouard Zorrilla (ezorrilla@tsf.com.pe)
Date: Wed Feb 04 2009 - 10:05:35 ARST


Joe / Pavel :

Excuse, maybe I am mistaken, but I see that the local traffic is being
translated, in my base I have Lo0 on my routing proccess of OSPF so RackR5
can ping RackR4 doing a nat inside R5 itself:

My config:

Rack1R5#siib
Interface IP-Address OK? Method Status
Protocol
FastEthernet0/0 10.5.5.5 YES NVRAM up
up
Serial0/0 183.1.45.5 YES NVRAM up
up
Serial0/1.345 183.1.0.5 YES NVRAM up
up
Loopback0 150.1.5.5 YES NVRAM up
up
Loopback55 55.55.55.55 YES manual up
up
Rack1R5#

My inside Nat is Lo55 and my outside Nat is Lo0:

Rack1R5#sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  Loopback0
Inside interfaces:
  Loopback55
Hits: 9 Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 2
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 121 interface Loopback0 refcount 0
Queued Packets: 0
Rack1R5#

Route-Map that defines that traffic that goes from Lo55 must go thru Lo0:

Rack1R5#sh route-map MAP-A
route-map MAP-A, permit, sequence 10
  Match clauses:
    ip address (access-lists): 121
  Set clauses:
    interface Loopback0
  Policy routing matches: 9 packets, 900 bytes
Rack1R5#sh ip acc
Rack1R5#sh ip acce
Rack1R5#sh ip access-lists 121
Extended IP access list 121
    10 permit ip 55.55.55.0 0.0.0.255 any (12 matches)
Rack1R5#

I applied it localy inside R5 so that traffic is redirected on the router
itself:

Rack1R5# sh run | sec ip local
ip local policy route-map MAP-A
Rack1R5#

Now I perform a ping to R4 using Lo55 as a source address:

Rack1R5#ping 150.1.4.4 source loopback 55 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 55.55.55.55
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/2/4 ms

Translations works, you could see that inside local Lo55 (55.55.55.55) is
now Lo0 (150.1.5.5)

Rack1R5#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 150.1.5.5:4 55.55.55.55:4 150.1.4.4:4 150.1.4.4:4
Rack1R5#
*Feb 4 11:24:51.549: NAT: s=55.55.55.55->150.1.5.5, d=150.1.4.4 [17]
*Feb 4 11:24:51.553: NAT: s=55.55.55.55->150.1.5.5, d=150.1.4.4 [18]
Rack1R5#

So it means that router doing the NATing will actually NAT packets that it
generates. In this case, source Lo55 nated to Lo0. Let me know If I am
mistaken.

Regards.

----- Original Message -----
From: "Joe Astorino" <joe_astorino@comcast.net>
To: "'Pavel Bykov'" <slidersv@gmail.com>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, February 04, 2009 2:52 AM
Subject: RE: Simple NAT Issue

> Hmmmmm.... I was just doing some research on this, and it seems that this
> is
> a symptom when on the newer ISR routers that utilize the Nat Virtual
> Interface ("ip nat enable"). However, I thought that it only used the NVI
> if you used the "ip nat enable" commands and not the older style "ip nat
> inside" "ip nat ouside" commands. On my 3640 running 12.4.23 code even if
> I
> do "ip nat inside" and "ip nat outside" it immediately brings up/up
> interface NVI0. I wonder if all the newer code will not translate locally
> generated packets despite the command set you use?
>
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
>
> mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
> Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
> W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
> RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
> YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
> doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
> EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
> FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
> FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
> aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
> CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
> Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
> tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
> q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
> VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
> ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
> fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
> F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
> UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
> nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
> QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
> 1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
> L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
> DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
> 74k/eLaYWYqu7YI=
> =8HMA
> -----END PGP PUBLIC KEY BLOCK-----
>
>
>
>
>
>
> _____
>
> From: Pavel Bykov [mailto:slidersv@gmail.com]
> Sent: Wednesday, February 04, 2009 1:32 AM
> To: Joe Astorino
> Cc: ccielab@groupstudy.com
> Subject: Re: Simple NAT Issue
>
>
> Yeah, I'm pretty sure of that. Same as with access lists. Locally
> originated
> traffic just skips a lot of facilities.
> What it does not skip is QoS, but this is dependent on platform - if you
> originate packets on 12000, then it will skip QoS as well.
>
>
>
> On Wed, Feb 4, 2009 at 7:26 AM, Joe Astorino <joe_astorino@comcast.net>
> wrote:
>
>
> Thanks for the solution Pavel. Do you know if it is indeed true that a
> router doing the NATing will not actually NAT packets that it generates,
> even if the source address is in the NAT translation list? I seem to
> remember this sort of thing working on older versions of IOS.
>
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
>
> mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
> Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
> W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
> RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
> YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
> doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
> EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
> FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
> FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
> aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
> CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
> Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
> tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
> q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
> VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
> ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
> fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
> F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
> UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
> nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
> QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
> 1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
> L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
> DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
> 74k/eLaYWYqu7YI=
> =8HMA
> -----END PGP PUBLIC KEY BLOCK-----
>
>
>
>
>
>
> _____
>
> From: Pavel Bykov [mailto:slidersv@gmail.com]
> Sent: Wednesday, February 04, 2009 1:22 AM
> To: joe_astorino@comcast.net
> Cc: ccielab@groupstudy.com
> Subject: Re: Simple NAT Issue
>
>
> One of the solutions how to accomplish your goal is to use PBR and local
> policy.
> e.g.:
>
> route-map NAT
> set interface lo55
> !
> ip local policy route-map NAT
>
>
>
> On Wed, Feb 4, 2009 at 6:32 AM, <joe_astorino@comcast.net> wrote:
>
>
> I am having a problem regarding NAT and was hoping somebody could help me
> understand this. I have a router, R5 that I wish to do NAT translation so
> that anything sourced from its Loopback55 address will be translated to
> its
> Loopback1 interface. This way I can meet a requirement that I should be
> able
> to source a ping from Loopback55 and have it reply successfully without
> adding Loopback55 to any routing protocol.
>
> If I set this up the way I have below, and try a ping sourced from Lo55 it
> does not work...no translation occurs. I thought I remember hearing
> something at one point that the router doing the NAT translation won't NAT
> packets sourced from itself, only packets that pass through it, but I am
> not
> sure on that. Any ideas guys?
>
> Just to be sure, I have checked that I do have reachability to the address
> I
> am trying to ping when sourced from lo1.
>
> R5(config)#do sh ip int brie | i Loop
> Loopback1 99.99.99.5 YES manual up up
> Loopback55 55.55.55.55 YES manual up up
>
> R5(config)#do sh access-list 55
> Standard IP access list 55
> 10 permit 55.55.55.55
>
> R5(config)#do sh run int e0/0 | i ip nat
> ip nat outside
>
> R5(config)#do sh run int s2/0 | i ip nat
> ip nat outside
>
> R5(config)#do sh run int s2/0.56| i ip nat
> ip nat outside
>
> R5(config)#do sh run int s2/1 | i ip nat
> ip nat outside
>
> R5(config)#do sh run int lo1 | i nat
> ip nat outside
>
> R5(config)#do sh run int lo55 | i nat
> ip nat inside
>
> ip nat inside source list 55 interface lo1 overload
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Pavel Bykov
> ----------------
> Don't forget to help stopping the braindumps, use of which reduces value
> of
> your certifications. Sign the petition at http://www.stopbraindumps.com/
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1930 - Release Date: 02/02/09
> 07:51:00
>
>
>
>
>
> --
> Pavel Bykov
> ----------------
> Don't forget to help stopping the braindumps, use of which reduces value
> of
> your certifications. Sign the petition at http://www.stopbraindumps.com/
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.16/1930 - Release Date: 02/02/09
> 07:51:00
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:10 ARST