MTU, PMTU & DF flag

[Guus Sliepen]

On Wed, May 13, 2015 at 04:41:30PM +0200, Florent B wrote:

> I have MTU problems when all these conditions are true:
> - a client is running Ubuntu (ICMP messages about PMTUd are ignored on
> it by default)

I have no experience with Ubuntu, but I find it hard to believe it would
block ICMP Fragmentation Needed packets out of the box.

> - a client is accessing us from a particular network
> - the client is accessing a backend VM which is not on the load-balancer
> node (so Tinc is used)
> 
> When this client tries to send to us a lot of data (large form, or file
> upload), packets seem to not reach backend server.
> He does not have any problem for reading web pages or download files.
> Only when he uploads to us.
> 
> When the client is accessing our network from a network where its PMTU
> is 1460 (tracepath to us), upload requests fail.
> When the same client is accessing our network from another network where
> its PMTU is 1462, upload is successful.
> When the same client is accessing our network from another network where
> its PMTU is 1500, upload requests fail.

Can you check what tinc thinks the PMTU is in each of these cases? With
tinc 1.0.24, you do "tincd -n <netname> -kUSR2", and it will send a list
of nodes to the syslog. The MTU should be in it.

> I know that situation is very particular, I don't know if I explain well
> the facts...

It would be good to see a diagram of the network path between the client
and the backend server, which parts of the real network have which MTU
(if you know), and which part of the path goes via tinc.

> Tinc does not seem to be "transparent" in this situation... I don't know
> exactly how or when... Maybe Tinc sends to client ICMP messages about
> fragmentation ? But client ignores them... so I expected Tinc to
> fragment them even if DF flag is set.

Tinc never fragments packets with the Don't-Fragment flag set. That's
the whole point of the flag. It indeed sends ICMP Fragmentation Needed
packets in response to packets that are too large and have the DF bit
set. It also sets the MSS header in SYN packets to an appropriate value.
If something is blocking the ICMP packets or the client is ignoring it,
it is not tinc's fault.

But things might be different if your traffic inside the VPN has VLAN
tags or is encapsulated in some other way...

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20150513/d02eb107/attachment.sig>