From mboxrd@z Thu Jan 1 00:00:00 1970 From: "s" Subject: NAT PPPOE & MTU problems Date: Thu, 29 May 2003 14:36:47 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <000801c325de$f89fde60$1800a8c0@ckznak.pl> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C325EF.BB9AC640" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: netfilter@lists.netfilter.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C325EF.BB9AC640 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I've got a problem with NAT connections on PPPOE. My box is connected to internet via DSL, and I have some computers = behind NAT.=20 I changed MTU on internal interfaces to 1492 and configured iptables = with: iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS = --clamp-mss-to-pmtu also I have squid cache installed for local workstations. When I surfing net without squid everything works fine, no timeouts or = something. Is good. But when I use squid as a cache sometimes when squid uses POST method = with huge amount of parameters, connection hangs. On tcpdump I see that = one packet is repeated few times (5) and I got timeout message. What's wrong ? Repeated packet has 1492 bytes lenght. But there's no = answer from www server. Pozdraviam Przemyslaw Borkowski ------=_NextPart_000_0005_01C325EF.BB9AC640 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I've got a problem with NAT connections = on=20 PPPOE.

My box is connected to internet via = DSL, and I have=20 some computers behind NAT.

I changed MTU on internal interfaces to = 1492 and=20 configured iptables with:

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

also I have squid cache installed for = local=20 workstations.

When I surfing net without squid = everything works=20 fine, no timeouts or something. Is good.

But when I use squid as a cache = sometimes=20 when squid uses POST method with huge amount of parameters, connection = hangs. On=20 tcpdump I see that one packet is repeated few times (5) and I got = timeout=20 message.

What's wrong ? Repeated packet = has 1492 bytes=20 lenght. But there's no answer from www server.

Pozdraviam

Przemyslaw=20 Borkowski

------=_NextPart_000_0005_01C325EF.BB9AC640-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Stark Subject: Re: NAT PPPOE & MTU problems Date: 12 Jun 2003 00:49:53 -0400 Sender: netfilter-admin@lists.netfilter.org Message-ID: <877k7roq6m.fsf@stark.dyndns.tv> References: <000801c325de$f89fde60$1800a8c0@ckznak.pl> Mime-Version: 1.0 Return-path: In-Reply-To: <000801c325de$f89fde60$1800a8c0@ckznak.pl> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: s Cc: netfilter@lists.netfilter.org "s" writes: > I've got a problem with NAT connections on PPPOE. > My box is connected to internet via DSL, and I have some computers behind NAT. > I changed MTU on internal interfaces to 1492 and configured iptables with: > > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu > > also I have squid cache installed for local workstations. When I surfing net > without squid everything works fine, no timeouts or something. Is good. But > when I use squid as a cache sometimes when squid uses POST method with huge > amount of parameters, connection hangs. On tcpdump I see that one packet is > repeated few times (5) and I got timeout message. What's wrong ? Repeated > packet has 1492 bytes lenght. But there's no answer from www server. You might try smaller MTUs. 1492 should work with PPPOE in theory, but some PPPOE based DSL providers seem to have internal networks that impose additional constraints. I find my own packets don't seem to get out if they're over 1480 or so (it seems to vary). Also, does your provider have a transparent proxy? One transparent proxy I've seen misbehaved in precisely the manner you're describing. There was no way around the bug, and people complained incessantly on the support newsgroups. I eventually just switched providers. -- greg From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sven Schuster Subject: Re: NAT PPPOE & MTU problems Date: Sat, 14 Jun 2003 21:36:48 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <3EEB7950.5000000@gmx.de> References: <000801c325de$f89fde60$1800a8c0@ckznak.pl> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: s Cc: netfilter@lists.netfilter.org s wrote: > I've got a problem with NAT connections on PPPOE. > My box is connected to internet via DSL, and I have some computers > behind NAT. > I changed MTU on internal interfaces to 1492 and configured iptables with: > > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS > --clamp-mss-to-pmtu > also I have squid cache installed for local workstations. > When I surfing net without squid everything works fine, no timeouts or > something. Is good. > But when I use squid as a cache sometimes when squid uses POST method > with huge amount of parameters, connection hangs. On tcpdump I see > that one packet is repeated few times (5) and I got timeout message. > What's wrong ? Repeated packet has 1492 bytes lenght. But there's no > answer from www server. > > Pozdraviam > Przemyslaw Borkowski I think the problem here is that squid will establish a connection locally from your box. So when your computers on the internal net surf directly, the MSS will be clamped to PMTU via your FORWARD rule. When your clients surf via your squid proxy, the SYN pakets MSS aren't clamped to PMTU. So, you'll need the same rule to clamp the MSS for your OUTPUT rule. Hope this helps Sven