Convert OpenVPN to WireGuard

If you are trying to convert OpenVPN to WireGuard by feeding an .ovpn file into something that emits a wg0.conf, stop looking. No such converter exists, and none can, because the two protocols do not hold the same kind of secret. Wiretastix, one of the few pages that says so plainly, puts it as "there is no automatic converter from .ovpn client configs to WireGuard peers."

That is the honest answer, and it is the first paragraph rather than the last because every other page dances around it. The useful part follows: several things about your setup do carry across, and knowing which ones turns a migration from guesswork into a checklist.

The phrase covers four different questions, and only one of them is impossible.

• Turn an existing .ovpn file into a WireGuard config with a tool. This is the impossible one, and it is what most people are asking.
• Move from a provider's OpenVPN service to that same provider's WireGuard service, keeping the same account.
• Migrate a self-hosted OpenVPN server to a self-hosted WireGuard server without losing the routing you already built.
• Run both at once, so that one protocol covers the networks where the other fails.

The second, third and fourth are all achievable. The rest of this page treats the first as settled and answers the other three.

An .ovpn profile authenticates with X.509. It carries a CA certificate, a client certificate signed by that CA, a matching private key, and usually a tls-crypt or tls-auth key wrapping the control channel. WireGuard has no certificate authority, no certificate and no TLS control channel at all. It authenticates each peer with a static Curve25519 keypair exchanged out of band. Nothing inside the certificate can be transformed into that keypair. The private half is generated locally on the device and never appears in an OpenVPN file in any form.

The WireGuard protocol documentation is short and specific about this. It uses "Curve25519 for ECDH", ChaCha20 authenticated with Poly1305, and BLAKE2s for hashing, inside a Noise_IK handshake. There is no negotiation step, so there is no cipher list to translate. There is no identity document, so there is nothing to re-sign. Two protocols with no shared primitive and no shared trust model have nothing to convert between.

Consider what a hypothetical converter could actually read. It could read the hostname, the port, the routing directives and the DNS directive, all of which are configuration rather than secrets. It could not read anything that would let a server recognise you, because the server has to be told your new public key before the tunnel can come up. A tool that emitted a valid wg0.conf from an .ovpn file would be emitting a config for a peer no server has ever heard of. That is a text transformation, not a migration, and it would fail on the first handshake.

For a fuller treatment of the design difference and what it costs each side, read how WireGuard and OpenVPN differ.

Intent carries over. Material does not. Read the table as a migration checklist rather than as a mapping a script could apply.

The last row is the one people get wrong. A firewall rule set that permits outbound traffic only on tun0 will silently block everything the moment you bring up wg0 instead. That is a kill switch working correctly against the wrong interface name, and it presents as a total loss of connectivity rather than as an error.

For the two fields that decide most of the behaviour, see AllowedIPs and MTU.

Everything cryptographic, and one thing structural.

The inline <ca>, <cert>, <key> and <tls-crypt> blocks have no destination. WireGuard's [Interface] section holds one PrivateKey, and the [Peer] section holds one PublicKey and an optional PresharedKey. Four blocks of PEM do not reduce to two base64 keys. If you want to understand what those blocks actually hold before discarding them, see what is inside an .ovpn file.

Cipher negotiation does not carry over, because there is nothing to negotiate. OpenVPN agrees a data channel cipher per session from data-ciphers. WireGuard's primitives are fixed at the protocol level, and a version change rather than a configuration change is what alters them.

Username and password authentication does not carry over. auth-user-pass, auth-nocache and every credential prompt they imply have no WireGuard equivalent. A peer is authorised because its public key is on the server's list, and for nothing else. That removes a whole class of failure and removes a whole class of control at the same time.

TCP transport does not carry over. The WireGuard protocol documentation states that "all packets are sent over UDP", with no TCP mode and no fallback. This is the single most consequential difference for anyone who travels, and it is why the section below exists.

