TCPMSS workaround on OUTPUT?

TCPMSS workaround on OUTPUT?

[John Hawley]

Hello.

I've been trying to figure out the solution to the old "unable to browse
to certain web site" problem for the past several days.  Am on kernel
2.4.19, iptables version 1.2.6a, on a Debian machine.

I have ipt_TCPMSS and ipt_tcpmss loaded as modules, with all the other
netfilter related stuff compiled into the kernel.

I inserted this line into my iptables.rules:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

Now, this does seem to have fixed it for clients behind this firewall.

The question is, how do I fix this for the firewall machine itself? 
Iptables does seem to accept the above rule for the OUTPUT chain, but
seems to have no effect.

The reason it'd be nice for this to work is that this is for a small
remote office in which we have Squid running on the firewall machine.  I
had to turn Squid off since the FORWARD chain fix obviously wouldn't
apply here.

Any suggestions?

-- 
John Hawley
BGEA / Info Tech Svcs
612.335.1334
jhawley@bgea.org

Re: TCPMSS workaround on OUTPUT?

[Thomas Lussnig]

John Hawley wrote:

>Hello.
>
>I've been trying to figure out the solution to the old "unable to browse
>to certain web site" problem for the past several days.  Am on kernel
>2.4.19, iptables version 1.2.6a, on a Debian machine.
>
>I have ipt_TCPMSS and ipt_tcpmss loaded as modules, with all the other
>netfilter related stuff compiled into the kernel.
>
>I inserted this line into my iptables.rules:
>
>iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
>-j TCPMSS --clamp-mss-to-pmtu
>
>Now, this does seem to have fixed it for clients behind this firewall.
>
>The question is, how do I fix this for the firewall machine itself? 
>Iptables does seem to accept the above rule for the OUTPUT chain, but
>seems to have no effect.
>
>The reason it'd be nice for this to work is that this is for a small
>remote office in which we have Squid running on the firewall machine.  I
>had to turn Squid off since the FORWARD chain fix obviously wouldn't
>apply here.
>
>Any suggestions?
>
Hi,
first your entry is working, but i think that the filter could 
"--tcp-flags SYN,RST,ACK SYN"
Because "ACK,SYN" as part 2 of the handshake there the MSS should 
already be known.
And i think that you should tell the direction (-o ppp+ maybe)

Local packages should know the correct size since the interface (DSL 
maybe) have the correct mtu.

Examplke
 > ip ad li ppp0
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc cbq qlen 3
    link/ppp
    inet 217.233.244.33 peer 217.5.98.168/32 scope global ppp0

Try this
ip ro ch 10.0.1.0/24 dev eth1 advmss 1490
on my networked this make all things working nice WITHOUT the 
clamp-mss-to-pmtu iptables entry.

Cu Thomas Luflnig

Re: TCPMSS workaround on OUTPUT?

[John Hawley]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Thu, 2002-09-26 at 15:56, Thomas Lussnig wrote:


    first your entry is working, but i think that the filter could 
    "--tcp-flags SYN,RST,ACK SYN"
    Because "ACK,SYN" as part 2 of the handshake there the MSS should 
    already be known.

well, I was just copying ver batim out of the kernel build docs ...

    And i think that you should tell the direction (-o ppp+ maybe)
    
    Local packages should know the correct size since the interface (DSL 
    maybe) have the correct mtu.

ok, so is there a kernel bug?  I dont seem to have this problem on
kernels previous to 2.4.18.  That is, that the fw machine itself can't
browse these web sites.  The two situations I've seen so far are:  (1)
fw (kernel 2.4.18) --> Cisco router with fractional T1 and (2) fw
(kernel 2.4.19) --> Lucent Pipeline on ISDN.

    
    Examplke
     > ip ad li ppp0
    19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc cbq qlen 3
        link/ppp
        inet 217.233.244.33 peer 217.5.98.168/32 scope global ppp0
    
    Try this
    ip ro ch 10.0.1.0/24 dev eth1 advmss 1490
    on my networked this make all things working nice WITHOUT the 
    clamp-mss-to-pmtu iptables entry.


didn't help

    
    Cu Thomas Lußnig
    
    

-- 
John Hawley
BGEA/ITS <=> Network Admin
612.335.1334
jhawley@bgea.org

[-- Attachment #2: Type: text/html, Size: 3237 bytes --]