What is the problem with my NAT configuration?

boile

Hi Everyone,

Thanks for reading my post.

I have this "Cisco 3640" router, which I have connected to the modem that I have got from the ISP.

Here is the configuration

interface FastEthernet0/1
ip address 192.168.5.254 255.255.255.0
ip nat inside

interface FastEthernet0/0
ip address dhcp
ip nat outside

ip access-list standard test
permit 192.168.5.0 0.0.0.255

ip nat inside source list test interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

(The router automatically added this, I guess because of DHCP)
ip route 0.0.0.0 0.0.0.0 99.244.38.1 254




Here is the
Router#sh ip int brief
Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 99.244.38.240 YES DHCP up up

FastEthernet0/1 192.168.5.254 YES NVRAM up up

So, you can see the router is getting public IP address. If I

ping 99.244.38.(some number).

Some of them work, and some of them don't. I guess those addresses are not assigned.

When I ping from my pc, I get:

Router#sh ip nat translations
Pro

---

Inside global---

---

Inside local

---

Outside local

---

Outside global

icmp

---

99.244.38.240:512

---

192.168.5.9:512

---

4.2.2.2:512

---

4.2.2.2:512

icmp

---

99.244.38.240:512

---

192.168.5.9:512

---

99.244.28.247:512

---

99.244.28.247:512

Looks like the router is translating. If I ping some valid public IP address, such as 4.2.2.2(This is a public DNS server). It says Request timed out. So, the firefox does not open any web pages.

What is wrong here? What should I do?


Any solution would be appreciated.

deth1k

Hi Boile,

Can you run the same ping from the router itself and then an extended ping sourcing your LAN interface i.e

ping x.x.x.x source fa0/1

+

sh ip nat trans

billscott92787

Try to ping like google or yahoo once. I am reviewing your config, I really don't see anything wrong at the moment. Let me know what you get. Can you also post a copy of your running-config?

mwgood

I would try using the IP address for your next-hop gateway, rather than the exit interface for your default route. Using the exit interface can sometimes result in failure to encapsulate.

The rest of your config looks OK.

rinoel

Hi boile, you might need authentication configuration if you have any from your ISP???

boile

mwgood wrote: »

I would try using the IP address for your next-hop gateway, rather than the exit interface for your default route. Using the exit interface can sometimes result in failure to encapsulate.

The rest of your config looks OK.

Well, The thing is I am using DHCP, In this case I guess the next-hop IP address is
(The router automatically added this, I guess because of DHCP)
ip route 0.0.0.0 0.0.0.0 99.244.38.1 254

So, the router adds the next-hop address, for me. Is that what you are looking for?
My router automatically gets this. Just wondering, is there other way to find that?

Thanks

mwgood

In "ip route 0.0.0.0 0.0.0.0 99.244.38.1 254" - the 254 indicates that this is a floating static route, which is basically a backup route - which would only be used when the primary route is removed from the routing table.

I'm suggesting you remove the previous default route and enter "ip route 0.0.0.0 0.0.0.0 99.244.38.1" - assuming 99.244.38.1 is the next-hop gateway address.

boile

rinoel wrote: »

Hi boile, you might need authentication configuration if you have any from your ISP???

Hi

May be that's the reason, because I can ping the ISP router address, and some of the 99.244.38.xxx addresses, but not other public addresses(4.2.2.2 --- 8.8.8.8 --- 8.8.4.4). So, I guess my router forwards the packets to the ISP network. But the ISP is not forwarding packets to those destinations.

From these it looks like, the problem is on the ISP side.

But if I connect my D-Link router instead of Cisco router, It can get me online, and everyting works.

Fromthese it seems, the problem is on my-side.


Any Idea?

Thanks

wastedtime

I would take a look at the computers and make sure they match up to your inside configuration. That is the ip addresses, default route, also check your dns make sure the dlink didn't proxy it. Also this probably has nothing to do with the issue at the moment but did your dlink router also do dhcp? if so you will need to set that up or go static. Also when you are pinging are you doing that from the router or computer?

deth1k

boile wrote: »

Hi


May be that's the reason, because I can ping the ISP router address, and some of the 99.244.38.xxx addresses, but not other public addresses(4.2.2.2 --- 8.8.8.8 --- 8.8.4.4). So, I guess my router forwards the packets to the ISP network. But the ISP is not forwarding packets to those destinations.

From these it looks like, the problem is on the ISP side.

But if I connect my D-Link router instead of Cisco router, It can get me online, and everyting works.

Fromthese it seems, the problem is on my-side.


Any Idea?

Thanks

Like mwgood said, get rid of your static route poiting to the interface as its AD is prefered over the one ISP is injected via DHCP. Do not put any routes in and try once more.

mwgood

The problem with using the exit interface with an ethernet network is that, since the interface has already been specified and there is no need for recursion, the mac-address needed to encapsulate the outbound frame is the mac-address for the final-destination IP address, not merely the next-hop mac-address. If the final destination address is on another network, then encapsulation will fail unless proxy-arp on the next-hop device is able to resolve the ARP request for you.

This is less than ideal; therefore, I recommend using the next-hop address on an ethernet network, not the exit-interface.

boile

deth1k wrote: »

Hi Boile,

Can you run the same ping from the router itself and then an extended ping sourcing your LAN interface i.e

ping x.x.x.x source fa0/1

+

sh ip nat trans

Thanks for ur response.

Here is the results of some pings.


Router#ping
Protocol [ip]:
Target IP address: 4.2.2.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 99.244.38.240
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)



Router#ping 99.244.38.240

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.244.38.240, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Router#ping 99.244.38.247

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.244.38.247, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 16/22/36 ms
Router#ping 99.244.38.245

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.244.38.245, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 12/18/24 ms
Router#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


Any help?

