cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
674
Visitas
3
ÚTIL
6
Respuestas

Static NAT, Routing

violetta1405
Level 1
Level 1

Hi, I have already finished my NAT, DNS, Default route lab
From End users I can ping xoilac.xx and banhmy.xxx with DNS I set up in google DNS server
and CORP Router has NAT configuration like this:

interface FastEthernet0/0

ip address 6.9.6.10 255.255.255.0

ip nat outside

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 172.16.69.1 255.255.255.0

ip nat inside

duplex auto

speed auto

!

interface FastEthernet1/0

ip address 172.16.96.1 255.255.255.0

ip nat inside

duplex auto

speed auto

!

interface FastEthernet1/1

no ip address

duplex auto

speed auto

shutdown

interface Vlan1

no ip address

shutdown

router rip

ip nat inside source static 172.16.69.2 6.9.6.69

ip nat inside source static 172.16.96.2 6.9.6.96

ip classless

ip route 0.0.0.0 0.0.0.0 6.9.6.9

I am just wondering why I can't ping 6.9.6.69(the inside global ip of the server) on the server xoilac side itself. Please help me, thank you^^

violetta1405_0-1754989573464.png

 

1 SOLUCIÓN ACEPTADA

Soluciones aceptadas

Enes Simnica
Level 5
Level 5

hello @violetta1405 You can’t ping 6.9.6.69 from the xoilac server itself because NAT translations only occur when traffic passes through the router from an inside to an outside interface. When the server pings its own mapped public IP, the traffic never leaves the inside network, so NAT doesn’t apply and the return path fails. This is a common NAT hairpin/NAT loopback limitation, u’d need to configure NAT hairpinning or test from a device on the outside network.

hope it helps and PEACE!

 

-Enes

more Cisco?!
more Gym?!



If this post solved your problem, kindly mark it as Accepted Solution. Much appreciated!

Ver la solución en mensaje original publicado

6 RESPUESTAS 6

Enes Simnica
Level 5
Level 5

hello @violetta1405 You can’t ping 6.9.6.69 from the xoilac server itself because NAT translations only occur when traffic passes through the router from an inside to an outside interface. When the server pings its own mapped public IP, the traffic never leaves the inside network, so NAT doesn’t apply and the return path fails. This is a common NAT hairpin/NAT loopback limitation, u’d need to configure NAT hairpinning or test from a device on the outside network.

hope it helps and PEACE!

 

-Enes

more Cisco?!
more Gym?!



If this post solved your problem, kindly mark it as Accepted Solution. Much appreciated!

I see, thank you for your reply. 
In addition to this problem, i want to ask the followings:
1. The traffic never leaves the inside network. Does it mean the router knows it and not even trying to forward it to outside network (the internet). Below are some images, I can see it changes the destination IP to the default gateway(I don't know how to read these informations but I can see the destination IP is changed)
Then it forwards the packet to the default gateway. At the router CORP, I don't see it changes back to to 6.9.6.69 for the destination IP. Why?
2. Do you have any suggestions where I can learn these? thank you^^

violetta1405_0-1754994575291.png

violetta1405_1-1754994583079.png

 

hello @violetta1405 and Yes! by “traffic never leaves the inside network” I mean the packet is sent toward the router, but because both the source (172.16.69.2) and the destination (6.9.6.69) actually point to the same inside host, the router does not perform NAT in this path by default. In normal NAT, the router changes the destination IP only for packets going from inside - outside, matching a NAT rule. So, in ur case, the destination is the public IP of an inside host, but the router has no NAT hairpin/loopback rule, so it just tries to route it directly using the inside routing table. And this is why u don’t see the destination change back on the CORP router, it was never translated in the first place.

About the learning part, I would recommend: Packet tracer (and after u learn some stuff, go ahead and jump to GNS3 or EVEng). As for video trainings, check the Jeremy Ciaora youtube channel, or u can find him on CBTNuggets (he is just great!!) and read the official book. AND LAB LAB LAB LAB LAB, as much as u can.....

hope it helps, and PEACE!

 

-Enes 

more Cisco?!
more Gym?!



If this post solved your problem, kindly mark it as Accepted Solution. Much appreciated!

Thank you for your answer and your resources you recommended
I just want to ask some last questions:
1. " but because both the source (172.16.69.2) and the destination (6.9.6.69) actually point to the same inside host, the router does not perform NAT in this path by default"
Did you mean the router still perform translating and sees it's the same point so it doesn't change the information inside the packet when forwarding which means it will try to route directly using the inside routing table.

violetta1405_0-1755009621302.png

I wonder after reaching CORP where will it go? I find it confusing when I see some of them going way too far to ISP when i ping 6.9.6.69 on the server side xoilac.xxx
and i can even see the switch do a broadcast message(all Fs) by sending to all in the local network 

violetta1405_1-1755009736802.png

2. What do you mean by saying "read the official book"? thank you^^

 

 

u r welcome @violetta1405 . Alrigh, so the router doesn't perform NAT when both source (172.16.69.2) and destination (6.9.6.69) point to the same internal host because it recognizes this as internal traffic. Instead of translating, it routes directly using its internal routing table. Which means that, If u're seeing traffic go out to the ISP when pinging 6.9.6.69:

  1. There's a missing NAT exemption rule for this internal communication, or
  2. The routing table isn't properly configured for this destination

And the switch broadcasts (all Fs) u're seeing are ARP requests, which happen when devices can't find the MAC address for 6.9.6.69. This suggests the host isn't responding to ARP properly.....

they way that u fix that is to add a nat exemption: ip nat inside source static 172.16.69.2 6.9.6.6, And then verify routes and check the arp tables.....

The OCG the official book CCNA 200-301 by Wendell Odom...

hope it wasnt a long long answer, and PEACE!

 

-Enes

more Cisco?!
more Gym?!



If this post solved your problem, kindly mark it as Accepted Solution. Much appreciated!

I can see there's a time when both source ip and dest ip is 6.9.6.69 . I think it translate the source ip from 172.16.69.2 to 6.9.6.69
after looking up the NAT table

violetta1405_0-1755019603357.png

after looked up the dest ip in the routing table it found the entry (because i have ip route 0.0.0.0 0.0.0.0 6.9.6.9)

violetta1405_1-1755019732687.png
it tried to find the mac address of the dest ip 6.9.6.69 by looking at ARP table right? but then it drops the packet instead of buffering it. Maybe it recognizes it as internal due to src ip is the same as dest ip (idk)

violetta1405_2-1755020036851.png

and i see "The ARP process has sent a request to the same target IP address recently. It does not send out another" after the router CORP tried to send arp request and drop the packet

somehow after that i saw a lot of multicast and finally i continue checking and saw some progress of the ping 6.9.6.69

violetta1405_3-1755021068199.png

because the arp request is looking for 6.9.6.69 so number 5 says does not match because the receiving port is 6.9.6.9(the static route). It then checks the routing table

violetta1405_4-1755021282733.png

7. The ARP process checks the routing table whether the requested IP address is reachable.

8. The requested IP address is reachable on the receiving port.

9. The ARP process drops the frame.
it is reachable due to the S* but i don't know why it drops the frame

so to concludes I can see the frame always get dropped then multicast appears and the host xoilac.xxx server will start its next ping request on 6.9.6.69(itself globally)

Those are my understandings about the lab. So maybe I made you confusing(I am sorry) here because you replied:
" so the router doesn't perform NAT when both source (172.16.69.2) and destination (6.9.6.69) point to the same internal host because it recognizes this as internal traffic"
Or Am I understanding it wrong? maybe the reason is what you said "The routing table isn't properly configured for this destination"
so it still translates.
also I already have "ip nat inside source static 172.16.69.2 6.9.6.69" and I will find how to check the arp tables later.
Overall, Thank you for your really helpful answers. I hope my reply doesn't make you confused and also thank you for your book recommendation^^