Can't ping to INSIDE GLOBAL IP (Static NAT)

WonR

I think I'll be spending some time in this forum in the future.


Anyhow, so I have a static NAT on Router:

!
ip nat inside source list 1 interface Serial0/0/0 overload
ip nat inside source static 192.168.0.10 55.55.55.5
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/0/0
!
access-list 1 permit 192.168.0.0 0.0.0.255
!

From Outside, I can ping to 55.55.55.5 (web server). No Problem.
From 192.168.0.100 host (LAN / Inside Local Address), I CANNOT ping to 55.55.55.5. PROBLEM

Router looks up the destination IP address (55.55.55.5) in the routing table, and finds it to be directly connected.

Router looks up in ARP table, and it's not there.

So it sends out broadcast to all ports except the port that it came in from, which is same port that 55.55.55.5 is located. Obviously, it cannot find 55.55.55.5

Static NAT above (in bold) does not take effect because packet was never sent out to Serial 0/0/0 (Outside). In other words, packet came in but never left.

That's where my brain stops.
How would I get LAN host to ping outside ip that has static NAT.

Thanks for your inputs.

Priston

What's your topology?
Can you ping the local address of the webserver?

Forsaken_GA

post the entire config for that router.

If 55.55.55.5 is an assigned address on the router, the internal hosts should be able to ping it just fine, nat or no nat. As soon as it hits the interface that holds the 192.168.0.0/24 gateway, the router should go 'hey, that's me!' and reply back. Your traffic shouldn't be NAT'd until it's actually going to transit out that interface, until that point, it's still internal traffic, so it should work fine, unless you don't have a route back to the source, or you've got something blocking icmp

Forsaken_GA

WonR wrote: »

Router looks up the destination IP address (55.55.55.5) in the routing table, and finds it to be directly connected.

Router looks up in ARP table, and it's not there.

So it sends out broadcast to all ports except the port that it came in from, which is same port that 55.55.55.5 is located. Obviously, it cannot find 55.55.55.5

I think you're also a little confused about how ARP works. A router does not broadcast anything out every port, routers don't propagate broadcasts. The only ARP at play at here is going to be on the hosts part.

When you try to ping 55.55.55.5, the host is going to recognize that IP isn't on it's subnet, it's not going to issue an ARP for 55.55.55.5, it's going to send the frame to the default gateway. If it doesn't have the default gateway's mac in it's arp table, it'll ARP for the gateway's address, NOT the destination address.

When it hits the router, the router is not going to arp for 55.55.55.5. Why? Because it's associated with a serial interface. Serial interfaces don't do ARP. Depending on how you have them configured, they may do inverse ARP, or if it's a point to point link, it doesn't need to know a layer 2 address, it just shunts it out the interface, it's only got one possible destination on that interface.

So chances are, something is screwed up in your configuration, but it's hard to tell without a topology map and the rest of the config.

WonR

Priston wrote: »

What's your topology?
Can you ping the local address of the webserver?

Yes, I can ping local address of server 192.168.0.10



**It's 55.55.55.0/29 Network**

WonR

Here is what I think is happening.

By the way, WAN is on ethernet, not serial(no HDLC or PPP). I THINK THIS IS THE PROBLEM.

I tried it with Seridal HDLC, and it works just fine. The packet will go out to WAN interface; next hop router will direct the packet back into WAN interface and NAT will translate it local address, then switch forwards frame to original host.

Routing table has 55.55.55.0/29 network as being directly connect to X1(WAN).
But webserver (55.55.55.5) actually resides in X0 (LAN)

So when router receives packet to webserver, router looks up destination IP Address in routing table, finds that destination IP address is directly connected next hop (X1WAN) port.

Now it tries to encapsulate into layer 2 frame but does not have destination mac address to 55.55.55.5 Router does have mac address to 192.168.0.10. So it seems like it drops it.

So then how would I be able to accomplish this? VLAN? So that arp table will be populated with public ip in a different sub-interface??

Couldn't this be done with NAT or ACL of some sort???

Thanks again for all the replys. It's really helping me understand a bit more clearly.

Forsaken_GA

WonR wrote: »

Here is what I think is happening.

By the way, WAN is on ethernet, not serial(no HDLC or PPP). I THINK THIS IS THE PROBLEM.

