![]() ![]() To tell you right away: It doesn’t work for me, and it’s not going to work for you either. PMTUD attempts to discover the largest IP datagram that may be sent without fragmentation through an IP path. To avoid IP fragmentation, many TCP/IP stacks have path MTU discovery (PMTUD) implemented. ![]() That’s where IP fragmentation kicks in – which could lead to performance degradation of your VPN tunnel. Keep in mind that IPsec in tunnel mode adds an ESP header and an additional IP header for tunneling the packet (usually with an additional size of around 70-80 bytes). When a packet is nearly the size of the MTU and when you tack on this encapsulation overhead, it is likely to exceed the MTU of the outbound link. This leaves room for up to 1460 bytes of data payload per packet (also referred to as the maximum segment size MSS). In the scenario with the Android client, the MTU along the entire path is 1500. On the VPN server side, we have the interface set to a standard Ethernet MTU 1500. $ echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_discĪnd here is why. In a nutshell, I was able to fix it with the following on the VPN server: $ iptables -t mangle -A FORWARD -o eth0 \ Windows 7 built-in IPsec client: MTU 1400Īmong the tested clients, only the connection through the Android VPN client was causing the issue with stalling websites.OS X / iOS 7 built-in IPsec client: MTU 1280 (for what it’s worth, 1280 is also the minimum IPv6 packet size and thus the MTU minimum required to make IPv6 work).With PPTP and L2TP based VPNs, the MTU is reduced to 1400 (line 758 – 778). Looking at the Android Source, it appears someone must have forgotten to take care of IPsec Xauth PSK. When the Android VPN is started, it sets the MTU to 1500 on the tun0 interface:ģ3: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500 link/none ![]() Today I ran into a problem with IPsec Xauth PSK and the built-in Android VPN client (Android 4.1.2), resulting in some sites (such as not loading through the VPN tunnel. ![]()
0 Comments
Leave a Reply. |