cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2845
Views
17
Helpful
16
Replies

A network can't get out - Is this a Deny static route?

spdivr
Level 1
Level 1

Hi, I have been dropped into this position and I am trying to figure out a problem. The writer of the configs is no longer available, so I am struggling. Basically, we have a router with 2 ethernet ports. FA0/0 is the 192.168.1.1/24 interface. FA0/1 is the 172.16.254.254/16 interface. The network connects to the Internet through a firewall at 172.16.201.1. Everyone on the 172 network can get to the internet. The 192 network can communicate with the 172 network, but can't get to the Internet. I can't find any reason for this, except possibly this entry in the show ip route:

S* 0.0.0.0/0 [1/0] via 172.16.201.1

S 192.168.0.0/16 [1/0] via 0.0.0.0

I understand the first one says that anything unknown should be forwarded to the firewall, but can someone explain what the second entry means?

Thanks!

4 Accepted Solutions

Accepted Solutions

ian.selkirk
Level 1
Level 1

Hi, The show ip route output does not make any sense to me at the moment... The second entry should read more like:

192.168.0.0 is subnetted (mask is 255.255.255.0), 1 subnets

C 192.168.1.0 255.255.255.0 routing via 0.0.0.0, Ethernet0

Note the initial "C" denoting a directly connected network, and the 0.0.0.0 stating that it is local.

The first entry is OK, the "S" denoting a locally configured static default route, and the * stating that it is the current candidate default route.

Please provide all 192.168.x.x output from the routing table and any locally configured static routes in the 192.168/16 range.

I imagine you have checked but for completeness does the firewall have a static entry 192.168.1.0/24 via 172.16.254.254? Also worth checking that the firewall allows ICMP from the 192 range in addition to the directly connected 172 range (I wouldn't normally allow it!). I'd concentrate on solving the IP connectivity from 192 to the firewall interface before considering anything else...

View solution in original post

Hello,

connectivity always has two directions. In case you ping the PIX from your PCs at 192.168.1.0/24 it is

1) PC to PIX (ICMP request)

2) PIX to PC (ICMP reply)

For 1) your 192.168.1.0/24 clients need to send packets towards the PIX following the default route. The should be no problem unless the default gateway is not 192.168.1.1 for them. I assume this is not the case.

For 2) when the PIX receives an ICMP request it will first check whether this type of traffic is allowed. According to your post it is allowed. Second the PIX (as any other IP device) will create the proper ICMP reply packet. It should then send it back and will therefore check it´s IP routing table where the 192.168.1.123 IP address is to be found. As long as there is no more specific entry it will send it along the default route out to the internet. Once you "tell" the PIX that the 192.168.1.0/24 network is found through 172.16.254.254 it will send it back to the router. Your router has the proper entry in its IP routing table (C 192.168.1.0/24 is directly connected, FastEthernet0/0) and will know how to deliver the ICMP packet coming from the PIX.

So you need an entry in the PIX for 192.168.1.0/24 network. It could look like this:

route inside 192.168.1.0 255.255.255.0 172.16.254.254 1

Check whether this exists and add the route in case it is missing. Once this is done internet access should be possible according your internal IP routing

Hope this helps! Please rate all posts.

Regards, Martin

View solution in original post

Hello,

somewhat simplified: a recursive lookup is performed, when one entry in the IP routing table needs another entry in the routing table to find the outgoing interface for a certain IP destination network.

Example:

B 10.1.1.0/24 next hop 10.2.3.4

O 10.2.3.0/24 next hop 10.3.5.1

C 10.3.5.0/30 directly connected interface Serial0

Lets assume we want to send a packet to 10.1.1.1, how to get there?

Here BGP (B) would tell the router, send it to 10.2.3.4, my next hop for your IP packet. But the router needs an interface to send the IP packet out. So, where do we find 10.2.3.4? To find out, the router consults the IP routing table.

OSPF (O) tells 10.2.3.0/24 (containing 10.2.3.4) can be reached through 10.3.5.1 - fine, but still no interface identified where to send the IP packet to 10.1.1.1!

So the router looks again into the IP routing table (hence recursive lookup!). Where is 10.3.5.1?

And now it detects that 10.3.5.0 is connected and therefore 10.3.5.1 is reachable through Serial0.

In the final step the router was able to identify an outgoing interface and can send the IP packet. But it was nessessary to lookup information in the IP routing table again and again - that is, why it is called recursive lookup.

Your conclusion that the firewall drops the packet might or might not be true. From an IP routing perspective the firewall will have a default route to the internet. And therefore, as long as it does not have more specific information, will try to send the IP packet towards the internet. Whether it succeeds or fails to send the packet depends on the security configuration allowing or disallowing the action.

Hope this helps! Please rate all posts.

