NAT Trouble...

CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
90% of the time when I try to ping PC to PC on my NAT setup it will fail, 10% of the time it will work.

I slowed down the simulation in packet tracer to follow the packet and what happens is when the packet is on the RETURN trip to its destination, when it arrives at that networks switch, it just stops and the switch broadcast STP packets to every PC. Whats wrong here?

Comments

  • fluk3dfluk3d Member Posts: 141 ■■■□□□□□□□
    can you post your config?
    "Imagination is more important than knowledge." - Albert Einstein
  • CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
    Router 1
    Router#show run
    Building configuration...
    
    Current configuration : 741 bytes
    !
    version 12.4
    no service timestamps log datetime msec
    no service timestamps debug datetime msec
    no service password-encryption
    !
    hostname Router
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    spanning-tree mode pvst
    !
    !
    !
    !
    interface FastEthernet0/0
     ip address 10.10.10.1 255.255.255.240
     ip nat inside
     duplex auto
     speed auto
    !
    interface FastEthernet0/1
     no ip address
     duplex auto
     speed auto
     shutdown
    !
    interface Serial0/1/0
     ip address 176.154.89.1 255.255.255.0
     ip nat outside
     clock rate 2000000
    !
    interface Vlan1
     no ip address
     shutdown
    !
    ip nat inside source list 1 interface Serial0/1/0 overload
    ip classless
    ip route 0.0.0.0 0.0.0.0 Serial0/1/0 
    !
    !
    access-list 1 permit 10.10.10.0 0.0.0.255
    !
    !
    !
    !
    !
    line con 0
    line vty 0 4
     login
    !
    !
    !
    end
    

    Router 2
    Router#show run
    Building configuration...
    
    Current configuration : 725 bytes
    !
    version 12.4
    no service timestamps log datetime msec
    no service timestamps debug datetime msec
    no service password-encryption
    !
    hostname Router
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    spanning-tree mode pvst
    !
    !
    !
    !
    interface FastEthernet0/0
     ip address 192.168.10.1 255.255.255.240
     ip nat inside
     duplex auto
     speed auto
    !
    interface FastEthernet0/1
     no ip address
     duplex auto
     speed auto
     shutdown
    !
    interface Serial0/1/0
     ip address 176.154.89.2 255.255.255.0
     ip nat outside
    !
    interface Vlan1
     no ip address
     shutdown
    !
    ip nat inside source list 1 interface Serial0/1/0 overload
    ip classless
    ip route 0.0.0.0 0.0.0.0 Serial0/1/0 
    !
    !
    access-list 1 permit 192.168.10.0 0.0.0.255
    !
    !
    !
    !
    !
    line con 0
    line vty 0 4
     login
    !
    !
    !
    end
    
  • pcgizzmopcgizzmo Member Posts: 127
    Sounds like the problem is in the switch and not the routers. What is the switch config?
  • CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
    no configs have been done on the switch. It happens with both switches too - and I have removed / reinstalled the switches as well.
  • fluk3dfluk3d Member Posts: 141 ■■■□□□□□□□
    CompUBug wrote: »
    no configs have been done on the switch. It happens with both switches too - and I have removed / reinstalled the switches as well.

    Have you tried deleting the vlan.dat database on the switch and just doing a factory restore?
    "Imagination is more important than knowledge." - Albert Einstein
  • MAC_AddyMAC_Addy Member Posts: 1,740 ■■■■□□□□□□
    fluk3d wrote: »
    Have you tried deleting the vlan.dat database on the switch and just doing a factory restore?
    +1 on this to test it out. I had erased all running-configs on a couple of my switches and could get some things to work. Turns out nearly every port belonged to it's own VLAN. It also looks like your access list is denying the 172 addy.
    2017 Certification Goals:
    CCNP R/S
  • CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
    Just tried that, same results - also added the 176.154.89.0 network to access-list 1... no effect.
  • MAC_AddyMAC_Addy Member Posts: 1,740 ■■■■□□□□□□
    Try changing the speed/duplex. I've had many problems with them being set on auto.
    2017 Certification Goals:
    CCNP R/S
  • CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
    on the router?
  • MAC_AddyMAC_Addy Member Posts: 1,740 ■■■■□□□□□□
    Yep, on the router.
    2017 Certification Goals:
    CCNP R/S
  • mella060mella060 Member Posts: 198 ■■■□□□□□□□
    CompUBug wrote: »
    it just stops and the switch broadcast STP packets to every PC. Whats wrong here?

    I don't know if this will help, but have you tried configuring spanning tree portfast on the port connected to the PC ?
  • gosh1976gosh1976 Member Posts: 441
    packet tracer is buggy. If you start fresh and rebuild the network it will probably work fine.
  • mbrdmyrmbrdmyr Registered Users Posts: 3 ■□□□□□□□□□
    Where is your NAT pool? I see the access list, but there isnt a pool for it to translate to. If you are, in fact using NAT, you can issue the show ip nat translations command to see if anything is being translated. but if you are not actually using the NAT, then I would check if you have trunk links going to the routers from the switches or the switchport accesses.

    And I did notice that someone said that packet tracer is buggy, which is 100% correct. Save what you are working on, close it and reopen, see if that fixes anything. I had trouble deleting a command on a router, when I closed it and reopened it, I was able to delete the command right away.

    Good Luck!
  • fluk3dfluk3d Member Posts: 141 ■■■□□□□□□□
    mbrdmyr wrote: »
    Where is your NAT pool? I see the access list, but there isnt a pool for it to translate to. If you are, in fact using NAT, you can issue the show ip nat translations command to see if anything is being translated. but if you are not actually using the NAT, then I would check if you have trunk links going to the routers from the switches or the switchport accesses.

    And I did notice that someone said that packet tracer is buggy, which is 100% correct. Save what you are working on, close it and reopen, see if that fixes anything. I had trouble deleting a command on a router, when I closed it and reopened it, I was able to delete the command right away.

    Good Luck!

    The NAT pool is defined by access list 1 with PAT correct me if I'm wrong
    "Imagination is more important than knowledge." - Albert Einstein
  • ciscoman2012ciscoman2012 Member Posts: 313
    MAC_Addy wrote: »
    Try changing the speed/duplex. I've had many problems with them being set on auto.

    I agree. I've had problems like this where everything looks correct but doesn't work. I'd also hard code the speed (100) and duplex (full) on the switch ports connected to the router as well as the router itself.
  • ChevelleChevelle Member Posts: 2 ■■■□□□□□□□
    You access-lists are wrong.
    interface FastEthernet0/0
     ip address 10.10.10.1 255.255.255.240
     ip nat inside
     duplex auto
     speed auto
    !
    access-list 1 permit 10.10.10.0 0.0.0.255
    
    interface FastEthernet0/0
     ip address 192.168.10.1 255.255.255.240
     ip nat inside
     duplex auto
     speed auto
    !
    access-list 1 permit 192.168.10.0 0.0.0.255
    
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Chevelle wrote: »
    You access-lists are wrong.

    Care to elaborate on why you think they're wrong?
  • boredgameladboredgamelad Member Posts: 365 ■■■■□□□□□□
    Alright, I dumped this in packet tracer and made a few assumptions. I configured PC1 and PC2 as 10.10.10.2 and 192.168.10.2, respectively. I also assumed you were pinging from PC1's command line to 192.168.10.2.

    Here are the translation tables as the first packet passes through both routers. The failure occurs when R1 drops the packet as returned by R2.

    R1:
    Router#show ip nat trans
    Pro  Inside global     Inside local       Outside local      Outside global
    icmp 176.154.89.1:9    10.10.10.2:9       192.168.10.2:9     192.168.10.2:9
    

    R2:
    Router#show ip nat trans
    Pro  Inside global     Inside local       Outside local      Outside global
    icmp 176.154.89.2:9    192.168.10.2:9     176.154.89.1:9     176.154.89.1:9
    

    First, R1 translates 10.10.10.2 to 176.154.89.1. The packet is then forwarded out S0/1/0 with the following source and destination addresses:

    Source: 176.154.89.1
    Destination: 192.168.1.2

    This is important to note because the echo-request that is sent by R1 has a destination of 192.168.1.2, so any echo-replies received should come from that address as well.

    Everything will proceed fine until the packet is returned by R2 to R1. When R2 receives the echo-reply from PC2, it translates 192.168.1.2 to 176.154.89.2 and sends a packet out S0/1/0 with the following:

    Source: 172.154.89.2
    Destination: 172.154.89.1

    Do you see the problem? R1 is expecting a reply from 192.168.1.2, but the above packet has a source IP address of 172.154.89.2.

    The router tries to match the incoming packet to its NAT translation table. As you can see, there's no entry for 176.154.89.2 on R1's translation table, so it attempts to process it like any normal packet. And, since R1 hasn't sent an echo-request to 176.154.89.2, ICMP drops the echo-reply.

    ==========

    Note that if you're using PT's simulation mode, a really handy tool is to look in the Event List on the upper right side of packet tracer and click on the colored box next to the event you want to examine further. You can then view what happens as the packet is received and passed up/down each layer, at each step of the way. In this instance you'll see the following on layer 3:
    1. The packet is coming from an outside network. The router looks up its NAT table for necessary translations.
    2. The NAT table does not have a matched entry for this packet. It passes the packet through without translations.
    3. The destination IP address matches the IP address of one of the  interfaces. The router dispatches the packet to the upper layer.
    4. The packet is an ICMP packet. The ICMP process processes it.
    5. The ICMP process received an Echo Reply message.
    6. The ICMP process has not sent an ICMP message with this identification recently. It drops the message.
    

    When I first started my Cisco studies I found this extremely useful for understanding how data is processed at each layer.
  • boredgameladboredgamelad Member Posts: 365 ■■■■□□□□□□
    Oh wait, it's failing at the switches for you? Hm, now, that's different than what I'm experiencing.
  • CompUBugCompUBug Member Posts: 46 ■■□□□□□□□□
    Oh wait, it's failing at the switches for you? Hm, now, that's different than what I'm experiencing.

    Yeah. The Routers forward it just fine BOTH DIRECTIONS but the switches 90% of the time **** the packet and broadcast STP packets to every node and 10% of the time forward the packet to the destination for a successful ping even though I didn't change anything.

    I pinged both ways but I used global addresses and not local addresses as if I used a local address it should be dropped as the Router on the opposite side shouldn't know where to find that address (as it should be listed as a global address)
  • boredgameladboredgamelad Member Posts: 365 ■■■■□□□□□□
    Can you upload your .pkt file?
Sign In or Register to comment.