From: Alistair Tonner <Alistair@nerdnet.ca>
To: netfilter@lists.netfilter.org
Cc: oan@frozentux.net
Subject: Re: Masquarede stalls?
Date: Tue, 10 Aug 2004 17:10:17 -0400 [thread overview]
Message-ID: <200408101710.17698.Alistair@nerdnet.ca> (raw)
In-Reply-To: <200408102018.51515.Antony@Soft-Solutions.co.uk>
On August 10, 2004 03:18 pm, Antony Stone wrote:
> On Tuesday 10 August 2004 7:56 pm, Meszaros Gergely wrote:
> > Dear Antony and Jason! Many thanks for the quick response! I'm
> > enthralled.
> >
> > Unfortunately "tcpdump -n -nn -p -i ppp0 icmp" gives nothing (I hope i
> > did it well :)). (what is -nn ? I cannot find that in the manpage.)
> >
> > Are you sure this is a ICMP related problem? I can ping everything very
> > quickly and correctly from the internal net. The things go wrong
> > somewhere during the connections. :-( However you must be right, im not
> > guru.
> >
> >
> > Anthony, my ext interface is the following:
> >
> > ppp0 Link encap:Point-to-Point Protocol
> > inet addr:xxx.xxx.xxx.xxx P-t-P:192.168.0.254
> > Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492
> > Metric:1 RX packets:2255 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:3300 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0
> > RX bytes:133634 (130.5 KiB) TX bytes:1083394 (1.0 MiB)
> >
> > MTU: 1492. But I dunno it is bad or good :)
>
> That means you cannot put packets bigger than 1492 bytes down the
> interface.
>
> If you have stupid internal client machines (eg: Windows O/S) which don't
> understand that MTUs between client and server can be less than the local
> subnet, then you will not be able to communicate from those clients without
> changing the MSS (maximum segment size) at the firewall.
>
> > Its less than 1500 bytes, however by only 8. Its bad?
>
> 8 bytes is enough to cause the problem.
>
> > And whats that clamp-mss-to-mtu thing ? :)
>
> iptables -t mangle -A POSTROUTING -o EXTIF -j TCPMSS --clamp-mss-to-mtu
>
> Regards,
>
Again Antony -- bang on the money as always Thanks for all your work.
For the record, I use this rule *always* -- but then I don't deal with really
large LANs behind the firewall -- anyone care to comment on the affect of
this in large bandwidth implementations?
Alistair Tonner
Please note that I have cc: Oskar directly -- if I have done something
brutally wrong in the below, beat me over the head with a LART and let Oskar
know I haven't the faintest clue what I'm doing *grin*
For Oskar Andreasson ---->
Oskar:
For iptables-tutorial 6.5 section "Targets Jumps"
6.5.16 TCPMSS targe
This target takes the options --clamp-mss-to-mtu or --set-mss (value)
The objective of this target is to ensure that packets are no larger than a
certain MSS (Maximum Segment Size) or (Maximum Transfer Unit - 40 )
for a specific route. This is commonly used when firewalling a LAN made up
of systems that may not correctly perform Path MTU discovery, or may not be
recieving ICMP messages that indicate there is an Path MTU problem.
It may be advantageous to put rules with this target in the mangle
POSTROUTING table, with filters to specific output devices i.e.
iptables -A POSTROUTING -t mangle -o ${EXTERNAL_INTERFACE} -j TCPMSS \
--clamp-mss-to-pmtu
in order to ensure that your client connection(s) packet(s) will always
fit in the MTU of the device which they go out to the internet through.
when used:
iptables -A POSTROUTING -t mangle -o ${ANY_DEVICE} -j TCPMSS \
--set-mss 596
it will lock the Maximum Segment Size for that device. This is useful when
tunneling TCP/IP through other protocols where the frame size may be smaller
or larger than 1500 bytes. Please note that MSS is not the packet size, but
rather MTU - 40 bytes.
This cures the problems that many folks have had with DSL (typical MTU of DSL
connections is 1492 -- 1500 byte ethernet frame - 8 byte ppp packet header.)
If your connections through the firewall start normally but hang abruptly
without returning complete data, you might look into this feature.
next prev parent reply other threads:[~2004-08-10 21:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-10 18:33 Masquarede stalls? Jason Opperisano
2004-08-10 18:56 ` Meszaros Gergely
2004-08-10 19:18 ` Antony Stone
2004-08-10 21:10 ` Alistair Tonner [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-10 19:13 Jason Opperisano
2004-08-10 20:22 ` Mészáros Gergely
2004-08-11 5:05 ` Alistair Tonner
2004-08-10 20:24 ` Meszaros Gergely
2004-08-10 22:35 ` Alistair Tonner
2004-08-10 22:48 ` Antony Stone
2004-08-10 18:23 Meszaros Gergely
2004-08-10 18:31 ` Antony Stone
2004-08-10 18:20 Mészáros Gergely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200408101710.17698.Alistair@nerdnet.ca \
--to=alistair@nerdnet.ca \
--cc=netfilter@lists.netfilter.org \
--cc=oan@frozentux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.