regards, Martin

View solution in original post

You are right. Packet destined for the 192 network are dropped because the firewall does not know the 192 network exist behind the 172.16.254.254 interface.

Furthermore, clarify the other 192 networks that you have. As it is, 192.168.1.0/24 is directly connected and 192.168.23.0 is reachable via 192.168.1.4. Do you have other 192 networks, and if so are they reachable via 172.16.201.1? If they are not, the router will be dropping packets for this network.

When the next-hop address specified in a static route is not directly connected, the router will need to recursively check the routing table for the next-hop address, until the next-hop address is directly connected. The cisco router kind of take the 0.0.0.0 as host, and recursively checks the routing table which yield a next-hop of 172.16.201.1 (a directly connected address). The effect of the route

ip route 192.168.0.0 255.255.0.0 0.0.0.0

in your situation will be the same as

ip route 192.168.0.0 255.255.0.0 172.16.201.1.

Left to me, I would remove the static route, as it will not worsen your situation, since the default route is present.

View solution in original post

16 Replies 16

olorunloba
Level 5
Level 5

You most likely have the following static route

ip route 192.168.0.0 255.255.0.0 0.0.0.0

This will make the network 192.168.0.0/16 to use the route specified by the default route (i.e. 0.0.0.0 network). The router will therefore do a recursive lookup for the default route. In your case that is pointing to 172.16.201.1. 192.168.0.0 will therefore be routed through 172.16.201.1

These addresses are private and not public. I therefore expect that a device somewhere is doing an address translation. Is this device configured to translate for the 192.168.0.0/16 subnet as well. If not, this subnet will not browse.

We don't have that static route. The only static route to the default route is the one that I listed. The addresses are private, but they are translated by the firewall. The problem seems to be getting to the inside firewall interface. There is nothing on the firewall that is blocking traffic from the 192 network, but I can ping the inside of the firewall from the 172 network, but not from the 192 network. That's why I am looking at these last two static entries in the routing table. Can anyone tell me what the last one means? Thanks!

Hello,

is possible, can you post the entire configuration of your router ? Also, check if there are tunnel interfaces on your router, and if CEF might be enabled...

Regards,

GP

Thanks! Rather than posting the whole config, will the following work? Also, looks like CEF is enabled.

!

version 12.3

card type t3 4

aaa new-model

!

aaa session-id common

ip subnet-zero

!

ip cef

ip domain name XXXXXXX.com

!

controller T3 4/0

!

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

ip helper-address 255.255.255.255

duplex auto

speed auto

no cdp enable

!

interface FastEthernet0/1

ip address 172.16.254.254 255.255.0.0

ip helper-address 255.255.255.255

duplex auto

speed auto

no cdp enable

!

router eigrp 2

network 10.0.0.0

network 172.16.0.0

network 192.168.1.0

no auto-summary

!

router ospf 1

log-adjacency-changes

redistribute static metric 28

network 10.0.0.0 0.0.0.0 area 1

network 10.0.1.3 0.0.0.0 area 1

network 192.168.3.1 0.0.0.0 area 1

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.16.201.1

ip route 10.1.1.0 255.255.255.0 172.16.201.1

ip route 172.18.0.0 255.255.0.0 172.16.201.9

ip route 172.19.0.0 255.255.0.0 172.16.201.9

ip route 172.20.0.0 255.255.0.0 172.16.201.9

ip route 172.21.0.0 255.255.0.0 172.16.201.9

ip route 172.22.0.0 255.255.0.0 172.16.201.9

ip route 172.23.0.0 255.255.0.0 172.16.201.9

ip route 172.24.0.0 255.255.0.0 172.16.201.9

ip route 172.25.0.0 255.255.0.0 172.16.201.11

ip route 172.26.0.0 255.255.0.0 172.16.201.9

ip route 172.29.0.0 255.255.0.0 172.16.201.9

ip route 172.30.0.0 255.255.0.0 172.16.201.1

ip route 192.168.0.0 255.255.0.0 0.0.0.0

ip route 192.168.23.0 255.255.255.0 192.168.1.4

!

access-list 199 permit tcp any any established

access-list 199 permit udp any any

access-list 199 permit icmp any any echo-reply

no cdp run

!

end

Just one comment on the config, the static route:

ip route 192.168.0.0 255.255.0.0 0.0.0.0

explains the second entry in your original post. This entry is not acheiving anything as part of the config you have shared.

192.168.1/24 - Directly connected

192.168.23/24 - Also directly connected (according to OSPF config)

192.168.3/24 - Static route to 192.168.1.4

Other 192.168 addresses will follow the default route with or without the static entry for 192.168/16

