Solved

PIX ping deny puzzle

Posted on 2004-04-03
3
976 Views
Last Modified: 2013-11-29
I have a PIX 525 with three interfaces being used, Outside0, Acc60, Eng20.   Acc60 is security level 60.  Eng20 is security level 20.

Acc60 connects to network 10.70.x.x.  
Eng20 connects to network 172.16.9.x.

From any workstation in 10.70.x.x I can ping 172.16.9.39, 172.16.9.40 and 172.16.9.41.  
Any 172.16.9.x can ping any other 172.16.9.x.

From any workstation in 10.70.x.x I am unable to ping 172.16.9.22.
I receive "Request timed out" on the workstation.
I receive these log entries on the PIX:

Result of firewall command: "show log | include 172.16.9.22"
 
106014: Deny inbound icmp src eng20:172.16.9.22 dst acc60:10.70.250.69 (type 0, code 0)
106014: Deny inbound icmp src eng20:172.16.9.22 dst acc60:10.70.250.69 (type 0, code 0)
106014: Deny inbound icmp src eng20:172.16.9.22 dst acc60:10.70.250.69 (type 0, code 0)

Beyond that, I really can't tell what's going on.  Why is this one workstation being denied and not the other three?

Also, if I do a "tracert 172.16.9.39" from a 10.70.x.x workstation, I get:

Tracing route to ENGPDC02 [172.16.9.39]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  10.70.1.1
  2   <10 ms   <10 ms   <10 ms  ENGPDC02 [172.16.9.39]

Trace complete.

Notice that the ip-address resolves to the correct name, even though there is no DNS resolution of any 172.16.9.x names on the 10.70.x.x network.

But if I do a "tracert 172.16.9.22" I get this:

Tracing route to 172.16.9.22 over a maximum of 30 hops

  1   <10 ms   <10 ms   <10 ms  10.70.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
    <continues>

(10.70.1.1 is an interface on a Catalyst 4908G-L3.  That switch connects the 10.70.x.x network to the PIX.  I don't think the problem is there, since the deny message is showing up on the PIX logs.)

So how can I troubleshoot this inablity to reach 172.16.9.22 from the 10.70.x.x network?

0
Comment
Question by:gateguard
3 Comments
 
LVL 79

Accepted Solution

by:
lrmoore earned 300 total points
Comment Utility
Permitting icmp replys takes an access-list on a PIX
since some of the hosts can reply just fine, and this one can't, there are two things to look at
1. subnet mask applied in the access-list that permits icmp-echo
2. routing on the 172.16.9.22 host. What is its default gateway? Does it know how to get to the 10.70.x.x subnet?

0
 
LVL 11

Assisted Solution

by:PennGwyn
PennGwyn earned 200 total points
Comment Utility
It's not routing, because he sees the answer attempts in the PIX log.  So that leaves something in the PIX config, probably an access list, that's incorrect.

0
 

Author Comment

by:gateguard
Comment Utility
I've been looking into all this and I don't really see why the pix is even replying at all.  This network is more complicated than I've indicated here, with different switches and an L3 switch... anyway, it turns out that if I substitute a windows machine for the 172.16.9.22 it solves my problem.  The difference being I know how to configure a windows machine, I don't know how to configure the original linux machine.  So I've turned this problem over to the people who do.  

0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Don’t let your business fall victim to the coming apocalypse – use our Survival Guide for the Fax Apocalypse to identify the risks and signs of zombie fax activities at your business.
Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now