How to Set Up a VPN on Fedora

Fedora is a good desktop for people who like current software, and it ships with a sensible network stack out of the box. That same stack is the reason a VPN on Fedora behaves a little differently from advice written for other distributions. NetworkManager owns your connections, systemd-resolved handles DNS, firewalld sorts interfaces into zones, and SELinux watches what every program is allowed to touch. When a VPN fails on Fedora, one of those four is usually the cause, not the VPN itself.

This article is about vpn for fedora specifically: what to check first, how to add VPN support with dnf, where firewalld and SELinux get in the way, and what to look at after a release upgrade. It does not repeat the basics of what a VPN is. If you want the plain installer steps for the VPNclient desktop app, the Linux setup guide has them.

What is different about Fedora

Three defaults separate Fedora from many other distributions, and each one changes how a VPN behaves.

• systemd-resolved is the default resolver. Since Fedora 33, /etc/resolv.conf is a link to a stub file that points at 127.0.0.53. A VPN that "sets DNS" does so by telling systemd-resolved, per interface. Tools that write directly to /etc/resolv.conf are overruled or ignored.
• firewalld is on, with zones. Each network interface belongs to a zone such as FedoraWorkstation or public. A new VPN interface such as wg0 or tun0 may land in a zone that is stricter than you expect.
• SELinux is enforcing. Programs started by the system must follow labelled rules. A configuration file copied from your home folder into the wrong place can carry a label that blocks the VPN service from reading it.

None of this is a defect. It is the reason Fedora is a safer desktop by default. The cost is that copy-and-paste instructions written for a different distribution sometimes fail silently. Knowing which layer to look at turns a long evening into a ten-minute fix.

Check your Fedora edition and network stack first

Before installing anything, confirm what you are running. Open a terminal and use these read-only commands.

cat /etc/fedora-release
nmcli general status
resolvectl status | head -30
firewall-cmd --get-active-zones
getenforce

What the output tells you:

Command	Healthy answer	If different
nmcli general status	State "connected"	NetworkManager may be stopped; start it before adding VPN profiles
resolvectl status	Your Wi-Fi or Ethernet link listed with DNS servers	A server install may use plain resolv.conf instead
firewall-cmd --get-active-zones	Your interface listed in a zone	firewalld may be disabled; then look at nftables rules
getenforce	Enforcing	Permissive still logs denials, which helps debugging

Edition matters too. Workstation and the KDE Plasma spin use NetworkManager by default. Server installs may use NetworkManager too but often have no desktop applet, so you manage VPN profiles with nmcli. Silverblue, Kinoite and other atomic editions have an immutable base system, which changes how you add packages; that gets its own section below.

Option 1: the VPNclient desktop app

If you hold an XPASS pass, the simplest route is VPNclient, the free app. The Linux version is a graphical desktop app that you download as a .run file from the official link, mark executable and start from a terminal. You then sign in with the username and password shown on your My Pass page, not your XPASS website email. The full steps, with the official link, are in the Linux setup guide.

A few Fedora-specific notes for that route:

1. The store listings and our guide describe the Linux app as a desktop app for Ubuntu and other distributions. We cannot promise it behaves the same on every Fedora release, so install it at a time when you can troubleshoot, not minutes before a call.
2. The installer may ask for your sudo password. That is your local Fedora account password.
3. If the installer completes but the app cannot start its network helper, read the denial messages with sudo journalctl -b | grep -i denied and check the SELinux section below before reinstalling.
4. Keep the app's default connection settings unless support tells you otherwise.

If you want to compare plans first, see the download page for the supported platforms and the pricing page for pass lengths.

Option 2: VPN profiles through NetworkManager and dnf

Many people on Fedora already have a configuration file from somewhere else: an employer, a university, a router at home, or a server they run themselves. NetworkManager can hold those profiles so that connecting is a click in the system menu. The plugin for each VPN type is a separate package.

VPN type	Package to install	Notes
WireGuard	wireguard-tools	NetworkManager supports WireGuard natively; the tools add wg and wg-quick
OpenVPN	NetworkManager-openvpn and NetworkManager-openvpn-gnome	The second package adds the GNOME settings dialog
IPsec / IKEv2	NetworkManager-strongswan	Search with dnf search networkmanager as names can change
L2TP	NetworkManager-l2tp	Often paired with IPsec on older company gateways
OpenConnect	NetworkManager-openconnect	Used by some company gateways

Install the ones you need, then restart NetworkManager so the new plugin is detected.

sudo dnf install wireguard-tools NetworkManager-openvpn NetworkManager-openvpn-gnome
sudo systemctl restart NetworkManager

Then open Settings, Network, press the plus next to VPN, and choose Import from file to load an .ovpn or WireGuard .conf file. A KDE spin has the same flow in the network applet. If a plugin is missing, the type simply does not appear in the list. For a deeper look at how profiles are built, see the article on adding a VPN in NetworkManager once you are comfortable with the basics.

If you are choosing between WireGuard and OpenVPN for a profile you control, WireGuard vs OpenVPN lays out the trade-offs without favouring either.