Back to my original post... Is the firewall running OSPF? If not then yes, the firewall needs a static route to 192.168.1/24 via an IP address that it is aware of (172.16.254.254 is on an interface DIRECTLY CONNECTED to the firewall as well as the router). If the firewall is running OSPF check the firewall routing table for 192.168.1/24 and post the output please.

ian.selkirk
Level 1
Level 1

Hi, The show ip route output does not make any sense to me at the moment... The second entry should read more like:

192.168.0.0 is subnetted (mask is 255.255.255.0), 1 subnets

C 192.168.1.0 255.255.255.0 routing via 0.0.0.0, Ethernet0

Note the initial "C" denoting a directly connected network, and the 0.0.0.0 stating that it is local.

The first entry is OK, the "S" denoting a locally configured static default route, and the * stating that it is the current candidate default route.

Please provide all 192.168.x.x output from the routing table and any locally configured static routes in the 192.168/16 range.

I imagine you have checked but for completeness does the firewall have a static entry 192.168.1.0/24 via 172.16.254.254? Also worth checking that the firewall allows ICMP from the 192 range in addition to the directly connected 172 range (I wouldn't normally allow it!). I'd concentrate on solving the IP connectivity from 192 to the firewall interface before considering anything else...

Thanks! Are you saying that the Pix needs an entry that the 192 network is coming through the 172 network interface? As for the show ip route, here is the complete output (minus unrelated networks):

ERT3#sho ip route

Gateway of last resort is 172.16.201.1 to network 0.0.0.0

C 172.16.0.0/16 is directly connected, FastEthernet0/1

S 172.19.0.0/16 [1/0] via 172.16.201.9

S 172.18.0.0/16 [1/0] via 172.16.201.9

S 172.21.0.0/16 [1/0] via 172.16.201.9

S 172.20.0.0/16 [1/0] via 172.16.201.9

S 172.23.0.0/16 [1/0] via 172.16.201.9

S 172.22.0.0/16 [1/0] via 172.16.201.9

S 172.25.0.0/16 [1/0] via 172.16.201.11

S 172.24.0.0/16 [1/0] via 172.16.201.9

S 172.26.0.0/16 [1/0] via 172.16.201.9

S 172.29.0.0/16 [1/0] via 172.16.201.9

S 172.30.0.0/16 [1/0] via 172.16.201.1

C 10.0.0.0/8 is directly connected, Serial4/0

S 192.168.23.0/24 [1/0] via 192.168.1.4

C 192.168.1.0/24 is directly connected, FastEthernet0/0

S* 0.0.0.0/0 [1/0] via 172.16.201.1

S 192.168.0.0/16 [1/0] via 0.0.0.0

Hello,

connectivity always has two directions. In case you ping the PIX from your PCs at 192.168.1.0/24 it is

1) PC to PIX (ICMP request)

2) PIX to PC (ICMP reply)

For 1) your 192.168.1.0/24 clients need to send packets towards the PIX following the default route. The should be no problem unless the default gateway is not 192.168.1.1 for them. I assume this is not the case.

For 2) when the PIX receives an ICMP request it will first check whether this type of traffic is allowed. According to your post it is allowed. Second the PIX (as any other IP device) will create the proper ICMP reply packet. It should then send it back and will therefore check it´s IP routing table where the 192.168.1.123 IP address is to be found. As long as there is no more specific entry it will send it along the default route out to the internet. Once you "tell" the PIX that the 192.168.1.0/24 network is found through 172.16.254.254 it will send it back to the router. Your router has the proper entry in its IP routing table (C 192.168.1.0/24 is directly connected, FastEthernet0/0) and will know how to deliver the ICMP packet coming from the PIX.

So you need an entry in the PIX for 192.168.1.0/24 network. It could look like this:

route inside 192.168.1.0 255.255.255.0 172.16.254.254 1

Check whether this exists and add the route in case it is missing. Once this is done internet access should be possible according your internal IP routing

Hope this helps! Please rate all posts.

Regards, Martin

Which networks on the 192 can not browse. I suspect that you have more than the 192.168.1.0/24. If so, the route 192.168.0.0 is pointing in the wrong direction. Please cross check the config again. I did notice the following route in what you pasted.

ip route 192.168.0.0 255.255.0.0 0.0.0.0

Which is the reason you have this route in your routing table.

S 192.168.0.0/16 [1/0] via 0.0.0.0

The above route will cause a recursive route lookup for the default. Hence 192.168.0.0/16 will be forwarded via the 172.16.201.1. If your other 192 networks are connected to f0/0 interface then this entry is wrong.

I will advice that you proceed in the following manner.

1. Remove the route for 192.168.0.0/16 by entering no ip route 192.168.0.0 255.255.0.0 0.0.0.0

