You've got an admin panel locked down to a single IP. Works beautifully from your home office. But what happens when you're on a train in Belgium, tethered to a 5G phone, trying to SSH into production? That moment of staring at a connection refused error — that's what we're digging into today.
Daniel wrote us a long one, and I'm going to read it nearly in full because the layers here matter. Quote: Let's say you want to use a static IP allowlist as the security mechanism guarding access to protected resources — an admin panel, a database, a cloud console, an API. If you're always sitting at home behind a fixed residential IP, that's easy. But what if you're working from multiple computers, in different countries, from hotel Wi-Fi, from a phone tether? How do you give all your trusted devices a single stable, fixed egress IP regardless of where in the world they're actually connecting from?
He goes on — walk through the practical options and the actual tools on the market. What are the categories? Cloud VPS running your own VPN or WireGuard box, commercial VPN providers that sell a dedicated static IP add-on, proxy and gateway services, cloud NAT gateways, corporate SASE and secure web gateway products, mesh VPN solutions with exit nodes. Which of those are realistic for an individual or a small team, and which are enterprise-priced?
Then the gotchas — single point of failure, latency penalties from hairpinning all traffic through one region, IP reputation problems, split tunnelling so only the traffic that needs the fixed IP goes through it, and what happens when the provider silently rotates the address you thought was static.
And then he pivots to the bigger question. Is IP allowlisting an outdated, device-level security model in twenty twenty-six? It authenticates a network location rather than a person or a device, and network location is a weak proxy for identity. Should we be using more sophisticated methods instead — mutual TLS with client certificates, hardware-backed device attestation, identity-aware proxies and zero-trust access, short-lived credentials, WebAuthn and passkeys, continuous authorisation? If IP allowlisting really is obsolete, what specifically should replace it, and how much operational complexity does that cost compared to just pasting an address into an allowlist field? And is there still a legitimate role for IP allowlisting as one layer in a defence-in-depth stack rather than as the whole gate? End quote.
So today we're going to answer that in two halves — first, the practical mechanics of getting a fixed egress IP from anywhere, and second, whether the whole premise of IP allowlisting even makes sense anymore.
I love this question because it exposes something most security discussions gloss over. IP allowlisting is the simplest access control that actually works — until you move six feet from your desk. The moment you're on a different network, the model collapses. And yet it's still everywhere. Every cloud console, every database dashboard, every internal tool — paste an IP, click save, done.
And the thing is, it works. That's the trap. It works so well in the one scenario it was designed for that people build entire workflows around it, and then they're genuinely surprised when it breaks on the road.
Right. So let's define the core problem before we get into solutions. An IP allowlist says: only traffic originating from this specific network address gets through. The address is the credential. The problem is that in twenty twenty-six, your network address changes constantly. You're on home Wi-Fi, then cellular, then a coffee shop, then a hotel. Each one has a different public IP. And if you're behind carrier-grade NAT — which is increasingly common, especially on mobile connections — you don't even have your own public IP at all. You're sharing one with hundreds of other people.
And that's the thing Daniel's really asking. Not just how to solve the technical problem, but whether the technical problem is even the right one to be solving. We'll get there. But first, let's walk the tool categories.
Six categories, from a five dollar a month VPS running WireGuard to enterprise SASE products that cost more than your rent. Let's start with the simplest one, because it's what I'd recommend for most people who just need this to work.
Category one, the DIY VPS.
Yeah. You spin up a virtual private server — DigitalOcean, Linode, AWS Lightsail, whatever. Five to ten dollars a month gets you a small instance with a static public IP. You install WireGuard, configure it as a VPN server, and connect all your devices as clients. All your outbound traffic now exits through that VPS's IP address. You put that IP in your allowlist, and you're done.
And the pros here are pretty clear. Full control — you're the sysadmin, nobody's logging your traffic unless you set up logging, and the IP is truly static as long as you don't destroy the instance. It won't silently rotate on you because there's no provider making decisions behind your back.
The cons are equally clear. Single point of failure — if that VPS goes down, you lose access to everything behind the allowlist. You're also the sysadmin, which means you're the one who has to notice when the VPS goes down and fix it. And there's a latency penalty. If your VPS is in New York and you're in Singapore, every packet is hairpinning through New York. That's easily a hundred to two hundred milliseconds added to every request.
And you'd better have a plan for what happens when you accidentally lock yourself out of the VPS itself.
Oh, that's the classic. You set up the firewall rules, you restart the VPS, and suddenly you can't SSH in because you forgot to allow your current IP. Now your static egress IP is sitting there, perfectly static, completely unreachable, and you can't get to anything.
So category one works, but it's fragile. Category two?
Commercial VPN providers with dedicated static IP add-ons. This is where Mullvad is the standout example. Mullvad's standard VPN is about five euros a month. They offer dedicated IP addresses as an add-on, and critically — and this is the thing Daniel's worried about — they explicitly state these IPs are only used by you and won't be rotated without notice. Most VPN providers do not make that promise. A lot of them will sell you a dedicated IP and then rotate it silently during maintenance, and suddenly your allowlist is pointing at nothing.
So Mullvad is the exception, not the rule.
And here's where it gets interesting. Tailscale has a direct integration with Mullvad exit nodes. It's documented in their knowledge base, article eleven eighteen. You can route traffic through a Mullvad node with a fixed IP from within your Tailscale mesh. So you don't even need to run your own VPN client separately — it's all inside the Tailscale network.
So you get the static IP from Mullvad, but you manage access through Tailscale's mesh. That's a useful combination.
And the pricing works out. Tailscale is free for up to three users, five dollars a month for the personal plan, business plan for teams. Mullvad's dedicated IP is an additional fee on top of the five euro base. So all in, you're looking at maybe ten to fifteen dollars a month for a setup where you don't manage any infrastructure yourself, you get a static IP that won't silently rotate, and you've got split tunnelling built in through Tailscale.
That's the sweet spot for an individual, I think. But let's keep going. Category three — proxy and gateway services.
This is the category people often stumble into by accident. Services like Bright Data, which used to be Luminati, Oxylabs, Smartproxy. These are residential proxy networks. They give you access to massive pools of IP addresses, often with geo-targeting, and some offer static IP options. They're primarily designed for web scraping — rotating IPs to avoid rate limits, accessing geo-blocked content, that kind of thing.
And the problem with using them for admin access?
Three problems. One, they're expensive. These are enterprise scraping tools, not VPN services. Two, using them for authentication purposes is often against their terms of service. They're not designed for it, and they'll shut you down if they detect it. Three, IP reputation. These IPs are shared across many customers, many of whom are doing things that get IPs flagged. You might find your static proxy IP is already on a blocklist before you even start using it.
So category three is a non-starter for what Daniel's asking about. These are scraping tools, not access control tools.
Agreed. Category four — cloud NAT gateways. AWS NAT Gateway, Google Cloud NAT, Azure NAT Gateway. These provide a static egress IP for resources inside a virtual private cloud. But they're designed for cloud workloads — you've got a fleet of EC2 instances that need to reach external APIs, and you want them all to appear from a single IP. They're not designed for individual devices on the move.
So you'd need to route all your traffic through a cloud VPN back to your VPC first, and then out through the NAT gateway. That's two hops.
Two hops and a lot of cost. AWS NAT Gateway pricing is roughly thirty-two dollars a month plus data transfer. Compare that to a five dollar VPS running WireGuard. The NAT gateway is more reliable — it's a managed service, AWS handles the availability — but for an individual or small team, the cost-to-benefit ratio just doesn't work.
Unless you're already running everything in that cloud and you've got existing VPC infrastructure. Then it might make sense as a bolt-on. But Daniel's asking about practical options, and for most people, thirty-two dollars a month for a NAT gateway is overkill.
Category five — corporate SASE and secure web gateway products. Cloudflare Zero Trust, Zscaler, Netskope, Palo Alto Prisma Access. These are the enterprise-grade solutions. They provide identity-aware proxying, not just IP-based access. You authenticate with your identity provider, the traffic gets routed through their network, and the destination sees the proxy's IP, not yours.
And the pricing?
Cloudflare Zero Trust is the interesting one here — it has a free tier for up to fifty users. That's usable for a small team. The advanced features cost money, but the basic identity-aware proxy is free. Zscaler is famously opaque about pricing, but expect five to fifteen dollars per user per month at minimum. Netskope and Prisma Access are in the same range or higher.
So Cloudflare Zero Trust is actually in the conversation for a small team, but Zscaler and the others are firmly enterprise territory.
Right. And the thing about these products is they're not really solving the static egress IP problem — they're solving the access control problem in a completely different way. They're saying: don't bother with IP allowlists at all. Authenticate the user and the device, and proxy the traffic. The IP becomes irrelevant. We'll come back to that in the second half.
Category six — mesh VPN solutions with exit nodes. You already mentioned Tailscale.
Tailscale is the standout. The idea is you designate any node in your mesh as an exit node. All traffic from other devices can be routed through that node's IP. So if you've got a home server sitting on a residential connection with a static IP, or a VPS in a data center, you make that the exit node and everything routes through it. Combined with the Mullvad integration we talked about, you can have a fixed IP exit node without even running your own VPS.
And the gotcha?
The exit node becomes a single point of failure and a bandwidth bottleneck. If it goes down, everyone loses access. And all traffic is flowing through that one node, so if you're on a gigabit connection and your exit node is on a hundred megabit link, you feel it.
So we've covered the six categories. But before anyone goes spinning up a VPS, let's talk about the gotchas that'll bite you.
Five gotchas, and they're all important. First, the single point of failure we keep mentioning. If your exit node or VPS goes down, you lose access to everything behind the allowlist. Everything. No admin panel, no database, no cloud console. You need a backup access method — maybe a second exit node in a different region, or an emergency break-glass procedure that doesn't depend on the allowlist.
And you need to test that backup method before you need it.
Yes. Test it quarterly. Nothing worse than discovering your emergency access procedure doesn't work during an actual emergency.
Gotcha two — latency.
Hairpinning all your traffic through a single region adds latency. If your exit node is in Virginia and you're in Tokyo, you're looking at a hundred and fifty to two hundred milliseconds added to every round trip. For SSH and admin panels, that's annoying but workable. For anything that requires real-time interaction, it's painful. And you can mitigate it by having exit nodes in multiple regions, but that adds complexity and cost.
Gotcha three — IP reputation.
This is the one people don't think about until it bites them. If you're using a cloud provider's IP range, some services will block you simply because you're coming from a known data center IP. A lot of streaming services do this, but so do some corporate services and APIs. They see the IP is from DigitalOcean or AWS, and they assume it's a bot or a scraper. Residential IPs have better reputation, but they're harder to get as static addresses.
If you're using a shared proxy IP, the reputation could be terrible before you even start.
Right. The previous user of that IP might have been scraping, spamming, or worse. You inherit their reputation.
Gotcha four — split tunnelling.
You don't want all your traffic going through the exit node. Just the traffic that needs the fixed IP. WireGuard and Tailscale both support split tunnelling, but it requires careful configuration. You need to specify exactly which IP ranges or domains should be routed through the tunnel and which should go directly. Get it wrong, and either your Netflix traffic is hairpinning through Singapore for no reason, or your admin panel traffic is bypassing the tunnel entirely.
Split tunnelling isn't automatic. You have to set it up explicitly.
Tailscale makes it relatively easy with their exit node selector — you can toggle it on and off per device. But you still need to think about which traffic goes where. WireGuard is more manual — you're editing config files and specifying allowed IPs.
Gotcha five — silent IP rotation.
This is the one Daniel specifically flagged, and he's right to worry about it. A lot of providers, especially cheaper VPNs, will sell you a dedicated IP and then rotate it without notice during maintenance or infrastructure changes. Your allowlist is pointing at an IP that no longer routes to you, and you don't know why. Mullvad explicitly says they don't do this for dedicated IPs. But if you're using any other provider, you need to verify their policy. And even with Mullvad, you should monitor it — set up a simple cron job that checks your egress IP and alerts you if it changes.
Those are the mechanics. Now let's zoom out and ask the uncomfortable question Daniel raised. Is this whole approach a mistake?
This is where it gets interesting. IP allowlisting authenticates a network location, not a person or a device. Network location is a weak proxy for identity. It's a single-factor, static credential that never rotates. If an attacker can get onto a network with an allowed IP — and there are many ways to do that, from compromising a cloud instance to piggybacking on a legitimate network — they're in.
The thing is, we've known this for years. The entire zero-trust movement is built on the premise that network location is not identity. Google published their BeyondCorp papers nearly a decade ago. And yet here we are, still pasting IPs into allowlist fields.
Because it's easy. That's the entire reason. Pasting an IP takes ten seconds. Setting up mutual TLS or an identity-aware proxy takes hours or days. For a lot of people, the threat model doesn't justify the complexity. If you're running a personal blog's admin panel, IP allowlisting is probably fine. If you're running a database with customer data, it's not.
What should replace it? Let's walk through the alternatives.
Six alternatives, and they're not mutually exclusive. First, mutual TLS with client certificates. This gives you strong device identity — the server authenticates the client's certificate, not its IP. The problem is PKI management. You need a certificate authority, you need to issue and revoke certificates, you need to handle expiry. For a team of three, that's a lot of overhead.
Second, hardware-backed device attestation.
TPMs, Apple's Secure Enclave, Android's Trusted Execution Environment. These let you prove that the device connecting is actually the device you think it is, and that it hasn't been tampered with. This is the strongest form of device identity we have, but it's also the hardest to implement. Most applications don't support it natively.
Third, identity-aware proxies.
This is where Cloudflare Access, Google BeyondCorp, and Tailscale's ACLs live. Instead of checking an IP, the proxy checks your identity. You authenticate through your identity provider — Google, GitHub, Okta, whatever — and the proxy decides whether you're allowed through based on who you are, not where you're connecting from. Cloudflare Zero Trust gives you this for free for up to fifty users. Tailscale's ACL system is even simpler — you define rules in a JSON file, and the mesh enforces them.
Fourth, short-lived credentials.
AWS STS, OAuth 2.0 device flow. Instead of a static IP that's valid forever, you issue credentials that expire after minutes or hours. Even if an attacker steals the credential, the window of abuse is tiny. This pairs well with identity-aware proxies — you authenticate, get a short-lived token, and use that token for access.
Fifth, WebAuthn and passkeys.
Phishing-resistant authentication. WebAuthn binds the credential to the origin, so even if someone tricks you into visiting a fake login page, the credential won't work. Passkeys take this further by syncing across devices through your platform's keychain. This is authentication, not access control, but it's a critical layer — if your authentication is strong, the access control can be simpler.
And sixth, continuous authorization.
BeyondCorp-style trust scoring. The system doesn't just check your identity at login — it continuously re-evaluates access based on device posture, location, behavior. If your device suddenly shows signs of compromise, access is revoked even if you're already authenticated. This is the most sophisticated model, and it's what the big tech companies use internally. It's also the hardest to implement for a small team.
There's a spectrum here. On one end, paste an IP and you're done. On the other end, continuous authorization with hardware attestation. The question is where on that spectrum the tradeoff makes sense.
The answer depends entirely on what you're protecting. Daniel asked for a decision framework, so here's one. If the resource behind the allowlist contains anything that would cause real harm if exposed — customer data, financial information, production infrastructure — IP allowlisting alone is insufficient. You need at least one additional layer. Client certificates, identity-aware proxy, WebAuthn, something.
If it's a low-risk internal tool? A staging environment, a dashboard that shows nothing sensitive?
The simplicity of IP allowlisting might be worth the risk. But I'd still argue for at least adding strong authentication. WebAuthn takes ten minutes to set up on most platforms. It's not a heavy lift.
There's also the defense-in-depth argument. IP allowlisting isn't useless — it's a useful layer when combined with other controls. Require both a valid client certificate and an IP on the allowlist. Or use IP allowlisting as a rate-limiting mechanism while relying on stronger auth for actual access. The mistake is using IP allowlisting as the sole gate.
Right. Think of it like a lock on your front door. It's not going to stop a determined attacker, but it stops casual opportunists. You still want an alarm system and insurance. IP allowlisting is the lock. Client certificates or identity-aware proxies are the alarm system.
The thing that bothers me about IP allowlisting, though, is that it creates a false sense of security. People set it up and think they're done. They don't realize how fragile it is, how many ways it can fail, how many attack vectors it doesn't address.
That's the real danger. Security theater that convinces you to stop thinking about security. If IP allowlisting makes you complacent, it's worse than useless.
What's the pragmatic middle ground? For someone listening who wants to improve their setup this week?
For individuals and small teams needing a static egress IP, the Tailscale plus Mullvad combo is the sweet spot. Easy setup, reasonable cost — five to ten dollars a month — split tunnelling built in, and Mullvad's explicit no-rotation policy for dedicated IPs. You get the fixed IP you need without managing infrastructure.
For teams that can afford a bit more complexity?
Move toward identity-aware access. Cloudflare Zero Trust is free for up to fifty users. Tailscale's ACL system is built into the product you're already using. Both provide much stronger security with minimal operational overhead compared to full PKI. You don't need to go all the way to hardware attestation and continuous authorization to get significant improvements.
The key insight is that you don't have to choose between IP allowlisting and zero trust. You can layer them. Use IP allowlisting as one control among several. Combine it with strong authentication — WebAuthn, TOTP, or client certificates. That gives you defense-in-depth without requiring a full zero-trust architecture.
That's the decision framework. Know your threat model. If the data behind the allowlist would cause real harm if exposed, IP allowlisting alone is insufficient. If it's a low-risk internal tool, the simplicity might be worth the risk. But in either case, adding a second layer — even a simple one like WebAuthn — costs very little and buys you a lot.
One thing I want to flag before we wrap — this whole problem is getting harder, not easier. IPv6 adoption and carrier-grade NAT mean static IPs are becoming rarer. More and more people are behind shared addresses they don't control. The trend is clearly toward identity-based access, because network-based access is becoming less reliable even for the people who want to use it.
The tools for identity-based access are getting better and cheaper. Five years ago, setting up an identity-aware proxy was a serious engineering project. Now Cloudflare gives it to you for free. Tailscale makes it a checkbox. The friction is dropping fast.
If you take one thing from this episode, it's that IP allowlisting is a layer, not a gate. It has a legitimate role in defense-in-depth, but if it's the only thing standing between the internet and your admin panel, you've got a problem.
The practical takeaway — if you need a fixed egress IP today, Tailscale plus Mullvad is the path of least resistance. But while you're setting that up, ask yourself whether you should be moving toward identity-based access instead. The answer might be both.
We've been talking about the mechanics of fixed egress IPs and whether the whole model still holds up. The open question I keep coming back to is whether IP allowlisting goes the way of the firewall rule — still used everywhere, but nobody trusts it as a primary control anymore. I suspect that's where we're headed.
I think you're right. And the shift is being driven by the infrastructure itself. When everyone had a static residential IP, allowlisting made intuitive sense. Now that your IP changes every time you switch from Wi-Fi to cellular, the model is breaking at the seams. Identity-based access isn't just more secure — it's becoming more convenient too.
Thanks to our producer Hilbert Flumingtop for making this episode happen. This has been My Weird Prompts. If you've got a weird prompt you want us to tackle, email the show at show at my weird prompts dot com. We read every one.
We'll be back soon.
