<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: CIPE <cipe-l,AT,inka,DOT,de>
Subject: Re: Traceroute in only one direction.
From: James Knott <james.knott,AT,rogers,DOT,com>
Date: Mon, 04 Aug 2003 16:06:49 -0400
In-reply-to: <3F2D2F8F.7010500@rogers.com>
References: <3F2C682D.7020303@rogers.com> <3F2D2F8F.7010500@rogers.com>

James Knott wrote:
James Knott wrote:

I have CIPE set up between my firewall and notebook computer. Both are running Red Hat 7.3. I have noticed that while I can traceroute from my notebook to firewall, I can't in the opposite direction. Ethereal running on my firewall can see the the traceroute packets going out, but the modem indicators show no data being received by the notebook.
Ping works fine in both directions.


I have also noticed that network browsing with smb or nfs is painfully slow going from my notebook to systems on my lan, but much faster from my lan to notebook. The data lights on the cable and dial up modems indicate erratic data transfer when browsing the lan from the notebook and much smoother transfer, when browsing the notebook from the lan.


The above makes me suspect a problem with udp packets going from my lan to my notebook. The connection to the notebook is via a dial up modem. My firewall is connected to the internet via a cable modem. Might the speed difference be the cause of the problems? The MTU on the CIPE tunnel is set to 1440 bytes, to allow for the vpn headers.



Further on the traceroute. I have noticed that it will finally get a reponse after 12 attempts. Also, I don't see the modem data lights flash, until that 12th attempt, so there appears to be 12 "hops", before cipe even attempts to get beyond the firewall.


Here's what traceroute shows, when going from my firewall to the notebook.

traceroute to 192.168.2.20 (192.168.2.20), 30 hops max, 38 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  192.168.2.20 (192.168.2.20)  360.556 ms  284.731 ms  279.927 ms

But, when going the otherway, from the notebook to firewall, I get

traceroute to 192.168.2.10 (192.168.2.10), 30 hops max, 38 byte packets
 1  192.168.2.10 (192.168.2.10)  437.186 ms  299.840 ms  299.938 ms


So, even though the transit times are similar, going one way appears to have more hops than the other.


Here are my routes, according to netstat.

Notebook

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.10 * 255.255.255.255 UH 40 0 0 cipcb0
ssmtp.bloor.is. dell.home 255.255.255.255 UGH 40 0 0 cipcb0
max71.tor.acces * 255.255.255.255 UH 40 0 0 ppp0
192.168.1.0 * 255.255.255.0 U 40 0 0 cipcb0
127.0.0.0 * 255.0.0.0 U 40 0 0 lo
default max71.tor.acces 0.0.0.0 UG 40 0 0 ppp0



Firewall


Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.20 * 255.255.255.255 UH 40 0 0 cipcb0
192.168.1.0 * 255.255.255.0 U 40 0 0 eth1
24.42.140.0 * 255.255.252.0 U 40 0 0 eth0
127.0.0.0 * 255.0.0.0 U 40 0 0 lo
default tlgw14.lndn.phu 0.0.0.0 UG 40 0 0 eth0



tnx jk



This is getting curiouser and curiouser. When examining the outgoing packets that contain the traceroute packets, from my firewall to notebook, I can see the time to live count starting at 1 for 3 packets, then 2 for 3 etc. It appears as though the TTL values from traceroute are making their way into the UDP headers. Going the other way, from the notebook to firewall, shows a steady TTL of 40 on all encrypted packets containing traceroute packets.


Why the difference? Why should the CIPE UDP packets change their TTL, when sent from my firewall, but not the notebook?


<< | Thread Index | >> ]    [ << | Date Index | >> ]