> mssfix 1300 > > (won't do anything for large UDP packets inside the tunnel, but will > fix TCP. If you really need large UDP, try --fragment 1400 - but this > needs to be turned on on both sides, OpenVPN server and client, and will > cause some overhead) >
Setting link-mtu 1440 fixes it for all protocols, but I am looking for a solution that is more graceful, such as PMTUD support. I don't see why it couldn't work, since the ICMP unreachable is sent to the VPN server with the appropriate MTU for the outer IP packet. Since I am approaching this from the mobile network carrier perspective, and since we don't have control over VPN provider configs, I am looking for ways to mitigate the problem for our customers whose VPN's suddenly stopped working after they were migrated to IPv6-only. > The "I have no IPv4 default route so my local 464 component messes up > IPv4 connections through the tunnel" is annoying, but not truly surprising. > > (And the real culprit here is "Apps using IPv4 literals" - those are > the ones to blaim that apple had to add that local "DNS64-like" component > for IPv4 literals - which is now breaking the same apps in a VPN context) > > But if "push default route" works as a workaround, this can be documented > and things will be fine... I'm not sure why it works, but it does. I assume the Apple hostname resolver APIs that do the IPv4 literal NAT64 synth have some logic to only do it when there is no IPv4 available. Maybe worth asking the question to Apple on exactly how this works before documenting anything. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
