Is router-generated traffic considered inside NAT?

Discussion in 'Cisco' started by Dan Lanciani, Oct 25, 2006.

  1. Dan Lanciani

    Dan Lanciani Guest

    Is traffic generated by the router itself implicitly assumed to
    be received on a "ip nat inside" interface? This appears to be
    the case since I can mark one interface "ip nat outside", no interface
    "ip nat inside", and still translate the router's telnet server's
    port with "ip nat inside source static".

    Dan Lanciani
    [email protected]*com
     
    Dan Lanciani, Oct 25, 2006
    #1
    1. Advertisements

  2. 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
     
    headsetadapter.com, Oct 26, 2006
    #2
    1. Advertisements

  3. 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.
     
    Martin Gallagher, Oct 26, 2006
    #3
  4. 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
     
    headsetadapter.com, Oct 27, 2006
    #4
  5. Dan Lanciani

    Dan Lanciani Guest

    | 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
    [email protected]*com
     
    Dan Lanciani, Oct 27, 2006
    #5
  6. Here it is with debugs and using E1/0's address. You can see port
    translated from 23<->2323.

    *****************
    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#
    **********************
     
    Martin Gallagher, Oct 28, 2006
    #6
  7. Not quite correct. See NAT Order of Operation,
    http://www.cisco.com/warp/public/556/5.html, for the DS solution.

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

    For Outside-to-Inside the packet is natted then routed.
     
    Martin Gallagher, Oct 28, 2006
    #7
  8. Dan Lanciani

    Bod43 Guest


    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
     
    Bod43, Oct 28, 2006
    #8
  9. 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.
     
    Martin Gallagher, Oct 29, 2006
    #9
  10. Dan Lanciani

    Bod43 Guest

    Thanks.

    I guess that I had assumed that to get NATted traffic had to pass from
    nat inside to nat outside or vice versa.
     
    Bod43, Nov 3, 2006
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.