I tried it with Seridal HDLC, and it works just fine. The packet will go out to WAN interface; next hop router will direct the packet back into WAN interface and NAT will translate it local address, then switch forwards frame to original host.

Uhm, did you update your configurations on the router when you switched interfaces? The configurations you have above all show it dealing with Serial0/0/0, not an ethernet interface.

WonR

@Forsaken

Come on forsaken! Of Course!!!
X1 & X0 interfaces are fastethernet.
Thanks for reminding me that tho.

Forsaken, Sorry for the confusion. Yes, original post had "Serial" as configuration as you have mentioned.

WonR

here is my router config :

!
interface FastEthernet0/0 (X0 in picture)
ip address 192.168.0.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface FastEthernet0/1 (X1 in picture)
ip address 55.55.55.2 255.255.255.248
ip nat outside
duplex auto
speed auto
!
!
ip nat inside source static 192.168.0.10 55.55.55.5
!



Here is "Show arp"

Router#sho arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 55.55.55.5 - Incomplete ARPA FastEthernet0/1
Internet 55.55.55.1 4 00D0.58C9.8201 ARPA FastEthernet0/1
Internet 55.55.55.2 - 0060.47C4.EE02 ARPA FastEthernet0/1
Internet 192.168.0.1 - 0060.47C4.EE01 ARPA FastEthernet0/0
Internet 192.168.0.10 15 0009.7C1C.55E4 ARPA FastEthernet0/0
Internet 192.168.0.100 15 0007.ECB4.C786 ARPA FastEthernet0/0

as you can see 55.55.55.5 shows incomplete.

Priston

Forsaken_GA wrote: »

post the entire config for that router.

If 55.55.55.5 is an assigned address on the router, the internal hosts should be able to ping it just fine, nat or no nat. As soon as it hits the interface that holds the 192.168.0.0/24 gateway, the router should go 'hey, that's me!' and reply back. Your traffic shouldn't be NAT'd until it's actually going to transit out that interface, until that point, it's still internal traffic, so it should work fine, unless you don't have a route back to the source, or you've got something blocking icmp

55.55.55.5 is not an assigned address on his router, 55.55.55.2 is.

Forsaken_GA

Priston wrote: »

55.55.55.5 is not an assigned address on his router, 55.55.55.2 is.

Yes, I know that now. Look at the information that was available when I posted that, had to draw a few conclusions.

Forsaken_GA

WonR wrote: »

Router#sho arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 55.55.55.5 - Incomplete ARPA FastEthernet0/1
Internet 55.55.55.1 4 00D0.58C9.8201 ARPA FastEthernet0/1
Internet 55.55.55.2 - 0060.47C4.EE02 ARPA FastEthernet0/1
Internet 192.168.0.1 - 0060.47C4.EE01 ARPA FastEthernet0/0
Internet 192.168.0.10 15 0009.7C1C.55E4 ARPA FastEthernet0/0
Internet 192.168.0.100 15 0007.ECB4.C786 ARPA FastEthernet0/0

as you can see 55.55.55.5 shows incomplete.

Well that makes a certain degree of sense. You're basically trying to configure a discontigous subnet. Internally, the traffic his the router, and it sees it has a route for that subnet out the X1 interface, but it gets no arp reply because the host isn't live on that interface. You're trying to make the address space live on two different interfaces, and that dog don't hunt, Cisco doesn't treat egress traffic the same as ingress traffic for NAT. Try nmapping a WAN interface's IP from beind the router on the lan, and from outside the lan, and you'll see two very different results as to what ports are open.

On the other hand, that's just a quick guess. I'll have to mock this up in the lab tomorrow and test that theory. I'm suspecting you're going to need an ip nat outside source statement in order to make it work

You have to remember the rules of nat translation -

ip nat inside source = source IP gets translated for packets traveling inside to out. destination gets translated for packets traveling outside to in.

ip nat outside source = source IP gets translated for packets traveling out to in, destination IP gets translated for packets traveling in to out

From the perspective of the network, traffic from 192.168.0.100 going toward 55.55.55.5 is inside going out, as the 55.55.55.2 network lives on the outside interface, per your configuration. Therefore, the only that's going to get translated in your current configuration is the source address. So when the packet gets transited through the router, you've got the packet sourced from 192.168.0.100 translated as being from 55.55.55.2, destined for 55.55.55.5, which isn't live on that side of the network, hence the incomplete arp response, and essentially, a dropped packet.

