suggested MSS feature for "proto tcp" operation

starlight

We are using OpenVPN 2.1 to traverse a Cisco ASA firewall and are running in TCP mode since the firewall is configured to block UDP. Discovered that by default the ASA rewrites the MSS field in all new connections with the value 1380. This is intended to guarantee TCP packets will fit in IPSEC tunnels without fragmentation, but is applied to all traffic regardless of whether it traverses an IPSEC tunnel.

Presently OpenVPN is unaware of the MSS adjustment and the default MSS values result in packet fragmentation in the OpenVPN tunnel. We found that this is corrected with "link-mtu 1368" added to the configuration on both ends. Possibly "tun-mtu 1420" would produce the same effect but we did not try it.

Suggestion is to have OpenVPN read the connection MSS value with a 'getsockopt(TCP_MAXSEG)' call and then calculate the optimal tunnel inner MTU value using it.

Also could the documentation for "tun-mtu" and "link-mtu" be expanded and clarified somewhat? Found it confusing and had to experiment quite a bit to figure it out.

starlight

Here is the calculation (back up with 'tcpdump' traces) used to arrive at the 1368 value:

Rationale for "link-mtu 1368"

results in 'tunX' MTU 1325

  1325    # tunnel inner MTU
    43+   # openvpn and ssl packet overhead
  1368=   # in practice max size is 1367, only see 1368 when packet splits
    20+   # IP header
    12+   # IP time-stamp option
    20+   # TCP header
  1420=   # effective tunnel outer MTU

  1380    # TCP MSS value forced by ASA 5500
    20+   # IP header
    20+   # TCP header
  1420=   # effective tunnel outer MTU

  1325    # tunnel inner MTU
    20-   # IP header
    20-   # TCP header
  1285=   # default TCP MSS for connections through tunnel

MSS 1380 value force by Cisco ASA 5500.
By default configuration directive
"sysopt connection tcpmss 1380".

NOTE: Linux default MSS is 1460 (1500 - 40).