OpenVPN Connect Rejects fragment: Fix the Profile Source

The error arrives at import, before any negotiation, and names a directive the client refuses to accept. OpenVPN Connect runs OpenVPN 3 library code, which does not implement the community client's fragment option at all. That makes this a compatibility question about two endpoints rather than a tuning question about packet size.

Deleting the line produces a file the client will parse, and a server that may still expect the format the line described. Walk it from the import screen outward before editing anything.

Where the Import Stops

The importer parses directives before it contacts the server, so a refusal there is a local decision about syntax rather than a network result, and OpenVPN's unsupported directive list records the same limitation. That explains how one file can work in the community client and fail in Connect on the same machine. Read the message for the directive name and keep the original file, because that text is the only evidence of what the client objected to. An import error and a connection timeout come from different stages and deserve different responses.

If the message names fragment, the remaining question is whether the server also depends on it. Answer that before touching the profile you were given.

What fragment Changes in the Community Client

In the community client, the directive enables OpenVPN's own datagram fragmentation, which splits payloads before they reach the outer IP layer. It exists to survive paths that drop large UDP datagrams and to keep a tunnel usable where path MTU discovery cannot be trusted. It is not a synonym for lowering the interface MTU, and it is not IP-level fragmentation performed by the operating system. A client lacking the mechanism cannot acquire it by lowering a number.

Because the setting lives in the server configuration as well, removing it from your copy changes your side only. The server may still expect a peer that understands the option, and a profile that parses is not yet a session that establishes. Those two facts explain the confusing middle state where an edited file connects and then stalls.

Ask for a Profile Built for This Client

The clean route is a second profile documented for OpenVPN Connect, if the service publishes one. Many providers do, and the difference is usually the directives they omit rather than the endpoint they point at. Ask for it by client name rather than describing the error, since a support desk can match a profile to a client far faster than it can diagnose a stripped file.

If you run the server, the decision is broader than your own client. Turning fragmentation off affects every peer, including ones that needed it to stay connected over a poor path. Publishing a second listener or a second configuration for the affected client keeps existing users working while the newer client gets something it can parse. Whichever way you go, write down which configuration serves which client, because that mapping disappears quickly otherwise.

Verify the Connection, Not Just the Import

A successful import proves only that the parser accepted the file. Establish the tunnel with the community client on a machine you control, using the same profile, and read the log for transport and cipher negotiation. The commands below do that without the desktop app in the way.

openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/

The log shows where the attempt stopped: an option error appears before any TLS exchange, while an authentication or cipher failure appears after it. If the tunnel comes up and the request still fails, the problem moved from compatibility to routing. Compare that against Connect's behaviour on the same network before concluding anything about the server.

Keep the working profile and the client version beside the note. A future client release can add support for a directive, and that changes the answer without anyone touching the server.