sinshiva
Very Senior Member
[edit] these are for TUN users, not TAP [/edit]
I spent some (more) time wiresharking openvpn over the last few days. I had already done so with UDP, but still needed to with TCP. My goal for both was to find the ideal tun-mtu.
My method:
- I disabled MSS clamping, etc., manually set the MTU of br0 and vlan1 to equal my WAN MTU. After setting a new MTU, I prefer to add the rule manually to iptables like thus;
iptables -I FORWARD -o tun21 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1408:65535 -j TCPMSS --set-mss 1407
using TCPMSS and finding the right mtu means not having to use mssfix/fragment openvpn options
I would then connect the openvpn client to the server while using wireshark to listen at the physical network interface. with UDP, the tunnel would fragment above a certain tun-mtu while with TCP, it would just set a huge window size and stuff a bunch of TCP segments in. The issue I encountered with this method with TCP is that this is harder to test from the LAN. i tested with various speedtests and ping for each tun-mtu. it is a good idea to use different servers for each mtu/speedtest as they seem to remember to use large windows, regardless of mtu, for a while
regardless, with my settings, I arrived at specific tun-mtus;
UDP:
AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
auth sha1 (implicit)
(comp-lzo disabled, mssfix/fragment unused)
tun-mtu= 85 bytes less than WAN MTU (suggest: 1407)
TCP:
AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
auth sha1 (implicit)
(comp-lzo disabled, mssfix/fragment unused)
tun-mtu= 101 bytes less than WAN MTU (suggest: 1391)
(comp-lzo reduces mtu by 1 byte, fragment reduces mtu by 4 bytes, mssfix does weird things, auth sha1 (default) is worth 20 bytes, sha256 is 32 and sha512 is 64)
anyway, with the above settings, the exterior of either tunnel doesn't fragment or end up consistently in a massive window for full size packets)
final note; if you intend to use your tunnels at wifi hotspots, you should know that most I've seen, such as at mcdonalds or starbucks, are PPPoE connected, in which case you should base your tunnels on that WAN MTU, even if you are not PPPoE at home. For this reason, I've based my above examples on a 1492 WAN MTU
getting ~0.65 down remotely of my 0.75 upload
anybody want to verify?
I spent some (more) time wiresharking openvpn over the last few days. I had already done so with UDP, but still needed to with TCP. My goal for both was to find the ideal tun-mtu.
My method:
- I disabled MSS clamping, etc., manually set the MTU of br0 and vlan1 to equal my WAN MTU. After setting a new MTU, I prefer to add the rule manually to iptables like thus;
iptables -I FORWARD -o tun21 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1408:65535 -j TCPMSS --set-mss 1407
using TCPMSS and finding the right mtu means not having to use mssfix/fragment openvpn options
I would then connect the openvpn client to the server while using wireshark to listen at the physical network interface. with UDP, the tunnel would fragment above a certain tun-mtu while with TCP, it would just set a huge window size and stuff a bunch of TCP segments in. The issue I encountered with this method with TCP is that this is harder to test from the LAN. i tested with various speedtests and ping for each tun-mtu. it is a good idea to use different servers for each mtu/speedtest as they seem to remember to use large windows, regardless of mtu, for a while
regardless, with my settings, I arrived at specific tun-mtus;
UDP:
AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
auth sha1 (implicit)
(comp-lzo disabled, mssfix/fragment unused)
tun-mtu= 85 bytes less than WAN MTU (suggest: 1407)
TCP:
AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
auth sha1 (implicit)
(comp-lzo disabled, mssfix/fragment unused)
tun-mtu= 101 bytes less than WAN MTU (suggest: 1391)
(comp-lzo reduces mtu by 1 byte, fragment reduces mtu by 4 bytes, mssfix does weird things, auth sha1 (default) is worth 20 bytes, sha256 is 32 and sha512 is 64)
anyway, with the above settings, the exterior of either tunnel doesn't fragment or end up consistently in a massive window for full size packets)
final note; if you intend to use your tunnels at wifi hotspots, you should know that most I've seen, such as at mcdonalds or starbucks, are PPPoE connected, in which case you should base your tunnels on that WAN MTU, even if you are not PPPoE at home. For this reason, I've based my above examples on a 1492 WAN MTU
getting ~0.65 down remotely of my 0.75 upload
anybody want to verify?
Last edited:
