Great Circle Associates Firewalls
(September 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: curios traceroute
From: Charles Ragan <ragan @ INS . COM>
Date: Sun, 08 Sep 1996 23:25:54 -0500
To: Chris Lonvick <clonvick @ cisco . com>, firewalls @ GreatCircle . COM

Chris,

Thanks for the heads up and info!  You mis-typed rfc 792 (729 is the IAC for
telnet ;-)

So....let me see if I have this straight (since I've only digested it!) -
The last box that these traceroutes were traversing with a legal address was
a Solaris box running Firewall-1.  There is possibility of some translation
happening, and it could be our tracert code that is pulling the information
from the payload of the datagram.....

Perhaps that's an enhancement in the tracert from MS? ;-)

>From RFC 792, pg 2:

Source Address

      The address of the gateway or host that composes the ICMP message.
      Unless otherwise noted, this can be any of a gateway's addresses.

The Solaris box was running multiple addresses (one of them rfc1918) - it
appears that Firewall-1 was sourcing the packet from that address.    

Do you think that in this case, it wasn't a 'payload' grabbing by the
tracert utility?  I was using the MS tracert, and the original poster was
using something else that signified the host unreachable by '!H'.

Thanks.

Charles

At 09:41 PM 9/8/96 -0700, Chris Lonvick wrote:
>Hello All,
>
>Gererally, ISPs don't propogate the destination of RFC-1918 networks through
>the Internet.  They usually have a chuckle then zap them from the routing
>tables.  What you're seeing is a NAT that doesn't dig into the packet.  NATs
>_must_ know to change the IP source and destination addresses.  This,
>however, is not the end.  Certain protocols embed the IP addresses into the
>packet payload.  For example, to get certain commands to work properly in
>ftp, the NAT must know to recognize these types of packets and then reach
>inside the payload and change the addresses there as well.  Your traceroute
>program is not looking at the IP source/destination addresses but is
>utilizing some of the data inside the payload of the packet (which the NAT
>is not translating) to generate its report.  Look at the source code of your
>traceroute program and RFC-729.
>
>Thanks,
>Chris Lonvick
>Cisco Systems
>Consulting Engineering
>+1-713-778-5663
>
>
-----------------------------------------------------
Charles B. Ragan, Jr.                 International Network Services
(214) 392-3545                       14160 Dallas Parkway Suite 200
Charles_Ragan @
 ins .
 com          Dallas, TX 75040
Cisco Certified IE (CCIE)           Text Page   - 1-800-INS-1-INS
Master CNE                              Direct Page - 1-888-360-5812
Microsoft SE			
Certified Banyan Engineer	"Semper Fi" - USMC Retired
-----------------------------------------------------




Indexed By Date Previous: Re: curios traceroute
From: Charles Ragan <ragan @ INS . COM>
Next: SNG multihomed works ?
From: Stefano Taino <taino @ cryptonet . it>
Indexed By Thread Previous: Re: curios traceroute
From: Charles Ragan <ragan @ INS . COM>
Next: Re: curios traceroute
From: Chris Lonvick <clonvick @ cisco . com>

Google
 
Search Internet Search www.greatcircle.com