Change MTU for forwarded packets

George Borisov · External Since: Aug 18, 2006 Posts: 15

Hello,

We have an IPSec VPN link between the UK and South Africa.
Unfortunately one of the routers upstream from our South Africa
firewall mangles large packets (e.g. only 2/3 chunks of a 4000
byte ping will be received.)

This was causing problems for LAN-to-LAN communication. Things
like SSH would work, but RDP would not.

We have managed to get around the problem by setting the MTU on
the UK LAN machines to 1328 (0x530, which is why it's so random.)

The obvious problem is that this needs to be done on every
machine on the network, which is a bit of a pain (especially as
we want to avoid rebooting the Windows servers.)

Is there a way of forcing an MTU size for forwarded traffic on
the firewall?

I have tried playing with TCPMSS in iptables, but I haven't
managed to get it to work.

Thank you in advance,

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Phil Dyer · External Since: Jan 12, 2006 Posts: 6

on 2006-08-18 at 11:25, George Borisov wrote:
> Hello,
>
> We have an IPSec VPN link between the UK and South Africa.
> Unfortunately one of the routers upstream from our South Africa
> firewall mangles large packets (e.g. only 2/3 chunks of a 4000
> byte ping will be received.)

[snip]

> Is there a way of forcing an MTU size for forwarded traffic on
> the firewall?
>

you can set the mtu using tools like ifconfig and iproute2. You can
actually set the mtu in /etc/network/interfaces, too.

--
phil

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

George Borisov · External Since: Aug 18, 2006 Posts: 15

Phil Dyer wrote:
>
> you can set the mtu using tools like ifconfig and iproute2. You can
> actually set the mtu in /etc/network/interfaces, too.

Cool, iproute2 does that as well? Smile

I did try setting it with ifconfig on the internal and it did not
work. That said, I did mostly test with ping and does that even
respect MTU size?

Testing it now, even on the Windows boxes with the reduced MTU
the ping packets fragment to 1500.

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Pascal Hambourg · External Since: Jan 10, 2006 Posts: 48

Hello,

George Borisov a écrit :
>
> Is there a way of forcing an MTU size for forwarded traffic on
> the firewall?

Yes, if the firewall is a router (not a bridge). You just set the
desired MTU on the output interface.

> I have tried playing with TCPMSS in iptables, but I haven't
> managed to get it to work.

Be aware that TCPMSS works only with TCP connections, not with other
protocols like UDP or ICMP.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

George Borisov · External Since: Aug 18, 2006 Posts: 15

Pascal Hambourg wrote:
>
> Yes, if the firewall is a router (not a bridge). You just set the
> desired MTU on the output interface.

This confuses me a little.

If by outgoing you mean the external interface on my firewall
then why did changing the MTU on the LAN computers fix the problem?

Surely the MTU should be set on the internal interface, so as to
force all of the LAN clients to send smaller packets?

Please bear with me while I try and get my head around all this
stuff. :-$

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Pascal Hambourg · External Since: Jan 10, 2006 Posts: 48

George Borisov a écrit :
> Pascal Hambourg wrote:
>
>>Yes, if the firewall is a router (not a bridge). You just set the
>>desired MTU on the output interface.
>
> This confuses me a little.
>
> If by outgoing you mean the external interface on my firewall

Yes, that's what I mean.

> then why did changing the MTU on the LAN computers fix the problem?

Probably because the LAN hosts won't send packets bigger than their MTU.
Besides, they will use that local MTU to compute the MSS they send to
the other hosts when establishing a TCP connection, so the other hosts
won't send packets bigger than the transmitted MSS + TCP header size.

When you reduce the firewall's external interface MTU, packets forwarded
from a LAN host to the outside bigger than the MTU (plus IPSec the
encapsulation) will be fragmented if they have the DF (Don't Fragment)
flag cleared, or discarded with an ICMP fragmentation-needed error
message otherwise. However it won't change the TCP MSS transmitted by
LAN hosts unless they use Path MTU Discovery (PMTU).

> Surely the MTU should be set on the internal interface, so as to
> force all of the LAN clients to send smaller packets?

If you mean the firewall's internal interface, I'm afraid this would be
ineffective, because it won't force the LAN hosts to send smaller
packets : the T in MTU stands for "Transmit", which applies to packets
transmitted (either locally generated or forwarded) by the local host on
this interface.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

George Borisov · External Since: Aug 18, 2006 Posts: 15

Pascal Hambourg wrote:
>
> Probably because the LAN hosts won't send packets bigger than their MTU.
> Besides, they will use that local MTU to compute the MSS they send to
> the other hosts when establishing a TCP connection, so the other hosts
> won't send packets bigger than the transmitted MSS + TCP header size.
>
> When you reduce the firewall's external interface MTU, packets forwarded
> from a LAN host to the outside bigger than the MTU (plus IPSec the
> encapsulation) will be fragmented if they have the DF (Don't Fragment)
> flag cleared, or discarded with an ICMP fragmentation-needed error
> message otherwise. However it won't change the TCP MSS transmitted by
> LAN hosts unless they use Path MTU Discovery (PMTU).

So what you are saying is that is does not matter what the MTU on
the LAN hosts' packets is because they will be wrapped in the
IPSec encapsulation anyway? I could set a lower MTU on the
external interfaces of the two IPSec firewalls and then it should
all work?

> If you mean the firewall's internal interface, I'm afraid this would be
> ineffective, because it won't force the LAN hosts to send smaller
> packets : the T in MTU stands for "Transmit", which applies to packets
> transmitted (either locally generated or forwarded) by the local host on
> this interface.

I think I am beginning to understand this better. You see, I
originally thought the LAN hosts and the internal interface of
the firewall used the lowest one between the two. :-/

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Bazy · External Since: May 24, 2006 Posts: 5

Hello guys,

I have a VPN, ip-ip, encrypted, made with vtun
(http://vtun.sourceforge.net) thru which I connect 2 offices thru a
metropolitan network. Place 2 is getting out on the internet thru
place 1...

The people from place 2 were happy with their internet, but they could
not see http of microsoft.com, opera.com, sourceforge… And the problem
was the MTU.

So then I searched google and applied this rule to my VPN interface:

iptables -I FORWARD -o $VPN_INTERFACE -p tcp --tcp-flags SYN,RST SYN
-j TCPMSS --clamp-mss-to-pmtu

$VPN_INTERFACE in your case would be "ipsec" I think…

I applied it on both sides of the VPN.

So... your using PMTU when SYN are sent... the MTU problem should not
appear... Thought I may be wrong… Most of the times I am Smile

On 8/18/06, George Borisov <george RemoveThis @dxsolutions.co.uk> wrote:
> Pascal Hambourg wrote:
> >
> > Probably because the LAN hosts won't send packets bigger than their MTU..
> > Besides, they will use that local MTU to compute the MSS they send to
> > the other hosts when establishing a TCP connection, so the other hosts
> > won't send packets bigger than the transmitted MSS + TCP header size.
> >
> > When you reduce the firewall's external interface MTU, packets forwarded
> > from a LAN host to the outside bigger than the MTU (plus IPSec the
> > encapsulation) will be fragmented if they have the DF (Don't Fragment)
> > flag cleared, or discarded with an ICMP fragmentation-needed error
> > message otherwise. However it won't change the TCP MSS transmitted by
> > LAN hosts unless they use Path MTU Discovery (PMTU).
>
> So what you are saying is that is does not matter what the MTU on
> the LAN hosts' packets is because they will be wrapped in the
> IPSec encapsulation anyway? I could set a lower MTU on the
> external interfaces of the two IPSec firewalls and then it should
> all work?
>
> > If you mean the firewall's internal interface, I'm afraid this would be
> > ineffective, because it won't force the LAN hosts to send smaller
> > packets : the T in MTU stands for "Transmit", which applies to packets
> > transmitted (either locally generated or forwarded) by the local host on
> > this interface.
>
> I think I am beginning to understand this better. You see, I
> originally thought the LAN hosts and the internal interface of
> the firewall used the lowest one between the two. :-/
>
>
> --
> George Borisov
>
> DXSolutions Ltd
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-REQUEST RemoveThis @lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian..org
>
>

Matt Ryan · External Since: Sep 29, 2006 Posts: 2

George Borisov wrote:
> I think I am beginning to understand this better. You see, I
> originally thought the LAN hosts and the internal interface of
> the firewall used the lowest one between the two. :-/

Only if you have pMTU running successfully end-to-end. That requires
ICMP working end-to-end which I think I read was a problem with your
set-up...

Matt.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

George Borisov · External Since: Aug 18, 2006 Posts: 15

Matt Ryan wrote:
>
> Only if you have pMTU running successfully end-to-end. That requires
> ICMP working end-to-end which I think I read was a problem with your
> set-up...

What's the best way to test this sort of stuff?

I must admit I am still confused. I reduced the MTU on both
internal and external interfaces of the firewall, but I am still
having problems. (Client PCs in SA have trouble connecting to the
Exchange server in the UK; reducing the MTU on the client PC
fixed it.)

In addition, reducing the MTU on the internal interface broke
access to some websites (e.g. microsoft.com :-p) How does that
one work? 8-/

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Matt Ryan · External Since: Aug 24, 2006 Posts: 2

George Borisov wrote:
> Matt Ryan wrote:
>> Only if you have pMTU running successfully end-to-end. That requires
>> ICMP working end-to-end which I think I read was a problem with your
>> set-up...
>
> What's the best way to test this sort of stuff?
>
> I must admit I am still confused. I reduced the MTU on both
> internal and external interfaces of the firewall, but I am still
> having problems. (Client PCs in SA have trouble connecting to the
> Exchange server in the UK; reducing the MTU on the client PC
> fixed it.)
>
> In addition, reducing the MTU on the internal interface broke
> access to some websites (e.g. microsoft.com :-p) How does that
> one work? 8-/

Microsoft is notorious for acting badly in the scenario where the
end-to-end MTU is less than 1500 bytes. That said, poor practise on
setting up firewall rules (blocking all ICMP) is just as bad as pMTU
(http://en.wikipedia.org/wiki/PMTU) then also fails. To avoid any
problems you need to have a end-to-end connection that can manage 1500
bytes packets. If you can't do that then you need to either use a
tunnelling technique that allows transparent segmentation/reassembly of
packets that exceed MTU (Cisco routers will allow this with GRE and
perhaps L2TPv3) or lower the MTU on all clients. Testing using 'ping -s
1500 <dest_ip>' is the best option to check everything will work.

Matt.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

George Borisov · External Since: Aug 18, 2006 Posts: 15

Matt Ryan wrote:
>
> Microsoft is notorious for acting badly in the scenario where the
> end-to-end MTU is less than 1500 bytes. That said, poor practise on
> setting up firewall rules (blocking all ICMP) is just as bad as pMTU
> (http://en.wikipedia.org/wiki/PMTU) then also fails.

Yeah, it's particularly annoying when our firewalls explicitly
allow all ICMP packets, but some get filtered out in transit
anyway. Sad

> Testing using 'ping -s
> 1500 <dest_ip>' is the best option to check everything will work.

This always worked, regardless of the other problems we were having.

Ah well, if all else fails, we do have an MTU .reg patch that we
can apply on all clients through Group Policy.

--
George Borisov

DXSolutions Ltd

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Matt Ryan · External Since: Aug 24, 2006 Posts: 2

George Borisov wrote:
> Matt Ryan wrote:
>> Testing using 'ping -s
>> 1500 <dest_ip>' is the best option to check everything will work.
>
> This always worked, regardless of the other problems we were having.

My bad. Install the iputils-ping package (if its not already) and use
'ping -s 1472 -M do <dest ip>'. Increment/decrement the '-s' parameter
until you see where the MTU breaks.

Matt.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org