Post cover image

July 11, 2026

One of the Safest Ways to Access Tor: VPN-Before-Tor on Tails

I promised this one a while back, right after the Tor internals post. Said the next one would be about actually accessing Tor safely…

By SHADOW

12 min read

I promised this one a while back, right after the Tor internals post. Said the next one would be about actually accessing Tor safely: bypassing ISP blocks, locking down the setup properly. Took me longer than I wanted, but here we go.

If you haven't read that one yet and want the "how does Tor actually work under the hood" explanation first, check it out here. It'll make the rest of this post click a lot faster, since we're building directly on top of that.

Quick disclaimer before anything else: Tails officially says it doesn't support VPNs. Their own FAQ says it straight up, currently, Tails does not work with VPNs, full stop. And their devs have a real argument for why: strapping a VPN in front of Tor doesn't automatically make you more anonymous, and in some ways it just adds a party who didn't need to be in the picture.

I'm not here to argue with that. This post isn't "VPN-before-Tor makes you more anonymous than stock Tails." It's narrower than that: this is for when your ISP itself is the problem, when it's throttling Tor, flagging it, or just blocking it outright. That's a different threat than what Tails' warning is about, and for that specific threat, this setup genuinely works. I'll show you exactly how well, with a kill switch test at the end that proves it.

Wait, why would my ISP even care that I'm using Tor?

A few real reasons this actually happens:

  • Some ISPs (and some countries, some workplaces, some campus networks) actively block connections to known Tor entry relays. The list of Tor guard IPs is public, so this is trivial for them to do.
  • Even where it's not blocked outright, some networks throttle it. Tor gets noticeably slower not because Tor itself is slow, but because your traffic's getting deprioritized once it's flagged.
  • And even if nothing gets blocked, plenty of people just don't want their ISP's logs showing "connected to Tor" at all, because depending on where you live, that alone can put you on a list you didn't ask to be on.

None of these are about the content of what you're doing on Tor. They're about the fact that you're touching Tor at all. That's the exact thing this setup solves.

The plan, in one line

Real IP → VPN tunnel → Tor → Internet.

Your ISP only ever sees you talking to a VPN server. Nothing about Tor shows up in their logs, because from their point of view, there's no Tor traffic to see. It's already wrapped inside the VPN tunnel before it ever leaves your machine's outbound rules for Tor. The VPN provider sees you connecting to a Tor entry node, but not what's inside. Tor's own encryption is already wrapping everything by the time it hits the tunnel.

Alright, let's build it.

Step 0: Get Tails booted and set up

If you've never touched Tails before, quick version. Grab the image from tails.net, and flash it to a USB using something like Rufus (Windows) or Balena Etcher (any OS). Balena's dead simple: pick the Tails image, pick your USB, hit flash.

None

If your host machine is Windows, disable BitLocker and Secure Boot before you restart, or the USB straight up won't boot. Plug the USB in, restart, and mash whatever key your machine uses for the boot menu (F12 on most Dells, varies by manufacturer). Pick the USB, and Tails should load.

First thing on the welcome screen: set an administrator password. This matters a lot here, without it, you can't run any of the sudo commands this whole setup depends on.

Step 1: Turn on Persistent Storage

Here's the thing about Tails by default: it forgets everything. Unplug it or restart, and it's a totally clean slate again. Normally that's the whole point (nothing left behind), but for this setup we need a few things to actually survive a restart: the OpenVPN package, your .ovpn config files, your VPN login, and the firewall edit we're about to make.

Go to Applications → Tails → Configure Persistent Storage, and turn on at least:

  • APT Packages (so OpenVPN survives a reboot instead of needing a reinstall every time)
  • Personal Data (for your .ovpn files and any notes)
  • Dotfiles, if you want configs to carry over too
None

One thing worth knowing: only what's actually inside Persistent Storage survives. Everything else on the system, including your firewall edit later unless you're careful about where things live, resets on every reboot. More on that pain point near the end.

The normal way: just using Tor, no VPN at all

Before we go anywhere near the ISP-bypass stuff, worth pointing out: for most people, this is genuinely all you need. Boot the USB, connect to your network, and Tails auto-connects to Tor on its own. That's it. No config, no terminal, nothing to break. Every bit of traffic on the system already routes through Tor by default, that's the entire premise of Tails as an OS.

If you're just after "don't let random sites and trackers know who I am," stop right here. This is the whole thing. Close Tails when you're done, and everything resets to a clean slate on next boot anyway.

The catch, and the only reason the rest of this post exists, is that this default setup makes no attempt to hide the fact that you're using Tor from whoever's watching your network. Your ISP can see the connection go out to a known Tor entry relay, plain as day, even though they can't see what you're doing once you're in. For most people that's a non-issue. For some, it's exactly the problem.

So who actually needs to go further than this?

