[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] ADSL->ADSL OpenVPN, what MTU? 1492?

  • Subject: Re: [Openvpn-users] ADSL->ADSL OpenVPN, what MTU? 1492?
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Fri, 22 Apr 2005 12:30:18 -0600 (MDT)

On Fri, 22 Apr 2005, Gregory G Carter wrote:

> Jason Haar wrote:
> >James Yonan wrote:
> >
> >  
> >
> >>OpenVPN shouldn't really need to participate in this process, because if 
> >>the kernel sees a large message trying to route through an interface with 
> >>a small MTU (even if this is a TUN/TAP interface), it should by default 
> >>drop the packet and bounce back an ICMP "fragmentation needed but DF set" 
> >>message back to the sender, which OpenVPN would duly forward.
> >>
> >>    
> >>
> True...but it doesn't.

Did you try any of the different --mtu-disc options?  On linux, these will 
give hints to the kernel on how to handle PMTU -- ultimately PMTU is 
handled by the kernel.

> >>Sometimes, however, this process breaks because firewalls filter out the 
> >>relevant ICMP messages.
> >>    
> >>
> I have the following rules in place on all my firewalls:
> iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
> iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT
> If there is some other icmp type related to mtu path discovery I am 
> missing, perhaps someone could point it out???
> If indeed, openvpn is simply forwarding MTU path discovery messages, 
> then why isn't this working and why do I not see such messages from OpenVPN?

You need to establish (a) whether fragmentation-needed messages are in
fact being generated by the kernel when it sees an oversize packet for the
MTU of the underlying interface and (b) whether or not OpenVPN is seeing
and forwarding the ICMP messages (try tcpdump on the tunnel interface).

> OpenVPN is broken I think in this aspect, or at least 1.6.0 which is 
> what I am currently using is the case.
> I will be upgrading of course now that 2.0 is out, but that will be a 
> daunting task as I have many openvpn tunnels.  In fact, just this week I 
> will be adding 3 more.

A lot of MTU problems vanished with 2.0 simply because the community
experience with 1.6 helped us to choose better defaults for the MTU
parameters.  Try 2.0 and let us know if the problems persist.


Openvpn-users mailing list