I have an old 486-box acting as a router. It has two NICs and
an ISDN adapter. The box is connected to my ISP by ISDN link
and has a GRE tunnel running over the ISDN link. The other end
of the tunnel is a Cisco router and the tunnel is the default
route. I'm experiencing problems identical to the classic MTU
problem with IP masquarade where a TCP-connection to/from some
hosts becomes jammed after a few bytes have been sent. The only
difference is that the problem is reproducable also on the router
box itself.
I'm running 2.2.18 vanilla and my firewall rules aren't blocking
ICMP. The ethernet interfaces and the ISDN link have an MTU of
1500 and the GRE tunnel has an MTU of 1514 (courtesy of Cisco).
Has anyone got any bright ideas how to work around this? Would
upgrading to 2.4 fix this?
--
-=[ Count Zero / TBH - Jussi H?m?l?inen - email [email protected] ]=-
On Sun, 31 Dec 2000, Jussi Hamalainen wrote:
> I'm running 2.2.18 vanilla and my firewall rules aren't blocking
> ICMP. The ethernet interfaces and the ISDN link have an MTU of
> 1500 and the GRE tunnel has an MTU of 1514 (courtesy of Cisco).
How is this solved? Personally, I am behind a CIPE tunnel with an MTU of
1442 or something like that. I experienced problems to some places and
have solved it by using the linux box as socks5 proxy (only napster) and
webproxy (squid). When the linux box does TCP to the outside it'll use the
MTU of the tunnel (default route is the tunnel) and thus works perfectly
(since TCP MSS will be set low enough to fit into the tunnel).
Could it be some kind of incompability at the tunnel level that make you
unable to receive large packets over the tunnel? Have you tcpdump:ed to
see if the tunnel packets actually make it the way they should?
--
Mikael Abrahamsson email: [email protected]
> How is this solved? Personally, I am behind a CIPE tunnel with an MTU of
> 1442 or something like that. I experienced problems to some places and
You have to get the other end to fix it.
> Could it be some kind of incompability at the tunnel level that make you
> unable to receive large packets over the tunnel? Have you tcpdump:ed to
> see if the tunnel packets actually make it the way they should?
Its normally seriously incompetent firewall admins on remote sites. Most large
ecommerce sites have these kind of basic errors. Makes you glad to trust your
credit card details to them doesnt it 8)
On Sun, 31 Dec 2000, Mikael Abrahamsson wrote:
> When the linux box does TCP to the outside it'll use the MTU of
> the tunnel (default route is the tunnel) and thus works perfectly
> (since TCP MSS will be set low enough to fit into the tunnel).
In my case I can't access a problematic host even from the router
box.
> Could it be some kind of incompability at the tunnel level that
> make you unable to receive large packets over the tunnel?
Could be. The internet connection is a 64k ISDN link.
> Have you tcpdump:ed to see if the tunnel packets actually make it
> the way they should?
I can't snoop the actual tunnel device, because tcpdump and sniffit
give me an unknown media type error. Here's a tcpdump from the router
box's ethernet device of a HTTP session (using lynx) to
http://www.doomworld.com:
17:19:46.126297 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: S 2549095564:2549095564(0) win 32120 <mss 1460,sackOK,timestamp 649398[|tcp]> (DF)
17:19:46.386142 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 <mss 1460,sackOK,timestamp 91687185[|tcp]> (DF)
17:19:46.386142 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 <mss 1460,sackOK,timestamp 91687185[|tcp]> (DF)
17:19:46.386142 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: . ack 1 win 32120 <nop,nop,timestamp 649423 91687185> (DF)
17:19:46.386142 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: P 1:369(368) ack 1 win 32120 <nop,nop,timestamp 649423 91687185> (DF)
17:19:46.685963 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 <nop,nop,timestamp 91687216 649423> (DF)
17:19:46.685963 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 <nop,nop,timestamp 91687216 649423> (DF)
And the connection locks up. This happens every time. I don't have
access to the Cisco so I can't dump traffic on the remote end of
my tunnel.
--
-=[ Count Zero / TBH - Jussi H?m?l?inen - email [email protected] ]=-
Hi,
At 05:28 PM 31/12/2000 +0200, Jussi Hamalainen wrote:
>On Sun, 31 Dec 2000, Mikael Abrahamsson wrote:
>
> > When the linux box does TCP to the outside it'll use the MTU of
> > the tunnel (default route is the tunnel) and thus works perfectly
> > (since TCP MSS will be set low enough to fit into the tunnel).
>
>In my case I can't access a problematic host even from the router
>box.
...
>17:19:46.126297 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: S
>2549095564:2549095564(0) win 32120 <mss 1460,sackOK,timestamp
>649398[|tcp]> (DF)
...
i know that you've said previously that you've increased your MTU beyond
1500, but can you validate that it is actually working?
ie. ping something on the other side of the GRE tunnel using a ping with
total packet sizes equal to 1500?
alternatively, ensure that your application is capable of enforcing a MSS
<1460 if this is shown to not be the case ..
http://www.cisco.com/warp/public/105/56.html contains some good information
on some of the potential pitfalls of using tunnels.
cheers,
lincoln.
On Mon, 1 Jan 2001, Lincoln Dale wrote:
> i know that you've said previously that you've increased your MTU beyond
> 1500, but can you validate that it is actually working?
Yup. At least 1500 byte ICMP echo packets get through the tunnel
OK.
> alternatively, ensure that your application is capable of enforcing a MSS
> <1460 if this is shown to not be the case ..
I found a way to work around this problem. I had to tell _ALL_
the hosts on my local network to use an MSS of 576 for the default
route (the GRE tunnel). Thus the packets always fit through without
fragmentation and the problem is gone (but not solved). If someone
has a more elegant solution, please tell me. This one seems to be
poison for the Windows boxes on my network. :I
--
-=[ Count Zero / TBH - Jussi H?m?l?inen - email [email protected] ]=-