MTU issues

[Guus Sliepen]

On Tue, Dec 10, 2013 at 07:13:49PM +0100, dorian wrote:

> For sure the problem is not a matter of MSS as http requests to the
> "problematic" http servers opened new TCP sessions (I've seen full
> triple TCP handshake starting with SYN packets)

Ok.

> It is also not a "general" GPRS transmission problem since other http
> servers were available.
> 
> According tcpdump output  ICMP Fragmentation Needed packets are sent by
> clients (with src addresses of the clients) rather than TINC itself (I
> understand that in this case the src IP should the router's one).
> Btw: TINC is sitting at gateway.

It depends on which interface exactly you ran tcpdump on. Tinc itself does not
have an IP address, when it generates an ICMP Fragmentation Needed packet, it
uses the destination address from the packet that was too big as the source
address for the ICMP packet. So it might only look like it is from the client.

> Down/up of the tunnel immediately removes the problem
> 
> Therefore I assumed that there was a matter of MTU.
> 
> But if MTU is dynamically adopted to the current connection state I have
> no idea what to look for...

It would be interesting to run tinc with the options -d5
--logfile=/tmp/tinc.log for ten minutes or so, without sending any traffic over
the VPN. Then check the logs to see what happens with the PMTU probes. It would
be helpful if you could send a copy of that log.

Instead of an MTU problem it could also be that the mobile provider is dropping
(certain) UDP packets, as they might associate it with VoIP traffic which they
might want to block. Using the TCPOnly option might help in this case.

-- 
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: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20131210/6f55272e/attachment.sig>