firewalld and SELinux: the two Fedora-only problems

firewalld zones. A VPN interface that gets traffic but cannot reach the internet is often in a zone that drops forwarded or outgoing packets. Check where the interface landed.

firewall-cmd --get-zone-of-interface=wg0
sudo firewall-cmd --zone=trusted --add-interface=wg0

The second command is temporary and lasts until reload. If it fixes the problem, make it permanent with --permanent after you decide the interface really is trusted. For a client machine, the default zone is usually fine; you only need changes if you share the connection or run services over the tunnel. Never move your normal Wi-Fi interface into a trusted zone just to make a VPN work.

SELinux. If a connection fails with a message about permissions, look for a denial rather than guessing.

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --since "10 minutes ago"

A typical cause is a certificate or key copied into the wrong folder. NetworkManager's own import copies files to a location where the label is correct. If you place files by hand, restore the default labels with sudo restorecon -Rv /path/to/folder. Do not switch SELinux to disabled to make an error go away. Setting it to permissive for a single test (sudo setenforce 0, then sudo setenforce 1) is acceptable when you need to prove SELinux is the cause, as long as you turn it back on.

Silverblue, Kinoite and other immutable editions

On atomic editions the base system is read-only. Packages are layered with rpm-ostree, and the change applies after a reboot.

rpm-ostree install NetworkManager-openvpn-gnome
systemctl reboot

Flatpak applications cannot add system network plugins, so the plugin has to come from the layered package. After you reboot, import the profile in Settings as before. Layer only what you need: every layered package slows down upgrades slightly and is rebuilt on each new image. For a laptop that is rarely used for VPN, one plugin is a reasonable cost; five is not.

DNS on Fedora: avoid the quiet leak

Because systemd-resolved decides which DNS server answers, a VPN profile must register its DNS servers on the VPN link and make that link the default route for lookups. Check after connecting.

resolvectl status wg0
resolvectl query example.org

You want the VPN link to show DNS servers and a DefaultRoute of yes, or a search domain of ~.. If the VPN link has no DNS servers, lookups still go to your router, which defeats part of the point. Read what a DNS leak is and the article on split DNS if you only want company names to resolve through the tunnel. Fedora users who also run a local caching resolver or DNS over TLS should test one change at a time.

IPv6 deserves a second look. If your provider hands out IPv6 but the VPN profile carries only IPv4, traffic to IPv6 sites can leave outside the tunnel. In NetworkManager set the IPv6 method of the VPN profile to Ignore or Disable if the tunnel does not carry IPv6, or confirm that it does.

Release upgrades and what to re-check

Fedora releases come roughly twice a year, and many people upgrade in place with dnf system-upgrade. Profiles in /etc/NetworkManager/system-connections normally come through intact. After an upgrade, spend two minutes on this checklist:

1. Run nmcli connection show and make sure the VPN profile is still listed.
2. Run dnf list installed | grep -i networkmanager to confirm the plugin package is still present. A plugin removed during the upgrade makes the profile fail with a vague error.
3. Reconnect and check resolvectl status for the VPN link.
4. Open a speed or leak test only after the DNS check passes.
5. If the app was installed from a .run file, check that it still starts; a major library change can require a reinstall using the same official link.

Troubleshooting on Fedora, in order

1. Is the profile active? nmcli connection show --active.
2. Can you reach the VPN server by its address? ping may be blocked, but ip route get SERVER_ADDRESS shows which interface is used.
3. Is the clock correct? Certificate-based VPNs fail with a wrong date. timedatectl shows it.
4. Is DNS going through the tunnel? Use the resolvectl commands above.
5. Is the zone right? firewall-cmd --get-zone-of-interface=VPN_INTERFACE.
6. Any SELinux denial? sudo ausearch -m avc -ts recent.
7. Is a second VPN or a leftover route interfering? ip route should show one default route through the tunnel.
8. Still stuck? Read VPN not connecting for the general checklist.

Change one thing at a time and keep a note of what you changed. Most Fedora VPN problems vanish at step 4, 5 or 6.

Common mistakes

• Installing a plugin and forgetting to restart NetworkManager, then concluding the type is unsupported.
• Editing /etc/resolv.conf by hand on a system that uses systemd-resolved.
• Disabling SELinux or firewalld permanently instead of reading the one denial that matters.
• Placing certificates in a home folder and pointing the profile at them from a system service.
• Expecting a VPN profile to protect you while the VPN link has no DNS servers.
• Keeping an old profile that points at a server that no longer exists.

Summary

A VPN on Fedora works well once you respect its four defaults: NetworkManager for profiles, systemd-resolved for DNS, firewalld for zones and SELinux for labels. Install the right plugin with dnf, import or create the profile, confirm DNS and IPv6 behaviour, and read the one firewalld or SELinux message instead of disabling the protection. After each release upgrade, re-check the plugin and the DNS settings.

If you want a simple prepaid pass to use with the desktop app, the pricing page shows the options at your own pace.