VPN does not work with MTU of 1400

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?

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.

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

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.

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

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
```

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

...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.

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