traceroute from UNIX to PIX-515e not working

Hello, can someone tell me what it takes to get the PIX to reply to UNIX traceroute's? I am trying to get my PIX 5151e to reply to traceroute's from a UNIX machine. It is proving to be quite difficult. I've done everything described in this article, and still nothing. ICMP based traces work, but not UDP based traces (as are standard to every router I've ever dealt with.) After some debugging, I can see the UDP packets hitting the PIX, but the PIX never replies (not via UDP or ICMP). That's it. That's where I am at. Can someone help shed some light on this? Thanks,

-Mike

Reply to
ponga
Loading thread data ...

You can't do it in PIX 4, 5, or 6; I don't know about PIX 7 but I suspect not.

It is PIX security policy not to -itself- respond to packets that are not addressed to -it-.

The PIX will look each one of those UDP accesses up, determine whether there are translations in place for them and whether the packets are permitted by the access policies, and if they are permitted the PIX will forward the packets on to the destination *without* changing the TTL. The PIX is invisible to a successfull traceroute.

If the static or access-list policies do not permit those UDP packets through, then they suffer the fate of all blocked UDP packets: they are just dropped, with a message being logged according to the access-list 'log' keywords and the configured log levels. The PIX does -not- treat them specially due to TTL expiration, as it is transparent to TTL.

Earlier I said that, "It is PIX security policy not to -itself- respond to packets that are not addressed to -it-.". This carries over to RST and generation of "ICMP unreachable" packets: by default the PIX doesn't generate either. For TCP traffic, you can use the "service" command to instruct the PIX to generate RST's; there are special provisions for IDENT mixed in to that. I see that PIX 7 expands the RST policies, but I don't -see- any provision for generation of ICMP Unreachables in PIX 7.

Reply to
Walter Roberson

Hi Mike,

The PIX Firewall does not support the initiation of the traceroute command as it is not part of the PIX command set.

However, it can be configured to allow traceroute through it.

When a traceroute command is issued from the outside, the PIX does not display its own interface IP address nor does it display the IP addresses of inside networks.

The destination address is displayed multiple times for each internal hop.

Traceroutes only work with static Network Address Translations (NATs) and not with Port Address Translation (PAT) IP addresses.

For example, a client on the Internet with the address 209.165.202.130 does a traceroute to a web server on the inside of the PIX with a public address of 209.165.201.25 and a private address of 10.1.3.25.

There are two routers between the PIX and the internal web server.

This is how the output of the traceroute command appears on the client machine:

Target IP address: 209.165.201.25 Source address: 209.165.202.130

Tracing the route to 209.165.201.25

1 209.165.202.128 4 msec 3 msec 4 msec

2 209.165.201.25 3 msec 5 msec 0 msec

3 209.165.201.25 4 msec 6 msec 3 msec

4 209.165.201.25 3 msec 2 msec 2 msec

icmp error command is issued.

When this feature is enabled, the PIX creates xlates for intermediate hops that send Internet Control Message Protocol (ICMP) error messages, based on the static NAT configuration.

The PIX overwrites the packet with the translated IP addresses.

In PIX 7.0, if NAT is enabled, the IP addresses of the PIX interfaces and the real IP addresses of the intermediate hops cannot be seen.

However, in PIX 7.0, NAT is not a must and can be disabled with the no nat-control command.

If the NAT rule is removed, the real IP address can be seen, provided that the real IP address is a routeable one.

------------------------------

There can be two different scenarios when traceroute is configured through the PIX.

They are -

Scenario # 1:

In order to allow traceroute outbound through the PIX, there must be static or global statements to allow the address translation.

In addition to the static or global statements, conduits or access control lists (ACLs) are also added (ACLs are preferred over conduits as conduits have been deprecated in PIX OS code 7.x and later).

For example, these ACLs need to be configured to allow inside users to traceroute outside:

access-list 101 permit icmp any any echo-reply

access-list 101 permit icmp any any source-quench

access-list 101 permit icmp any any unreachable

access-list 101 permit icmp any any time-exceeded

access-group 101 in interface outside !--- Binding the access list 101 to the outside interface.

This allows only the return messages listed through the firewall when an inside user pings to an outside host.

Other types of ICMP status messages may be hostile, and the firewall blocks them.

For PIX Firewalls that operate on PIX OS code 7.x and later, ICMP inspection must be enabled with the inspect icmp command.

Issue the inspect icmp error command to create xlates for intermediate hops that send ICMP error messages, based on the static/NAT configuration.

The security appliance overwrites the packet with the translated IP addresses.

------------------------------

Scenario # 2:

In order to issue the traceroute command to get to a device inside the PIX, there must be a static mapping to the inside device.

Also, in addition to the static or global statements, conduits or ACLs are also required to be added to the configuration.

Note: Make sure that ICMP is not blocked.

Look at the output of the show icmp command for PIX OS 6.3 and earlier and the output of the show running-config icmp command for PIX OS 7.0 and later in order to do this.

For details, refer to:

The PIX and the traceroute Command

formatting link
and

Handling ICMP Pings with PIX Firewall

formatting link
Hope this helps.

Brad Reese BradReese.Com - Cisco Repair

formatting link
Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant BradReese.Com - Cisco Power Supply Headquarters
formatting link

Reply to
www.BradReese.Com

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.