NAT Trouble...

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?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

fluk3d

can you post your config?

CompUBug

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

pcgizzmo

Sounds like the problem is in the switch and not the routers. What is the switch config?

CompUBug

no configs have been done on the switch. It happens with both switches too - and I have removed / reinstalled the switches as well.

fluk3d

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?

MAC_Addy

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.

CompUBug

Just tried that, same results - also added the 176.154.89.0 network to access-list 1... no effect.

MAC_Addy

Try changing the speed/duplex. I've had many problems with them being set on auto.

CompUBug

on the router?

MAC_Addy

Yep, on the router.

mella060

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 ?

gosh1976

packet tracer is buggy. If you start fresh and rebuild the network it will probably work fine.

mbrdmyr

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!

fluk3d

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

ciscoman2012

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.

Chevelle

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_GA

Chevelle wrote: »

You access-lists are wrong.

Care to elaborate on why you think they're wrong?

boredgamelad

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.

boredgamelad

Oh wait, it's failing at the switches for you? Hm, now, that's different than what I'm experiencing.

CompUBug

boredgamelad wrote: »

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)

boredgamelad

Can you upload your .pkt file?