netdev
[Top] [All Lists]

Re: dsl masquerading over linux 2.4.0-test[78]pre...

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre...
From: Marc Boucher <marc@xxxxxxx>
Date: Thu, 07 Sep 2000 14:14:40 -0400
Cc: netdev@xxxxxxxxxxx, mostrows@xxxxxxxxxxxxxxxxx, hgfelger@xxxxxxxxxxx, rusty@xxxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxx
In-reply-to: Your message of "Thu, 07 Sep 2000 08:06:34 EDT." <Pine.GSO.4.20.0009070803220.949-100000@shell.cyberus.ca>
References: <Pine.GSO.4.20.0009070803220.949-100000@shell.cyberus.ca>
Sender: owner-netdev@xxxxxxxxxxx
As Jamal says, mssclampfw can do the trick but since you are already
using iptables installed I would recommand its TCPMSS match&target
modules instead. These are in the tcp-MSS patch which can be found under
netfilter/userspace/patch-o-matic/ (in the CVS repository, or next
upcoming iptables release > 1.1.1). Use the ./runme script in that same
directory to apply it, then recompile iptables and reconfigure/rebuild
your kernel with CONFIG_IP_NF_MATCH_TCPMSS and
CONFIG_IP_NF_TARGET_TCPMSS enabled.

Then you need a rule like:

iptables -t nat -A POSTROUTING -o pppoe_interface \
    -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss mtuofpppoeintf-40+1: \
    -j TCPMSS --set-mss mtuofpppoeintf-40

so for example if the outgoing PPPoE interface is ppp0 with an mtu of 
1492, you would have:

iptables -t nat -A POSTROUTING -o ppp0 \
    -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: \
    -j TCPMSS --set-mss 1452

Replacing "-t nat -A POSTROUTING" with "-A FORWARD" should also work.

Before Rusty mentions that the nat&filter tables weren't meant for this
kind of stuff, let me admit that it would be conceptually neater to put
such a rule in the 'mangle' table but unfortunately the latter only has
PREROUTING and OUTPUT hooks at this time. At the PREROUTING stage the
output interface isn't known so you couldn't select packets based on
that, and the OUTPUT chain only sees packets originating from the
gateway itself.

Rusty, what would you think of adding the missing hooks to the 'mangle'
table; extending its purpose to general packet alteration, not just
changing stuff that influences routing?

I am also considering implementing a --clamp-mss-to-mtu option to the
TCPMSS extension target that would, like mssclampfw did, automatically
calculate the maximum value based on the outgoing interfaces' MTU and if
necessary adjust the packet's option value. So users would only need a
rule like:

iptables -t mangle -A POSTROUTING [-o intf] -p tcp --tcp-flags SYN,RST SYN \
        -j TCPMSS --clamp-mss-to-mtu

Opinions?

Cheers,
Marc

> 
> On Thu, 7 Sep 2000, Hartwig Felger wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Salut,
> > I got a setup, where I can surf from the box, where the ADSL is installed.
> > This box also has ISDN and Modem connected. It offers via
> > iptables-masquerading its internet-connection to other boxes in the lan.
> > This works for ISDN as well as for modem... But with dsl it makes
> > problems:
> > If I change the mru I can do ftp-downloads with lynx, but with netscape I
> > can not get the whole start-page of www.adobe.com (just for example - it
> > also does not work with other sites). When I start netscape on the server
> > itself, it works as espected. So it seams, that iptables-masqerading
> > triggers a bug in pppoe, or has a bug that is triggered by pppoe.
> > 
> > Please give me an advice, how to narrow the problem...
> > 
> 
> I think your problems are path-mtu related.
> 
> Please try Marc Boucher's mssclampfw packaged in the contrib directory
> in the pppoed-047 package at:
> 
> http://www.davin.ottawa.on.ca/pppoe
> 
> Note do not use anything else from that package for 2.4 all you need is
> contrib/mssclampfw
> 
> cheers,
> jamal
> 



<Prev in Thread] Current Thread [Next in Thread>