VPN vs firewall: what each one doesn't cover

A firewall and a VPN solve different problems, even though buying guides keep lining them up as rivals. NIST defines a firewall plainly: a device or program that controls the flow of network traffic between networks or hosts with different security postures. Its separate definition of a VPN is something else entirely — a logical network built on top of a public one, using encryption and tunneling, not a set of rules about what gets in. One decides whether a connection happens; the other decides who can read it once it does. Windows Firewall ships active on every edition of Windows by default, per Microsoft’s own documentation — if you’re reading this on a laptop, a firewall is very likely already running. The more useful question is which failure mode each tool still leaves open, and the two friction points where running both at once trips people up. The tunnel side is covered in what a VPN is and how it works, and every provider in our full VPN rankings builds it the same basic way.

What does a firewall actually control?

Admission, not content. Microsoft’s documentation for Windows Firewall states the default posture exactly: block all incoming traffic unless it was solicited or matches a rule, and allow all outgoing traffic unless a rule says otherwise. Rules sort by source and destination address, port, protocol, and which application is asking; Windows also applies stricter rules automatically on a public network profile than a home one. macOS does the same job differently: Apple’s guide describes its firewall as application-based, blocking contact other computers initiate and prompting you the first time an unapproved app tries to accept a connection. A router firewall repeats the pattern at the network edge, refusing any inbound connection nobody inside asked for. None of these tools open a packet and read what’s inside it — a firewall’s job ends at the decision to let a connection start.

What does a VPN add on top of it?

A VPN starts after a firewall has already said yes. It has no opinion on whether a connection should be allowed — your device or a firewall rule settled that already. What it does is encrypt the traffic before it leaves the device and hand it to a server that swaps in its own IP address, so the site on the other end sees the server, not you. Turn on a VPN and the coffee-shop router’s firewall keeps doing exactly what it was doing before — checking connections at the edge — while the VPN handles what happens to the ones that get through.

What actually stops each threat?

Lay six real threats next to both tools and the pattern holds: each one has exactly one tool built for it, or neither does.

What a firewall and a VPN actually stop

Threat	Firewall	VPN
Your ISP logging which sites you visit	No — it never inspects what leaves the device, only whether the connection is allowed	Yes — encrypts the traffic, so the ISP sees a connection to a VPN server, not a destination
Someone on the same public Wi-Fi reading your traffic	No — a local firewall does nothing to data already sent onto the shared network	Yes — the tunnel encrypts everything before it reaches that network
An inbound port scan or unsolicited connection attempt	Yes — default-deny inbound rules exist exactly for this	No — a VPN doesn't filter what's trying to reach you, only what you send out
Malware already on your device calling out to a control server	Often — an outbound rule can block or flag traffic to an unrecognized destination, if one is set	No — the tunnel encrypts the malware's traffic as faithfully as anything else
A streaming or shopping site geo-blocking your country	No — location isn't a connection-admission problem	Yes — the site sees the VPN server's location instead of yours
A phishing page with a convincing fake login form	Rarely — a basic OS firewall doesn't inspect page content	No — encryption protects the delivery pipe, not what's inside it

Three of those six are strictly a VPN’s job. Two are strictly a firewall’s. The last one, phishing, is neither’s job at all — that is what a password manager and a moment of suspicion are for, not a network-layer tool.

Where a firewall and a VPN genuinely overlap

The one place the two actually merge is the kill switch. A VPN kill switch is not a separate invention — it is a firewall rule the VPN app installs on itself: allow traffic only through the tunnel’s virtual interface, block everything else, and lift the rule once the tunnel reconnects. On Windows that rule runs through the same engine Windows Firewall itself uses — Microsoft’s developer documentation for the Windows Filtering Platform describes “run-time filters” added by “firewall agents, or by custom firewall solutions,” and a VPN app is one of those solutions. Our guide to VPN kill switches covers what that protects against and where it falls short. It is also the honest answer to “do I need a firewall if I already use a VPN”: the app is already running a small, single-purpose firewall of its own, built for one failure mode and nothing else.

Why a firewall can block your VPN from connecting

A strict firewall does not only stop outside threats — it can stop your own VPN from connecting at all. Every protocol needs a specific port let through for its handshake, and a hotel, school, or office network that only opens standard web ports can quietly drop every one of them. The failure looks identical from inside the app: it says “connecting” and never finishes.

Default ports each VPN protocol needs open, and what to try when they're blocked