2. From inside the router, do an extended ping to 172.16.201.1, but specifying the source ip address to be 192.168.1.1. This will confirm that the route entry on the firewall for the 192.168.1.0/24 network is correct.

3. Still inside the router, try to reach the external interface, still sourcing from 192.168.1.1.

4. If the above are not successful, check the routing on the firewall.

5. If they are succesful, and you still can not browse, check the NAT configuration.

6. If there are other subnets on the 192.168.0.0, you will need to add these routes to the router, and probably to the firewall as well.

Please feed us back on the result.

Thanks for the help! I am able to see that the reason for the problem is because the firewall is not running ospf and does not have a route configured through the 172.16.254.254 interface back to the 192.168.1.0 network. I'm not authorized to make any changes at this point, but I can see that this is the problem. Thanks!

Now, would it be possible for someone to explain (in short-bus terms) why the routing table would have been configured this way:

S* 0.0.0.0/0 [1/0] via 172.16.201.1

S 192.168.0.0/16 [1/0] via 0.0.0.0

I understand that the S* entry makes that the default route (send it to the default gateway if address is not local). But what is the next entry saying? Is it saying that anything going to the 192.168.0.0 network should be sent to the default route, or is it saying to send it to no-where?

Many thanks!

I cannot say the reason why the routing table has been configured that way. However, I configured those routes and I found out that the router will do a recursive lookup to reference the defaul route. The 192.168.0.0 network will therefore be forwarded based on the default route entry. see below

S* 0.0.0.0/0 [1/0] via 172.16.201.1

S 192.168.0.0/16 [1/0] via 0.0.0.0

TestRouter2811#

TestRouter2811#sh ip cef 192.168.0.0 detail

192.168.0.0/16, version 32, epoch 0

0 packets, 0 bytes

via 0.0.0.0, 0 dependencies, recursive

unresolved

TestRouter2811#

Thanks for the reply! What exactly is happening in a "recursive lookup to the default route"? If I am understanding this correctly, a packet from the 192 network trying to get out will be sent to the default route, which will send it to the 172.16.201.1 address? As I understand it, the reason the packet can't get back to the 192 network from the firewall at 172.16.201.1, is because the firewall doesn't know that the 192 network is on the otherside of the 172.16.254.254 interface of the router, so it drops the packet?

Thanks!

Hello,

somewhat simplified: a recursive lookup is performed, when one entry in the IP routing table needs another entry in the routing table to find the outgoing interface for a certain IP destination network.

Example:

B 10.1.1.0/24 next hop 10.2.3.4

O 10.2.3.0/24 next hop 10.3.5.1

C 10.3.5.0/30 directly connected interface Serial0

Lets assume we want to send a packet to 10.1.1.1, how to get there?

Here BGP (B) would tell the router, send it to 10.2.3.4, my next hop for your IP packet. But the router needs an interface to send the IP packet out. So, where do we find 10.2.3.4? To find out, the router consults the IP routing table.

OSPF (O) tells 10.2.3.0/24 (containing 10.2.3.4) can be reached through 10.3.5.1 - fine, but still no interface identified where to send the IP packet to 10.1.1.1!

So the router looks again into the IP routing table (hence recursive lookup!). Where is 10.3.5.1?

And now it detects that 10.3.5.0 is connected and therefore 10.3.5.1 is reachable through Serial0.

In the final step the router was able to identify an outgoing interface and can send the IP packet. But it was nessessary to lookup information in the IP routing table again and again - that is, why it is called recursive lookup.

Your conclusion that the firewall drops the packet might or might not be true. From an IP routing perspective the firewall will have a default route to the internet. And therefore, as long as it does not have more specific information, will try to send the IP packet towards the internet. Whether it succeeds or fails to send the packet depends on the security configuration allowing or disallowing the action.

Hope this helps! Please rate all posts.

regards, Martin

You are right. Packet destined for the 192 network are dropped because the firewall does not know the 192 network exist behind the 172.16.254.254 interface.

Furthermore, clarify the other 192 networks that you have. As it is, 192.168.1.0/24 is directly connected and 192.168.23.0 is reachable via 192.168.1.4. Do you have other 192 networks, and if so are they reachable via 172.16.201.1? If they are not, the router will be dropping packets for this network.

When the next-hop address specified in a static route is not directly connected, the router will need to recursively check the routing table for the next-hop address, until the next-hop address is directly connected. The cisco router kind of take the 0.0.0.0 as host, and recursively checks the routing table which yield a next-hop of 172.16.201.1 (a directly connected address). The effect of the route

ip route 192.168.0.0 255.255.0.0 0.0.0.0

in your situation will be the same as

ip route 192.168.0.0 255.255.0.0 172.16.201.1.

Left to me, I would remove the static route, as it will not worsen your situation, since the default route is present.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: