Cannot send larger fragments than 71 bytes (!). How to set tun-mtu/link-mtu/mssfix?

[nobaq]

Hi,

I am using OpenVPN 2.4.8 on Win 10 to connect to a Sophos SSL-VPN endpoint (runs OpenVPN under the hood and I don't want to use the Sophos client since I am using OpenVPN anyway).

This is my client config:

View OriginalClient config

1

2

3

ip-win32 dynamic

4

5

client

6

7

dev tun

8

9

proto tcp

10

11

verify-x509-name "[...]"

12

13

route remote_host 255.255.255.255 net_gateway

14

15

resolv-retry infinite

16

17

nobind

18

19

persist-key

20

21

persist-tun

22

23

dev-node "OpenVPN"

24

25

pull-filter ignore redirect-gateway

26

27

route 192.168.20.0 255.255.255.0 vpn_gateway 3

28

29

<ca>

30

--STRIPPED INLINE CA CERT--

31

</ca>

32

33

<cert>

34

--STRIPPED INLINE CERT--

35

</cert>

36

37

<key>

38

--STRIPPED INLINE KEY--

39

</key>

40

41

auth-user-pass

42

43

cipher AES-128-CBC

44

45

auth SHA256

46

47

comp-lzo no

48

49

route-delay 4

50

51

verb 3

52

53

reneg-sec 0

54

55

remote [...] 8443

56

1

ip-win32 dynamic

2

client

3

dev tun

4

proto tcp

5

verify-x509-name "[...]"

6

route remote_host 255.255.255.255 net_gateway

7

resolv-retry infinite

8

nobind

9

persist-key

10

persist-tun

11

dev-node "OpenVPN"

12

pull-filter ignore redirect-gateway

13

route 192.168.20.0 255.255.255.0 vpn_gateway 3

14

<ca>

15

--STRIPPED INLINE CA CERT--

16

</ca>

17

<cert>

18

--STRIPPED INLINE CERT--

19

</cert>

20

<key>

21

--STRIPPED INLINE KEY--

22

</key>

23

auth-user-pass

24

cipher AES-128-CBC

25

auth SHA256

26

comp-lzo no

27

route-delay 4

28

verb 3

29

reneg-sec 0

30

remote [...] 8443

I am suffering from severe connection issues. It seems that the tunnel cannot transport anything larger than 71 byes!

Code: Select all

C:\Windows\System32>ping 192.168.20.144 -f -l 71

Pinging 192.168.20.144 with 71 bytes of data:
Reply from 192.168.20.144: bytes=71 time=23ms TTL=63
Reply from 192.168.20.144: bytes=71 time=24ms TTL=63
Reply from 192.168.20.144: bytes=71 time=23ms TTL=63
Reply from 192.168.20.144: bytes=71 time=27ms TTL=63

Ping statistics for 192.168.20.144:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 27ms, Average = 24ms

C:\Windows\System32>ping 192.168.20.144 -f -l 72

Pinging 192.168.20.144 with 72 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.20.144:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Windows\System32>

I played around with tun-mtu, link-mtu and mssfix (as well as changing the MTU value of the TAP-Windows adapter) but I have not found any setting that works. However, when I set for example "tun-mtu 1200" in my client config I see the following warnings when connecting:

Code: Select all

Mon Mar 16 14:46:38 2020 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1200)
[...]
Mon Mar 16 14:46:40 2020 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1272', remote='link-mtu 1572'
Mon Mar 16 14:46:40 2020 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1200', remote='tun-mtu 1500'

The interesting part: link-mtu is exactly 72 bytes larger than tun-mtu and for some weird reason the Sophos VPN server seems to set 1572 .... 1572-1500=72 ... can't be a coincidence that my largest ping message that I can send is 71 bytes! I tried setting link-mtu and tun-mtu both lower and higher but I just don't see any changes.

How can I fix this situation?

PS: I tried using the oconf BB tag but it is ignored ... so I'm using the normal code tag.

[TinCanTech]

I am using OpenVPN 2.4.8 on Win 10 to connect to a Sophos SSL-VPN endpoint (runs OpenVPN under the hood and I don't want to use the Sophos client since I am using OpenVPN anyway).

Try using the right software.

[nobaq]

Try using the right software.

??

I am not sure if you are sarcastic or not but in any case, that response is pretty useless.


Nevertheless, if anybody else stumbles across this problem: Issue seems to be that Sophos uses the old 2.3.8 server and there seems to be a bug with compression. In the end, I also found these in my log:

Code: Select all

Bad compression stub decompression header byte: 102

Ironically I stumbled on this earlier and tried to fix it with different "compress" and "comp-lzo" parameters but missed that my client config already included "comp-lzo no" in the end.

Changing to "comp-lzo yes" removed this error message and with it the MTU issues.

[TinCanTech]

I don't want to use the Sophos client

Had you used their client with their server it would probably have worked.

If not then you could have asked Sophos why ..