• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 997
  • Last Modified:

PIX ping deny puzzle

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
gateguard
Asked:
gateguard
2 Solutions
 
lrmooreCommented:
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
 
PennGwynCommented:
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
 
gateguardAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now