Routing Issue - Cisco

I have a situation where in one of my offices I have a Cisco 1751 and a Cisco Pix. The Pix has internet access and the 1751 is a T1. There is a strange situation where I need to send traffic destined for one host through the pix.

The 1751 (10.75.2.1) is the gateway in the subnet. Under normal instances all traffic goes through this 1751 box. There is a tracker that sends traffic through an IPSEC tunnel on the Pix if the T1 is down. This part all works fine I am just telling you this so you have some context.

The pix is 10.75.2.2 - I can log into that pix and ping my address I am trying to create a route for no problem (lets say 1.1.1.1). I have defined in the 1751 a route which looks like this.

IP ROUTE 1.1.1.1 255.255.255.255 10.75.2.2

And there are two additional routes in this 1751 router...
IP ROUTE 0.0.0.0 0.0.0.0 2.2.2.2 track 10 (this is the tracker we are using and means default is to go over the T1)
IP ROUTE 0.0.0.0 0.0.0.0 10.75.2.2 200 (this is the secondary route to send traffic to the PIX if the T1 is down)

My question is this... I cannot seem to get the pix to show up when I do a traceroute in the 1751 to this 1.1.1.1 address - and I cannot ping 1.1.1.1 either. If I take the route off that sends teh traffic to 10.75.2.2 then the ping works but this sends the traffic through my default gateway. I cannot understand why if the pix can ping 1.1.1.1 any my 1751 gateway has a route to get to 1.1.1.1 it needs to go to the pix - that my 1751 cannot ping the 1.1.1.1 address...

The PIX by default blocks ICMP replies from the outside/Internet even though it allows the TCP/UDP return traffic (yeah, its silly). So, connectivity was there all along, the PIX was simply blocking ICMP.

A PIX by default doesn't appear as a hop in the traceroute. It "stealths" itself for a little added security (not really). In later versions of code you can make it decrement the TTL (make it appear in a traceroute).

>That did it.. now help me understand why?
The PIX by default blocks ICMP replies from the outside/Internet even though it allows the TCP/UDP return traffic (yeah, its silly). So, connectivity was there all along, the PIX was simply blocking ICMP.

>I had this..
access-list acl_out permit icmp any any
Yeah, but it wasn't applied to the interface with the "access-group" command.

>Also why doenst the pix show up on my traceroute from my 1751?
A PIX by default doesn't appear as a hop in the traceroute. It "stealths" itself for a little added security (not really). In later versions of code you can make it decrement the TTL (make it appear in a traceroute).

>Also strange that I have ALWAYS been able to ping the outside interface from another host? So why was that?

The PIX interfaces are treated differently. Pinging the PIX itself doesn't use the interface access-lists. Use the "icmp permit or icmp deny" commands to block/permit ICMP to itself. By default, all interfaces reply to ICMP.

Featured Post

With the GDPR deadline set for May 25, 2018, many organizations are ill-prepared due to uncertainty about the criteria for compliance. According to a recent WatchGuard survey, a staggering 37% of respondents don't even know if their organization needs to comply with GDPR. Do you?

Concerto Cloud Services, a provider of fully managed private, public and hybrid cloud solutions, announced today it was named to the 20 Coolest Cloud Infrastructure Vendors Of The 2017 Cloud (http://www.concertocloud.com/about/in-the-news/2017/02/0…

Both in life and business – not all partnerships are created equal.
As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …

Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:
• Key questions to ask when considering a partnership to accelerate your business into the cloud
• Pitfalls and mistakes other partners…