WonR

@Forsaken_GA

Thanks for your reply, and you explained it way better than I could.
I actually have this setup in SonicWall environment. I needed 2 NAT policies to accomplish this.

(1) This takes care of traffic from outside (X1)
1-1 static NAT that is equivalent to what I have on this thread :
ip nat inside source static 192.168.0.10 55.55.55.5 SAME AS


(2) This takes care of traffic from inside to 55.55.55.5

---

Source Original : ANY
Source Translated : X1 IP (55.55.55.2)
Destination Original : 55.55.55.5
Destination Translated : 192.168.0.10
Service Original : ANY
Service Translated : ORIGINAL
Interface Inbound : X0 (LAN)
Interface Outbound : ANY

---

Part of above policy states, for any X0(LAN) traffic to 55.55.55.5, source address will be translated to X1(WAN). So it looks like traffic is coming in from WAN port rather than LAN port. This should take care of the ARP issue for 55.55.55.5

WHAT IS THE EQUAVALENT CISCO NAT STATEMENT???

Thanks!!!

*FYI, I also needed ACL to allow traffic from WAN(X1) to LAN(X0) that have destination to 55.55.55.5 in SonicWall. This was necessary since SonicWall is a firewall*

Forsaken_GA

WonR wrote: »

@Forsaken_GA

Thanks for your reply, and you explained it way better than I could.
I actually have this setup in SonicWall environment. I needed 2 NAT policies to accomplish this.

(1) This takes care of traffic from outside (X1)
1-1 static NAT that is equivalent to what I have on this thread :
ip nat inside source static 192.168.0.10 55.55.55.5 SAME AS


(2) This takes care of traffic from inside to 55.55.55.5

---

Source Original : ANY
Source Translated : X1 IP (55.55.55.2)
Destination Original : 55.55.55.5
Destination Translated : 192.168.0.10
Service Original : ANY
Service Translated : ORIGINAL
Interface Inbound : X0 (LAN)
Interface Outbound : ANY

---

Part of above policy states, for any X0(LAN) traffic to 55.55.55.5, source address will be translated to X1(WAN). So it looks like traffic is coming in from WAN port rather than LAN port. This should take care of the ARP issue for 55.55.55.5

WHAT IS THE EQUAVALENT CISCO NAT STATEMENT???

Thanks!!!

*FYI, I also needed ACL to allow traffic from WAN(X1) to LAN(X0) that have destination to 55.55.55.5 in SonicWall. This was necessary since SonicWall is a firewall*

Ok, this is the point at which I stop, because this is looking more and more like deployment, and not study. For a more thorough understanding of Cisco NAT, I'd recommend you check Cisco's website for deployment guides, or lay hands on a copy of Routing TCP/IP, Vol. 2

WonR

Forsaken_GA wrote: »

Ok, this is the point at which I stop, because this is looking more and more like deployment, and not study. For a more thorough understanding of Cisco NAT, I'd recommend you check Cisco's website for deployment guides, or lay hands on a copy of Routing TCP/IP, Vol. 2

You're hurting my feelings. I've put in my dues on studying and getting myself certified with papers. This thread has plenty of information regarding how ethernet switching differs from routing, and topics of NAT which you must understand in order for you work with any network equipments, not alone pass CCNA. Actually this thread goes way deeper than what you need to know to pass CCNA.

Perhaps, I'm in wrong forum. Thank you for all your inputs.

Forsaken_GA

WonR wrote: »

You're hurting my feelings. I've put in my dues on studying and getting myself certified with papers. This thread has plenty of information regarding how ethernet switching differs from routing, and topics of NAT which you must understand in order for you work with any network equipments, not alone pass CCNA. Actually this thread goes way deeper than what you need to know to pass CCNA.

Perhaps, I'm in wrong forum. Thank you for all your inputs.

Well, that's kind of my point. I have no problem helping folks work through theoretical problems in order to get the concepts down in order to employ those skills in the real world. It's a little unrealistic to expect detailed help for a live deployment off of a forum dedicated to helping folks pass certification exams though.

At least, not without discussing hourly rates

Don't take it personally, please. There's a fine line between helping folks along in their education (which I'm happy to do) and working pro bono (which I'm not )