With a provider that ships both protocols, the migration is a download rather than a conversion. PulseVPN ships WireGuard and OpenVPN config files and has no proprietary app, so both are files you fetch and import into the standard client.

Two details decide how you plan a move on that account. Both protocols run on the same account at the same time, so this is an addition rather than a switch. The counts differ by protocol: OpenVPN profiles are unlimited, and WireGuard configs are capped at three. Generate the WireGuard config you need, keep the .ovpn profiles you already hold, and treat the three as the budget you plan devices around.

Request or download the WireGuard config from the provider. Do not attempt to build one from the .ovpn.

Import it into the WireGuard client for your platform, or place it at /etc/wireguard/wg0.conf and bring it up with wg-quick up wg0. The procedure is in importing a WireGuard config.

Check AllowedIPs against what you actually want. 0.0.0.0/0, ::/0 sends everything through the tunnel and is the equivalent of redirect-gateway def1. A narrower list is split tunnelling, and anything not listed will not route through wg0 at all.

Re-point your firewall rules at wg0. Every rule that named tun0 needs updating before you test, not after, because a half-migrated rule set fails closed and looks like a broken tunnel.

Keep the .ovpn profile. Do not delete it once WireGuard connects, for the reason in the next section.

For self-hosted migrations the shape is the same at a larger scale. Stand up WireGuard alongside the running OpenVPN server rather than in place of it. Onboard clients onto the new interface one at a time. Retire the old server only once the last peer has moved. Pro Custodibus documents routing between the two networks while both are live. It also notes that the OpenVPN side must use dev tun rather than dev tap, since WireGuard has no bridged equivalent.

Checking the move worked

A WireGuard tunnel that comes up is not the same as a WireGuard tunnel that carries what you expect. Check four things before you trust it.

• Run wg show and confirm the peer has a recent handshake and moving transfer counters, since a peer at zero has never completed the exchange.
• Check your public IP from the client and confirm it is the server, because a narrow AllowedIPs list can bring the tunnel up while leaving default routing untouched.
• Check DNS separately from routing, since a missing DNS = line leaves lookups going to your previous resolver while traffic routes correctly.
• Drop the tunnel deliberately and confirm your firewall rules block traffic against wg0 rather than against the interface name you retired.

The third of those is the one that most often survives a migration unnoticed. OpenVPN pushes DNS from the server, and WireGuard pushes nothing at all. A resolver that arrived automatically on the old setup has to be written into the config file on the new one.

WireGuard is not strictly better, and the cases where it loses are predictable.

Networks that block UDP defeat it completely. Hotel, airport, campus and corporate guest networks frequently allow only TCP on 80 and 443, and a UDP-only protocol has nowhere to go. OpenVPN over TCP 443 looks enough like ordinary traffic to pass, which is the entire reason to keep a working .ovpn profile after you migrate.

Some clients only speak OpenVPN. Older router firmware, some NAS packages and a few managed environments ship an OpenVPN client and nothing else. A protocol your device cannot run is not an upgrade.

Bridged setups have no WireGuard equivalent. If your OpenVPN deployment genuinely relies on dev tap and layer 2 adjacency, there is no configuration that reproduces it.

Credential-based access control does not survive. If you need to revoke one user's access by disabling a password rather than by editing a peer list, OpenVPN's model does that and WireGuard's does not.

The short version, without restating a comparison that lives elsewhere.

• Use WireGuard as the default on any network that lets UDP out, because it reconnects faster and roams between networks more cleanly.
• Use OpenVPN over TCP 443 when UDP is blocked or when the tunnel establishes and immediately stops.
• Use OpenVPN when the device only supports it, which is still common on routers and NAS hardware.
• Keep both configs downloaded, because the decision is per network and you make it at the moment the first one fails.

That is a choice about circumstances, not about which protocol is better. The argument itself is set out in how WireGuard and OpenVPN differ.

To load the new config, see importing a WireGuard config. To keep the fallback working, see using an OpenVPN profile.