Working remotely is awesome. But it comes with a few weird tech problems. One of the funniest (and most annoying) I ran into recently? My own team got locked out of our website simply because we used a VPN.
TL;DR: My security plugin thought VPN traffic was suspicious and started banning team members. Why? Because the VPN provider’s shared IP pool caused the plugin to think we were under attack. I created smart exception rules to fix the issue while still staying secure. Everyone’s happy now — and nobody’s locked out.
What happened?
Our dev team uses a VPN. It’s a big-name provider we trust. One day, messages started popping up: “Hey, I can’t log in.” “Why am I banned?” The site was blocking key team members. Weird, right?
At first, I thought it was a bug. I checked logs in my security plugin. Nope, not a bug. The plugin was doing its job — maybe a bit too well.
The culprit: shared IPs
VPNs often rotate IP addresses. Even worse, they reuse them. So if one person does something sketchy on that IP, and later someone legit (like my team) uses it, boom — the IP is blacklisted.
That’s exactly what happened. The VPN provider had an IP pool. My plugin saw traffic from a few of those suspicious IPs. It figured we were under attack and started banning everyone coming from that pool.
Security plugin logic: Friend or foe?
Let’s talk about my plugin for a second. I use a popular WordPress security plugin. Great tool. It blocks brute-force attacks, scan attempts, and shady login behavior.
Part of its job is looking at IP reputation. If an IP shows up in a list of bad guys, or if there are too many failed login attempts from it — ban. Seems logical.
But here’s the twist: It doesn’t know about VPNs using shared IPs. So two totally separate people using the same VPN can get tied together, at least in the eyes of the plugin.
The not-so-great side effects
- Our content writer got blocked mid-edit.
- The QA tester couldn’t access the staging site.
- Our project manager had to tether from a phone to send updates.
Turns out, this little issue caused bigger delays. We had Slack messages flying and panic emojis everywhere. Some even thought we were being hacked. Nope, it was just… ourselves.
How I fixed it with smart exception rules
Okay, time to solve this. I had two goals:
- Keep the site secure (duh).
- Let my team access the site without getting booted.
I didn’t want to turn off the security plugin — that would be overkill. Instead, I went for something smarter: exception rules.
Step 1: Identify the common IPs
I pulled up the logs from the plugin. Turns out most bans came from a handful of IPs. Those IPs matched ones used by my VPN provider. I checked the provider’s documentation and forums. Yup, shared IP pool confirmed.
Step 2: Create a safe list
The plugin had an option to whitelist IPs. So I created a list of known-safe IPs my team used. But here’s the problem — shared IPs change often. Updating them manually every other day was not my idea of fun.
So instead, I got sneaky-smart:
Step 3: Use user agent tagging
I told my team to use a VPN profile that included a unique user-agent string in the HTTPS headers. It’s a little trick you can set up in some browsers or VPN tools. For example, “MyTeamVPN-Agent.”
Then I set a rule in the plugin: If this user-agent shows up, and login is attempted — don’t auto-ban, even with multiple failed attempts.
This method isn’t foolproof, but it reduces false positives like crazy.
Step 4: Geo-filtering exceptions
Bonus move — I knew our team mostly logged in from two countries. I set a rule to be a bit more forgiving for VPN traffic coming from those locations. Combined with the user-agent setup, it worked like a charm.
What I learned (and how you can avoid my fate)
Security tools are powerful. They’re also a little too eager sometimes. The best thing I did? Taught my plugin the difference between “bad guy” and “team member on a VPN.”
Here’s a quick list of tips to stay secure and avoid unnecessary bans:
- Check if your VPN reuses public IPs — many do.
- Whitelist IPs cautiously. Don’t use this method alone.
- Use user-agent rules if your security plugin supports them.
- Geo-target your trust levels — be precise, not open-ended.
- Consider adding login rate limits per user instead of globally per IP.
Bonus: Use DNS logging
One way I discovered problematic VPN traffic was through my DNS logs. Depending on your host, you can see odd spikes or patterns — like five different users suddenly appearing from one IP. Cool trick: If you see “login.php” getting hit multiple times from mixed user accounts, and the IP is a known VPN provider, add it to your exception workflow, not your ban list.
It’s about balance: Block the bad, trust the good
Security isn’t just about keeping enemies out — it’s about not locking your friends out. My setup now allows my remote team to work freely with fewer disruptions. And our plugin still catches real threats, like shady crawlers trying brute-force logins from offshore.
We’ve had zero lockouts since setting up these exception rules. And I sleep better knowing the firewall doesn’t hate my team anymore.
Final thoughts
If your security setup starts interfering with productivity, don’t disable it — fine-tune it. A few smart tweaks to your rules can make your system way better. Most plugins have advanced features you’re probably not using yet.
So next time your site’s security flags your designer or locks out your PM for “suspicious behavior,” ask yourself: Is the plugin too paranoid… or is your team just too remote?
Glad I figured it out before someone threw their laptop across the room.