boile

billscott92787 wrote: »

Try to ping like google or yahoo once. I am reviewing your config, I really don't see anything wrong at the moment. Let me know what you get. Can you also post a copy of your running-config?

Thanks for ur reply. I am not sure, if u asked for the whole output.

Am I missing something?


Current configuration:
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
!
!
!
!
!
memory-size iomem 25
ip subnet-zero
!
ip audit notify log
ip audit po max-events 100
!
!
!
!
!
!
!
!
!
!
!
interface BRI0/0
no ip address
shutdown
!
interface FastEthernet0/0
ip address dhcp
ip nat outside
duplex auto
speed auto
!
interface Serial0/0
no ip address
!
interface FastEthernet0/1
ip address 192.168.5.254 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface BRI1/0
no ip address
shutdown
!
interface Ethernet1/0
no ip address
shutdown
!
interface Serial1/0
no ip address
shutdown
!
interface Ethernet1/1
no ip address
shutdown
!
interface Ethernet2/0
no ip address
shutdown
!
interface Ethernet2/1
no ip address
shutdown
!
interface Serial3/0
no ip address
shutdown
!
interface Serial3/1
no ip address
shutdown
!
interface Serial3/2
no ip address
shutdown
!
interface Serial3/3
no ip address
shutdown
!
ip nat inside source list 1 interface FastEthernet0/0 overload
ip nat inside source list test interface FastEthernet0/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
ip route 0.0.0.0 0.0.0.0 99.244.38.1 254
no ip http server
!
!
ip access-list standard test
permit 192.168.5.0 0.0.0.255
access-list 1 permit 192.168.5.0 0.0.0.255
!
!
!
line con 0
transport input none
line aux 0
line vty 0 4
login
!
end

wastedtime

I would get rid of one of the nat overloading statements, and it's associated access list. Also I would get rid of the ip route statements. Do a "show ip route" after you remove them. You should see a few connected routes and a few static routes with a default set to the next hop router.

boile

Hey Thanks to all of you guys.

I have followed
mwgood, deth1k and wastedtime,

After removing the ip route 0.0.0.0 command, and adding the next-hop ip address for the ip nat command.

Guess what,
WOW!
Everything works perfect.

Selfmade

yeah you have to specificy a NAT address in order for it to work, using a default route isn't recommended, it will fail to encapsulate

gouki2005

mwgood wrote: »

I would try using the IP address for your next-hop gateway, rather than the exit interface for your default route. Using the exit interface can sometimes result in failure to encapsulate.

The rest of your config looks OK.

you are saying
we must use the next hop IP ADDRESS instead the Interface is no the same thing??

mwgood

gouki2005 wrote: »

you are saying
we must use the next hop IP ADDRESS instead the Interface is no the same thing??

Right. Using the next-hop ip address is not the same as using the interface as the destination in a static route statement.

Think about when a router encapsulates a packet to the next hop. It must ARP or lookup the mac-address of the next hop in it's ARP table to resolve the IP Address in order to put the correct mac-address in the frame header. If you are using the next hop IP Address in the static route statement, then it can easily encapsulate the frame by putting the mac-address from the ARP lookup in the frame header - no problem.

If you use the exit interface, and I'm only talking about an ethernet network here... The router knows the interface to send the frame out of, but it still needs to encapsulate the packet using a mac-address from an ARP lookup. The only IP Address it knows about in this case is the final destination IP (because you didn't give it the next hop IP in the static route statement), so it must do an ARP lookup for the final destination IP. This is no problem if the final destination is on a connected network, but if the destination IP resides on a non-directly connected network, then the only way it will get an answer for an ARP lookup is if the upstream router(s) do the lookup in proxy and send an answer to the router that is encapsulating the packet (Proxy-Arp). (One other way would be a static ARP mapping, but this would typically be cumbersome.) This may work in some cases, but may cause some major problems, so it is best on a multi-access network to use the next hop in a static route instead of the exit interface.

Things are different for a point to point link, because there is only one possible destination. The reason this problem arises in this way - is due to the fact that an ethernet network is multi-access, meaning there can be more than one destination on the other side of any given link.

wastedtime

Exactly what mwgood said. Although when you receive your dhcp info from your isp it should use the default gateway as the next hop.

How to Configure a Cisco Router Behind a Non-Cisco Cable Modem [Cable Modems] - Cisco Systems

gouki2005

mwgood wrote: »

Right. Using the next-hop ip address is not the same as using the interface as the destination in a static route statement.

Think about when a router encapsulates a packet to the next hop. It must ARP or lookup the mac-address of the next hop in it's ARP table to resolve the IP Address in order to put the correct mac-address in the frame header. If you are using the next hop IP Address in the static route statement, then it can easily encapsulate the frame by putting the mac-address from the ARP lookup in the frame header - no problem.

If you use the exit interface, and I'm only talking about an ethernet network here... The router knows the interface to send the frame out of, but it still needs to encapsulate the packet using a mac-address from an ARP lookup. The only IP Address it knows about in this case is the final destination IP (because you didn't give it the next hop IP in the static route statement), so it must do an ARP lookup for the final destination IP. This is no problem if the final destination is on a connected network, but if the destination IP resides on a non-directly connected network, then the only way it will get an answer for an ARP lookup is if the upstream router(s) do the lookup in proxy and send an answer to the router that is encapsulating the packet (Proxy-Arp). (One other way would be a static ARP mapping, but this would typically be cumbersome.) This may work in some cases, but may cause some major problems, so it is best on a multi-access network to use the next hop in a static route instead of the exit interface.

Things are different for a point to point link, because there is only one possible destination. The reason this problem arises in this way - is due to the fact that an ethernet network is multi-access, meaning there can be more than one destination on the other side of any given link.

I see i going to take your advice