traceroute from UNIX to PIX-515e not working

Discussion in 'Cisco' started by ponga, Oct 23, 2006.

  1. ponga

    ponga Guest

    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<http://www.cisco.com/warp/public/110/pixtrace.html> 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
    ponga, Oct 23, 2006
    #1
    1. Advertising

  2. In article <>,
    ponga <> wrote:
    >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<http://www.cisco.com/warp/public/110/pixtrace.html> 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?


    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.
    Walter Roberson, Oct 23, 2006
    #2
    1. Advertising

  3. 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

    >From PIX version 6.3, this behavior can be undone if the fixup protocol

    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

    http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00800e9312.shtml

    and

    Handling ICMP Pings with PIX Firewall

    http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

    Hope this helps.

    Brad Reese
    BradReese.Com - Cisco Repair
    http://www.bradreese.com/cisco-big-iron-repair.htm
    1293 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
    http://www.bradreese.com/cisco-power-supply-inventory.htm
    www.BradReese.Com, Oct 23, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr Ping

    Traceroute and pix 501

    Mr Ping, Nov 24, 2004, in forum: Cisco
    Replies:
    8
    Views:
    4,658
    Mr Ping
    Nov 24, 2004
  2. Christoph Gartmann

    No traceroute since Pix upgrade to V7

    Christoph Gartmann, Jun 21, 2005, in forum: Cisco
    Replies:
    2
    Views:
    3,511
    BradReeseCom
    Jun 23, 2005
  3. jsandlin0803
    Replies:
    3
    Views:
    931
    Erik Tamminga
    Dec 30, 2005
  4. Scott Townsend

    PIX 515 to PIX 515e not passing traffic

    Scott Townsend, May 10, 2006, in forum: Cisco
    Replies:
    6
    Views:
    3,695
    Vikas
    May 25, 2006
  5. leuzz
    Replies:
    3
    Views:
    550
Loading...

Share This Page