Why OpenConnect Pages Hang Until You Lower the Tunnel MTU

Login succeeds, the portal front page paints, and then a dashboard widget or a report sits at waiting for host until the browser gives up. Public sites load normally the whole time, and no credential has changed. Small replies arriving while large ones stall is the signature of a packet-size ceiling rather than an access rule. Confirm that reading before you edit anything else in the profile.

Separate a size problem from a policy problem

Start by ruling out rejection. If the gateway refused you, the connection would fail at once instead of half-loading a page. A tunnel that comes up and then stalls only on bigger transfers is telling you the outer path cannot carry the inner packet.

The mechanism is encapsulation. Each inner packet gains tunnel headers, so a payload that fits the physical link becomes an outer packet that no longer fits, and anything carrying the do-not-fragment bit is dropped without a reply the browser can interpret.

Measure the ceiling with do-not-fragment probes

Measure the ceiling instead of guessing it. Send probes that refuse fragmentation and step the payload down until a reply comes back, starting from a command like ping -M do -s 1472 host. A response complaining that fragmentation is needed while DF is set means the value is still too high. Repeat at 1462, then 1452, and stop at the first size that returns. Record the number together with the host you probed, because the answer belongs to that path and not to the protocol in general.

Probe the address the tunnel actually sends traffic to. An outer probe against the gateway's public name and an inner probe against an internal server measure different hops, and ICMP filtering on either one can make a healthy path look broken.

Apply the value to the tunnel device

Apply the result to the interface the client created, not to the Wi-Fi adapter. On a Linux client that is ip link set dev tun0 mtu 1300 followed by ip link show tun0 to confirm the value took. Use whatever device name the client reports, since it varies with the implementation and with how the tunnel was built.

Lowering the tunnel MTU shrinks the payload each packet carries, so bulk throughput drops a little, and that is the price of not black-holing large responses. A smaller number is not automatically safer. Changing the physical adapter instead spreads the damage across every connection on that link while leaving oversized inner packets just as oversized.

Use the client's own MTU requests first

When you control the invocation, the client can ask for a size rather than being patched afterwards. --mtu requests a tunnel MTU from the server, and --base-mtu declares the underlying path MTU so the gateway can derive the tunnel figure. Both are requests, and the client's manual does not promise the gateway will honour either one.

That distinction sets your order of work. Try the request first and inspect the interface it produces, then fall back to setting the device locally if the value the gateway chose still stalls.

Verify with the transfer that failed, then persist it

A local ip link change lasts until the client rebuilds the tunnel, which happens on the next reconnect or resume. Put the value where the connection starts: a wrapper that runs the client and then adjusts the device, a systemd unit with an ExecStartPost step, or the client option when the gateway accepts it. Keep it beside the profile in version control so the next person can see why the number is there.

Test with the request that failed, not with the front page. Open the report, pull the attachment, or run the repository fetch that hung, and note exactly where it stops if it still does. A page that renders after the change proves little, because it rendered before as well.

If the same transfer stalls at the same point, the MTU theory is unproven. Capture traffic on the tunnel and check which side stops sending before you change the number again, and keep the previous value recorded so a rollback stays a single command.