VPN does not work with MTU of 1400

[Ryan Novosielski]

After installing 18.04, I started to have VPN problems that were very erratic. Some things worked, some did not (including parts of out JIRA install's website work but not others). I traced this to MTU. The problem goes away if I set my MTU on the VPN interface to 1358. However, when I connect with openconnect -vvv, I see that the server side sets 1400. Additionally, 1400 works fine on the Mac version of Pulse Secure. I can't figure out what is going on or what could be different. This worked fine in 17.10.

I am running 18.04 with all of the updates as of this week.

[Dan Lenski (lenski)]

Are you sure this is actually a regression from 17.10 -> 18.04?

It sounds more like the behavior of the *server* changed. Can you install the 17.10 version of the openconnect and libopenconnect5 packages and see if it actually makes any difference in the functionality?

[Ryan Novosielski (novosirj)]

I'm not absolutely certain, but I'm fairly sure. The behavior changed when I installed 18.04, which was relatively recently compared to its release date. For a couple of months, I'd try to use it for a few months, remember it was wonky, and need to get work done before the end of the train trip. Finally was on a longer one the other day where I went hunting for the solution.

I can't be sure what the MTU was set to back when it was working/on 17.10 (I suppose I'll find out by installing that version), but the fact remains that the MTU that /does/ work with the MacOS version does not work with OpenConnect on 18.04. I'm not sure what could be different between the two.

Anyway, will followup. If there's any useful output to provide, let me know.

[Dan Lenski (lenski)]

Thanks, that's interesting. There were almost no changes to the Juniper code between v7.06 and v7.08, and none that affected MTU handling (git diff v7.06 v7.08 -- oncp.c auth-juniper.c)

What version are you running on MacOS?

MTU detection is a perenially-unreliable issue with VPNs. I'm going to mention this issue upstream at http://gitlab.com/openconnect/openconnect

[Ryan Novosielski (novosirj)]

I don't use OpenConnect on MacOS -- I'm using the real Pulse Secure software version 5.2.5 (869).

Before 18.04, it seemed that they worked identically well.

One thing I did not consider, but will be able to test for: all of these problem scenarios occurred connected to an iPhone via wireless in hotspot mode on iOS 12.1.x. I should compare this to my home setup (Optimum Online) to make sure it wasn't something in the iOS hotspot or on VZW that changed.

[Ryan Novosielski (novosirj)]

Note that this does not appear to be a detected MTU, but a server-provided MTU (if there is indeed a difference).

[Dan Lenski (lenski)]

Ah, that's useful to know.

The Juniper NC protocol (what OpenConnect implements) has a mechanism for the server to tell the client what MTU to use, but no mechanism AFAIK for the client to tell the server what MTU it thinks it has at the IP level — unlike AnyConnect which has both.

This makes the Juniper protocol pretty bad for negotiating a usable MTU. (GlobalProtect protocol is even worse, though.)

```
$ openconnect --prot=nc -vvvv juniper.company.com
...
Received MTU 1400 from server
```

[Ryan Novosielski (novosirj)]

It's not doing it right now on either 17.10 or 18.04, on either Optimum Online or VZW via hotspot. :-|

[Ryan Novosielski (novosirj)]

...until I said that. Now it's doing it again on 18.04 on VZW. I'll try to see under what circumstances it does and does not happen.

[Dan Lenski (lenski)]

You can still work around it by setting a lower MTU manually though, right? (openconnect --mtu=X)