✅ Vpc-cidr overlap with home-network and vpn connection issues for resources access
✅ Option 1 — From Your Local Laptop (Fastest)
When you connect to Pritunl VPN → run:
ip a | grep tunYou will see something like:
inet 10.8.0.23/24Then your VPN CIDR is:
10.8.0.0/24Whatever subnet appears next to the tun0 interface → that’s the range.
✅ Option 2 — Pritunl Web UI
1️⃣ Login to Pritunl Admin Panel 2️⃣ Go to Servers 3️⃣ Select your VPN Server name 4️⃣ Check:
- VPN Network or Client Address Pool
- Usually under Advanced → “Virtual Network”
Example values you may see:
10.8.0.0/24192.168.200.0/2410.99.0.0/24
This exact CIDR must be allowed in RDS SG.
✅ Option 3 — Check VPN Profile (.ovpn) File
Open your downloaded .ovpn file:
cat ~/Downloads/profile.ovpn | grep routeYou may find:
route 10.8.0.0 255.255.255.0Convert Mask → CIDR:
10.8.0.0/24📌 IMPORTANT Note
Do NOT take VPC CIDR Take the VPN Virtual Network CIDR ✔️
Example:
| Where | CIDR |
|---|---|
| VPC CIDR | 10.0.0.0/16 ❌ |
| Pritunl VPN subnet | 10.8.0.0/24 ✔️ |
You will allow only the VPN CIDR on port 3306 for MariaDB RDS.
🔥 Why does this break sometime?
When a user’s home LAN uses 10.0.0.0/8 (or any part overlapping your VPC CIDR), their device routes those local addresses to the home router instead of the VPN. So even if DNS tries to resolve .2 AWS DNS for the VPC:
Client sees: 10.x.x.2 belongs to my LAN → routing conflict → failEven full-tunnel mode does NOT override this if the OS routing table still prioritizes the home network. The VPN client will refuse to install conflicting routes.
✔️ What are the correct solutions?
| Solution | Difficulty | Works long-term? | Notes |
|---|---|---|---|
| Do NOT use RFC1918 ranges in VPC | ⭐ Easy | ✅ Best | Use 100.64.0.0/10 (CGNAT) for AWS VPC. Zero clashes with home networks. |
| NAT client IPs behind a unique VPC subnet | ⚙️ Medium | ⚠️ Adds complexity | Fixes overlap but breaks local-address attribution/debugging. |
| Force-tunnel + custom routing rules | 😕 Hard | ❌ Not guaranteed | Still breaks DNS reachability due to route rejection. |
| Tell users to change home subnet | 🤣 | ❌ Impossible | Not realistic for employees/home users. |
⭐ Recommended AWS best practice
Use 100.64.0.0/10 address space for the VPC or VPN-side addressing
This range is specifically reserved for Carrier-Grade NAT and rarely used in homes:
100.64.0.0 - 100.127.255.255Most AWS environments are planned to avoid overlap before deploying Client VPN — because once remote access is introduced, overlap risk grows significantly.
Example architecture (works with ALL home networks)
| Component | CIDR |
|---|---|
| VPC | 100.64.0.0/16 |
| Client VPN CIDR | 100.65.0.0/22 |
| AWS DNS resolver | Provided inside that VPC range |
| Peered networks? | Routed with NAT if needed |
If you cannot rebuild the VPC (short term workaround)
You can NAT client IPs to a dedicated translation subnet:
Client → VPN → NAT (VPC ephemeral CIDR) → VPCBut:
- Harder to track sessions
- Breaks IP-based firewalls/policies
- Adds latency + complexity
Use only as a temporary fix.
Practical takeaway
Yes — overlapping CIDR = guaranteed routing pain. No — you cannot force users to change home LANs. Best fix — move AWS VPC to 100.64.0.0/10 to avoid consumer network ranges.
If you want, I can help you design a migration plan: ✔ Create new VPC ✔ Setup transit routing from old → new ✔ Migrate subnets, EC2, RDS, ECS, S3 endpoints step-by-step ✔ Zero downtime approach if needed
Would you like me to create a CIDR planning sheet for your environment and future peering constraints (e.g., on-prem, partner networks, VPN peers)?