1. Home
  2. Cisco Systems
  3. PIX 501 routing issues

PIX 501 routing issues

Good day to everyone.

I have been toying with a PIX 501 running v. 6.3(5) and have run into a routing issue. The configuration for this unit is very basic at this time. All it is intended to do is stand as the gateway to the internet and allow traffic out while blocking most outside traffic. Eventually it will be one end of a dedicated VPN tunnel but I need it to be able to pass information to the internet for right now.

Internal devices (configured with the PIX as the gateway) can ping the inside interface of the PIX but not the outside. The PIX can ping devices on the inside and the outside, including successful ping replies from internet servers. Traceroute commands have the same results.

If anyone can spot what I may be missing and offer a suggestion of a fix, I would be greatly appreciative.

: PIX Version 6.3(5) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password 8Ry2YjIyt7RRXU24 encrypted passwd 2KFQnbNIdI.2KYOU encrypted hostname drtest domain-name nonetospeakof.org clock timezone CST -6 fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names pager lines 24 icmp permit 172.16.0.0 255.255.0.0 inside icmp permit 10.10.10.0 255.255.255.0 inside mtu outside 1500 mtu inside 1500 ip address outside 63.225.175.115 255.255.255.224 ip address inside 10.10.10.1 255.255.255.0 ip audit info action alarm ip audit attack action alarm pdm location 172.16.0.0 255.255.0.0 inside pdm location 0.0.0.0 255.255.255.224 outside pdm logging informational 100 pdm history enable arp timeout 14400 global (outside) 1 interface nat (inside) 1 0.0.0.0 0.0.0.0 0 0 route outside 0.0.0.0 0.0.0.0 63.225.175.113 1 timeout xlate 0:05:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225

1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout sip-disconnect 0:02:00 sip-invite 0:03:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server RADIUS protocol radius aaa-server RADIUS max-failed-attempts 3 aaa-server RADIUS deadtime 10 aaa-server LOCAL protocol local http server enable http 10.10.10.0 255.255.255.0 inside no snmp-server location no snmp-server contact snmp-server community public no snmp-server enable traps floodguard enable telnet 10.10.10.0 255.255.255.0 inside telnet timeout 5 ssh timeout 5 console timeout 10 terminal width 80 banner motd Unauthorized access is strictly prohibited. Cryptochecksum:f333d02c5a5d110ec76c7c460a896519
Reply to
Justin
Loading thread data ...

You need to allow those pings that you send out back in. I am certain they are going out, they're just not being allowed back in by the firewall.

Try adding the following commands:

access-list outside_access_in permit icmp any any echo-reply access-group outside_access_in in interface outside

HTH

Just> Good day to everyone.

Reply to
Mike W.

Reply to
Justin

Try adding these too, then:

icmp permit any outside icmp permit any echo-reply outside icmp permit any inside

Reply to
Mike W.

No improvement.

Reply to
Justin

I have also just set this unit up so that there is a computer on each side of the interface and nothing else. The inside computer has the PIX as its default gateway; the outside computer has a non-existent gateway. I have also turned ICMP to be fully open both directions.

The PIX can p> Just> > Adding the icmp traffic back through the outside interface didn't make

Reply to
Justin

Did you get rid of these statements:

icmp permit 172.16.0.0 255.255.0.0 inside icmp permit 10.10.10.0 255.255.255.0 inside

You should...you don't need them for testing.

Add this line as well so that this one section looks like it does below:

access-list outside_access_in permit icmp any any

names access-list outside_access_in permit icmp any any echo-reply access-list outside_access_in permit icmp any any pager lines 24 icmp permit any outside icmp permit any echo-reply outside icmp permit any inside mtu outside 1500 mtu inside 1500 ip address outside 63.225.175.115 255.255.255.224 ip address inside 10.10.10.1 255.255.255.0

Reply to
Mike W.

With a Pix you can only ping the closet IP address. You shouldn't be able to ping the outside address from the inside. This is quite normal.

Chris.

Reply to
Chris

Unfortunaltely, using ping and traceroute were just a tools to test routing in an attempt to see why internet traffic could not make it outside the PIX. I have tried resetting the box back to factory defaults and using the 192.168.1.x ip address scheme and connecting the outside interface directly to an internet router, setting up the default NAT and allowing all traffic on both sides and it still will not let a computer from the inside look outwards.

Tis probably time for a call to Cisco.

Reply to
Justin

You cannot PING the far interface of a PIX. It just won't ever happen. Find another way to test routing through the PIX.

Reply to
Scott Perry

Your config looked okay. I presume that you checked the routing on the client PC's? What did a "sh xlate" show on the pix? Could the clients resolve URL's to IP's?

Chris.

Reply to
Chris

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.