MTU issues

[Guus Sliepen]

On Tue, Dec 10, 2013 at 11:11:31PM +0100, dorian wrote:

> >> 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.
> 
> Sorry but I do not understand this explanation.
> 
> Clear is that "it uses the destination address from the packet that was too
> big as the source" since this packet is to be sent to the originator of the
> big packet to inform him that should resend shorter packets. But the source
> address of the ICMP packet has to belong to the creator of this packet. So in
> case when it is TINC which creates the icmp packet it can use only ones of
> the router's IPs.

No, if tinc itself generates an ICMP packet (inside the VPN) then it will have
the destination address of the packet that was too big as the source address.

> Apart from above - I observed with tcpdump the interface connected to
> the clients (LAN) rather than TINC interface.
> So I should not see packets sent to the external hosts on this interface
> if the packets are created by TINC.

Correct, in that case those ICMP packets were not generated by tinc, but by the
client itself. Although it would be strange for the client to do this, since it
is unlikely that the MTU of the LAN interface is smaller than the PMTU to the
web server...

> BTW: in my setup TINC interface (tun device) has no IP at all - all the
> traffic from LAN is routed via tunnel.

Could you send us the output of "ifconfig -a" and "netstat -r -n" from the
computer running tinc, so we can see exactly how it is set up?

> > 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.
> 
> Maybe this is good testing point...
> 
> But I assumed that the UDP/TCP transport is also dynamically replaceable by
> TINC (same as MTU renegotiating for established tunnel) Was I right? Or maybe
> the kind of transport (UDP or TCP) is chosen only once at the moment of
> tunnel creation?

Tinc falls back to TCP if there is no response at all to its MTU probes. This
should happen dynamically, not only at tunnel creation. However, if there is
less than 100% packet loss or if for example the ISP drops only UDP packets of
a certain size, this is not seen by tinc as a reason to fall back to TCP.

-- 
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/20131211/a5890688/attachment-0001.sig>