Protocol	Default port	Source	Fallback when it is blocked
WireGuard	UDP 51820	WireGuard's own quick-start	A provider-specific option — Mullvad, for one, can move WireGuard to UDP 53, 80, 123 or a custom port
OpenVPN	TCP and UDP 1194	IANA port registry	TCP 443, which looks like ordinary HTTPS to a filter
IKEv2/IPsec	UDP 500, then UDP 4500 behind NAT	RFC 7296	No standard port fallback — switch protocol instead

That is when protocol choice stops being about speed and starts being about which port survives — our WireGuard vs OpenVPN guide covers that trade-off in full. It also turns a provider’s protocol decisions into a real constraint. Mullvad removed OpenVPN entirely, client and server side, on 15 January 2026, so the TCP 443 escape hatch in the row above is simply gone there — WireGuard sends every packet over UDP. Mullvad’s answer is its own set of workarounds rather than a second protocol: its guidance for restrictive networks documents UDP-over-TCP on port 80, 443 or 5001, Shadowsocks, and a QUIC mode that makes the traffic resemble ordinary web browsing. Our Mullvad review covers what that all-WireGuard bet trades away.

Split tunneling causes a quieter version of the same fight. Send some apps through the tunnel and route the rest normally, and a firewall enforcing “everything goes through the VPN or nothing does” — a common rule on managed corporate networks — treats the untunneled half as a violation and blocks it, even though the VPN is working as configured. The fix is not a different VPN; it is turning split tunneling off on any network that expects one fully tunneled connection.

Where does a combined “VPN firewall” device fit in?

Router and firewall vendors also sell one box that runs both. pfSense, a widely used open-source platform, advertises itself in exactly those terms: “full firewall/VPN/router functionality all in one.” Take that literally — it is one piece of hardware running two separate programs, not one function absorbing the other. The firewall half still decides what is allowed in and out at the network edge; the VPN half still runs the encrypted tunnel, most often for remote workers connecting back into an office. Buying the combined box saves a second device and login. It does not merge admission control and encryption into a single decision — a misconfigured rule on either half leaves the same gap a separate firewall and VPN would.

Reach for the firewall when

• You want to stop unsolicited inbound connections and port scans on a laptop, router, or server.
• You are deciding which apps and devices are allowed to reach the internet at all.
• You run a business network and need to segment traffic between departments or block a known-bad destination outright.

Reach for the VPN when

• You are on a network you do not control — hotel, airport, café — and want the traffic itself unreadable to anyone else on it.
• You would rather your ISP see one encrypted stream than a list of every site you visit.
• You need to appear to be connecting from somewhere else, for access or for checking how a site behaves elsewhere.

Reach for both when

That is most people, most of the time. The firewall was already running before you thought about any of this, and it cost nothing — it shipped with the operating system. The VPN is the part you choose and pay for, and what that money buys is the one gap the firewall was never built to close: privacy from the network you are sitting on.

Frequently asked questions

What is the difference between a VPN and a firewall?

A firewall controls which connections are allowed to reach your device or network. A VPN encrypts the connections that are already allowed and hides where they're headed from anyone watching the network. One is a set of admission rules; the other is an encrypted tunnel.

Do I need a VPN if I already have a firewall?

Yes, if privacy from your ISP or from other people on your network matters to you. A firewall doesn't encrypt anything it lets through, so it does nothing to stop an ISP, or a stranger on public Wi-Fi, from seeing where your traffic is headed.

Do I need a firewall if I use a VPN?

Yes. A VPN doesn't filter inbound connection attempts and doesn't stop malware already on your device from calling out — that's still the firewall's job, and one is running by default on Windows and macOS whether or not a VPN is active.

Can a VPN replace a firewall?

No. A VPN has no concept of blocking an unsolicited inbound connection or an app you don't trust — it only wraps traffic you've already decided to send.

Can a firewall replace a VPN?

No. A firewall doesn't encrypt anything or hide your destination from your ISP or local network — it only decides whether a connection is allowed to start.

Will a VPN work through a firewall?

Usually, but not always. A firewall that only opens standard web ports can block the port a VPN protocol needs for its handshake — WireGuard's default UDP 51820 is an easy one to block, which is why OpenVPN's TCP 443 option exists as a workaround.

Does a VPN protect you from hackers?

Against one kind of exposure: someone reading your traffic in transit on a shared network. It does nothing about a phishing page, malware already on the device, or an attacker using a different route in — a firewall and updated software cover those instead.