If any of this sounds like you, the VPN layer below is worth the extra setup:

  • Your ISP or network actively blocks or throttles connections to Tor relays
  • You're on a connection where "this device is talking to Tor" showing up in a log is itself a risk, regardless of what you're doing on it
  • You just don't want that fact sitting in anyone's logs, full stop

If none of that applies, seriously, just use Tails normally and skip everything below. But if it does, here's the setup that actually solves it.

Step 2: Install OpenVPN

Open a terminal:

sudo apt update
sudo apt install openvpn -y

It'll probably ask if you want this to reinstall automatically on every future boot, say yes. That's exactly what Persistent Storage's APT Packages toggle is for; without it, you'd be doing this install every single session.

Step 3: Get a Proton account (without handing over your identity)

Do this bit inside Tor Browser, you're anonymous already at this point since you haven't touched the VPN yet, so it's the safest moment to sign up.

Head to account.proton.me/mail/signup?plan=free and create a free account. It won't ask for any personal info, you can just create the account by entering a new email address and a password. That account doubles as your Proton VPN login too.

None

Step 4: Find the VPN dashboard and grab the OpenVPN config (TCP, not UDP)

Here's a small gotcha: signing up through that link drops you into your Proton Mail inbox, not the VPN dashboard. You need to switch over to the VPN side yourself, either through the app switcher in the top corner, or by opening the VPN dashboard directly in a new tab.

Once you're on the VPN side, head to the OpenVPN config section, and download a config file. Any of the free servers listed will work fine for this.

Pick TCP, not UDP. UDP is way easier for a hostile network to fingerprint and block outright, a lot of ISPs and firewalls just drop unrecognized UDP streams. TCP on port 443 blends in as regular HTTPS traffic, which is exactly the kind of thing that gets through networks that are actively trying to block Tor or VPN traffic. Since the entire point of this setup is getting past a hostile network, UDP kind of defeats the purpose.

None

Grab your OpenVPN username and password from the credentials page too, and save both the config file and the credentials into Persistent Storage, you'll need them every time you connect.

None

One security note now that you're past the signup step: if you had to bump Tor Browser's Security Level down to Standard to get any of these pages working, set it back to Safest once you've got everything downloaded. That's the setting that disables JavaScript. Tor Browser ships with JS enabled by default for compatibility, but JS is one of the bigger fingerprinting and exploit surfaces in a browser. For anything actually sensitive from here on, running with JS off (via the shield icon next to the URL bar → Settings → Safest) is worth the occasional broken-website tradeoff. Only flip it back to Standard temporarily, on trusted sites, when you genuinely need to.

Step 5: Read the .ovpn file to grab the server details

Open the config file in a text editor and look for a line like:

remote 146.70.xxx.xxx 443 tcp

That's your VPN server's IP, port, and protocol, you'll need all three for the next step.

None

Step 6: The firewall surgery

This is the part that actually makes the whole thing work, not just "route traffic through the VPN," but force Tor to only ever talk over the VPN tunnel and refuse to work otherwise. That's the difference between "usually goes through the VPN" and "physically cannot leak," and it comes down to two small edits in Tails' firewall config (ferm.conf).

Tails locks down outbound traffic tight by default, nothing gets out unless there's an explicit rule allowing it. We're adding two rules. I've marked both with a comment so you can spot exactly what you added if you ever reopen the file:

Edit 1: let OpenVPN itself reach the VPN server

sudo nano /etc/ferm/ferm.conf

Add this near the top of the OUTPUT chain, using the IP/port/protocol you pulled from your .ovpn file:

#Local resources
daddr 146.70.xxx.xxx proto tcp dport 443 { mod owner uid-owner root ACCEPT; }
None

What this actually does: OpenVPN runs as root, and by default, root has no special permission to reach anywhere Tails hasn't explicitly allowed. This line carves out one narrow exception, root can talk to this exact IP, on this exact port, over TCP, and nothing else. That's the only door that lets your VPN connection get established in the first place.

Edit 2: force Tor to only use the VPN tunnel

Further down, there's already a block that looks like this:

#Tor is allowed to do anything it wants to
outerface tun0 mod owner uid-owner debian-tor {
    proto tcp syn mod state state (NEW) ACCEPT;
    proto udp dport domain ACCEPT;
}
None

Here's the important part, and it's the whole reason this setup is actually a kill switch and not just a preference: this is the only rule in the entire firewall that lets the debian-tor user send anything out at all. tun0 is the interface OpenVPN creates once it connects, it doesn't exist before that. So before the VPN is up, there's no tun0 for this rule to match, no rule allows Tor's traffic out, and Tails' default-deny policy just blocks it. Tor can't send a single packet until the tunnel exists.

That's not a routing preference that Tor could technically ignore, it's the firewall physically refusing to let Tor out any other way.

To save and exit: Ctrl+O, Enter, then Ctrl+X.

Step 7: Restart the firewall and bring up the VPN

Check the syntax before you trust it, a typo here can silently fail instead of erroring loudly:

sudo ferm -n /etc/ferm/ferm.conf

If that's clean, restart:

sudo /etc/init.d/ferm restart
None

Now connect to the VPN:

sudo openvpn yourconfig.ovpn

It'll ask for the username and password you saved earlier. Once you see "Initialization Sequence Completed," you're tunneled. Keep this terminal tab open and running, closing it kills the VPN connection.

None

Open a second terminal tab and check:

ip addr

Look for tun0 in the list with an IP assigned to it. That confirms the tunnel's actually up.

Step 8: Bring Tor back online

Still in that second tab (leave the VPN tab running in the background), bring Tor up:

sudo systemctl restart tor

If that doesn't work on your version, run systemctl status tor first to see the actual service name Tails is using, then restart that instead.

Give it a minute to bootstrap, then check:

👉 check.torproject.org

None

If it says you're using Tor, you're in. Your ISP, at this exact moment, sees nothing but a VPN connection. No Tor handshake, no known relay IPs in their logs, nothing to flag.

So what does the actual path look like at this point? Roughly like this:

Tor Browser
    |  (wrapped in Tor's own onion encryption)
    v
Tor daemon (debian-tor)
    |  (that already-encrypted traffic gets wrapped AGAIN, this time in the VPN's own encryption)
    v
tun0 (the VPN tunnel)
    |
    v
VPN server (Proton exit)
    |  (VPN encryption peels off here, Tor's onion layers are still intact underneath)
    v
Tor entry guard → Tor middle relay → Tor exit relay
    |
    v
The website you're actually visiting

The segment between your browser and the VPN server is the double-protected part, your ISP sees only VPN-encrypted traffic there, with Tor's own encryption still sitting underneath it. In practice, that means your ISP only ever sees you connecting to the VPN server, it has no visibility into the Tor entry node at all, since that hop only happens after the VPN server, well outside your ISP's view. Past the VPN server, it's normal Tor from that point onward, peeled one hop at a time exactly like it always is.

The actual proof: killing the VPN mid-session

This is the part that actually convinces you it's not just routing traffic through the VPN as a preference, it's enforced. With Tor already working through the tunnel, go back to the terminal running OpenVPN and hit Ctrl+C to kill it.

Now go back to Tor Browser and try to reload anything.

None

Nothing loads. Nothing will load. Because remember Edit 2, Tor's only allowed path out was through tun0, and tun0 doesn't exist anymore. The firewall isn't confused or half-working, it's doing exactly what we told it to: if the VPN's down, Tor doesn't get a fallback path onto the raw connection, it just goes silent. That's the kill switch, and that screenshot is the proof.

Reconnect the VPN, and Tor picks back up right where it left off.

What this actually buys you (and what it doesn't)

Let's be straight about the trade-off, because it's easy to oversell this:

  • Your ISP sees zero evidence of Tor. Not "Tor but encrypted," actually nothing, just a plain VPN connection. That's the entire value proposition here.
  • The VPN provider knows your real IP and that you're connecting to a Tor entry node, but they never see your actual traffic, since Tor's own encryption already wraps everything before it reaches them. What they know is timing and the fact you're a Tor user, not content.
  • Tor's own guard rotation is completely untouched by any of this. Tor still picks its 2 to 3 guards from the full relay pool on its own schedule, the VPN sitting in front doesn't interact with that mechanism at all.
  • So the real question is: which party would you rather hold the "this IP uses Tor" fact? Your ISP, who often has legal reach and retention obligations over you specifically? Or a VPN provider with no jurisdiction-based leverage over you at all? For most people dealing with a Tor-hostile network, that's an easy call.

This is why the Tails team's caution and this setup aren't actually in conflict, they're answering different questions. Their FAQ is about general anonymity theory ("more hops isn't automatically better"). This post is about a specific, narrower problem: getting past a network that's actively hostile to Tor in the first place. If your threat model is "I need my ISP to not know I even touch Tor," this setup earns its complexity.

Troubleshooting grab bag

A few things that tripped me up, if you hit them too:

  • Proton signup being weird about verification: try flipping Tor Browser's Security Level to Standard temporarily on Proton's page specifically if it won't load, or use their .onion mirror if you're on a network that's actively hostile to clearnet Tor exit traffic.
  • Ferm restart looking successful but rules not applying: always double check with sudo iptables -L -n -v | grep -i tor after restarting, to confirm your added lines actually loaded into the kernel and it wasn't a silent no-op from a typo.
  • The ferm edit disappearing after a reboot: yeah, this one's annoying. Unless the /etc/ferm/ferm.conf file itself is somewhere covered by your Persistent Storage config, you'll need to redo this edit every fresh session. Worth turning into a saved script in Persistent Storage that you can just re-run instead of retyping.

That's the full setup, tested end to end, kill switch and all. If anything here's off or I got a step wrong on your version of Tails, drop a comment and I'll get it corrected.

Next one's already brewing, stay tuned.

Happy Reading.