Over the years, in my network and system administration career, I've encountered many different technologies. Some made my job easier, while others unnecessarily created complexity and cost me extra hours. One of these topics, falling into the latter category, especially on the VPN side, is "dual-stack" – the simultaneous use of both IPv4 and IPv6.
In my opinion, in many scenarios, forcing dual-stack only adds an extra burden to your career. Especially when making this decision for a VPN infrastructure, it's crucial to consider not just the technical requirements, but also the operational costs and long-term problems. Now, I will explain step-by-step why I think this, based on my own experiences.
Where Did the Dual-Stack Craze Come From and Why Is It Problematic?
It's true that IPv6 has an inevitable future; IPv4 addresses are running out, and the transition to IPv6 is essential for the next generation internet. This fundamental truth pushes some managers or architects to say, "since that's the case, let's make everything dual-stack immediately." Especially at critical access points like VPNs, the idea of being able to connect via both IPv4 and IPv6 might seem logical on paper.
However, in practice, this hasty decision often doubles the existing complexity. In one project, while setting up a VPN tunnel for our overseas branches, we opted for dual-stack, thinking it would be "future-proof." Initially, everything seemed fine, but we soon encountered a tangle of unexpected issues and entered a debugging process that lasted for weeks. This situation turned into an operational nightmare that complicated the management of the entire network infrastructure, far beyond a simple connection problem.
IP Address Management: The Two-Headed Monster
In a dual-stack VPN environment, IP address management is not only complex but also sets the stage for potential conflicts. You need to assign both an IPv4 and an IPv6 address for every user or device. This complicates address planning, especially managing overlapping address spaces.
In a client project, when we configured the OpenVPN server as dual-stack, users sometimes connecting via IPv4 and sometimes via IPv6 caused problems. I witnessed undesirable situations, especially with mobile devices or users connecting through different ISPs, due to DNS resolution or routing preferences. For example, when a VPN-connected user's IPv6 address conflicted with an internal company resource, access issues arose.
# Check IPv6 addresses on the server
$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:cafe::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe0e:3714/64 scope link
valid_lft forever preferred_lft forever
# IPv6 definition in OpenVPN client config
# client.ovpn
client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
# For IPv6 address assignment
ifconfig-ipv6 2001:db8:dead::10/64 2001:db8:dead::1
As you can see, planning separate IPv4 and IPv6 address blocks, preventing conflicts, and correctly configuring tunnel mechanisms for both protocols brings a significant workload. A wrong prefix choice carries the risk of conflicting with other networks as it grows. This makes me think, "why should I put in twice the effort when I can manage a single network stack?"
Routing and Firewall Rules: A Nightmare Scenario
In a dual-stack environment, routing tables and firewall rules also double. You need to define separate routes and apply separate security policies for both protocols. This not only increases configuration complexity but also raises the probability of making errors.
At a manufacturing company's VPN gateway, I had to define separate nftables rules for both IPv4 and IPv6. Writing, testing, and maintaining hundreds of rules for both IPv4 and IPv6 was a significant waste of time. Moreover, occasionally forgetting to add a rule to IPv6 after adding it to IPv4 led to security vulnerabilities or access issues.
⚠️ Routing Flap Danger
Misconfigured dual-stack routing, especially if dynamic routing protocols like BGP are used, can lead to "routing flaps." This means routing tables constantly change, and the network becomes unstable. Independent changes in IPv4 and IPv6 routes can further complicate this situation and make troubleshooting impossible.
Below is a simplified example showing how a basic firewall rule set doubles in a dual-stack environment:
# nftables rules (for IPv4)
table ip filter {
chain input {
type filter hook input priority 0; policy drop;
# ...
# Allow IPv4 traffic coming through the VPN tunnel
iifname "tun0" ip saddr 10.8.0.0/24 accept
# ...
}
}
# nftables rules (for IPv6)
table ip6 filter {
chain input {
type filter hook input priority 0; policy drop;
# ...
# Allow IPv6 traffic coming through the VPN tunnel
iifname "tun0" ip6 saddr 2001:db8:dead::/64 accept
# ...
}
}
Even a simple rule like in this example requires two separate tables and two separate rule sets when dual-stack. When you consider complex enterprise firewall policies, you can imagine how out of control this situation can become. This extra workload directly falls on the shoulders of people in operational roles like me.
MTU/MSS Mismatches and Fragmentation: Silent Killers
VPN tunnels add extra headers to data packets, reducing the MTU (Maximum Transmission Unit) value. In a dual-stack VPN environment, correctly setting these MTU/MSS (Maximum Segment Size) values for both IPv4 and IPv6 and preventing fragmentation becomes even more critical. Incorrect configurations can lead to packet loss, slow connections, and even some applications not working at all.
While trying to access the backend servers of an e-commerce site via VPN, we experienced constant interruptions during the transfer of some large files. At first, I thought it was a firewall or routing problem, but after analyzing with tcpdump, I found that it was fragmentation issues caused by MTU mismatches. I realized that both IPv4 and IPv6 packets were not being carried with the correct MTU within the tunnel.
# Check PMTUD (Path MTU Discovery) on Linux
# Discover MTU by pinging a target IP for IPv4
$ ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.100 icmp_seq=1 Frag needed and DF set (mtu = 1480)
# This output indicates that a 1472-byte packet requires fragmentation and
# cannot be sent because the DF (Don't Fragment) bit is set. The MTU needs
# to be lowered.
# Similar check for IPv6
$ ping -6 -M do -s 1452 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 1452 data bytes
From 2001:db8:cafe::1 icmp_seq=1 Packet too big (mtu 1460)
# Here, there is a similar problem for IPv6.
Such problems become a complete headache, especially when MTU values behave differently across various network layers (IPsec, OpenVPN, WireGuard) and different platforms (Windows, macOS, Linux, mobile). I've often seen a problem I solved on one side reappear on the other. This unnecessarily cost me hours.
Troubleshooting: Digging for a Needle in a Haystack
Troubleshooting in a dual-stack VPN is like digging for a needle in a haystack. When you encounter a problem, you first need to understand if the issue is in the IPv4 or IPv6 layer. Then, you need to check separate logs, routing tables, firewall rules, and interface statistics for both protocols.
Last year, in the test environment of my side product, I couldn't connect to a Redis instance via VPN. The connection sometimes worked, sometimes didn't. It took me a full day to examine journalctl outputs and tcpdump traces. Finally, I realized that some clients were trying to connect to Redis over IPv6, while the Redis server was only listening on IPv4. This was a situation that required much more time and effort than a classic IPv4 problem.
# Monitor IPv6 connection attempts in OpenVPN server logs
$ journalctl -u openvpn-server@server.service -f | grep -E "IPv4|IPv6"
Jun 05 10:30:05 vpn-server ovpn-server[12345]: TCP/UDP: Incoming packet from [IPv4_CLIENT_IP]:PORT (via tun0)
Jun 05 10:30:06 vpn-server ovpn-server[12345]: TCP/UDP: Incoming packet from [IPv6_CLIENT_IP]:PORT (via tun0)
Jun 05 10:30:07 vpn-server ovpn-server[12345]: [client] Peer Connection Initiated with [IPv4_CLIENT_IP]:PORT
Jun 05 10:30:08 vpn-server ovpn-server[12345]: [client] Peer Connection Initiated with [IPv6_CLIENT_IP]:PORT
# Check which addresses Redis is listening on the target server
$ ss -lntp | grep redis-server
tcp LISTEN 0 128 0.0.0.0:6379 0.0.0.0:* users:(("redis-server",pid=6789,fd=6))
# This output shows that Redis is only listening on IPv4.
# If I wanted it to listen on IPv6 as well, the output would include the IPv6 address, for example:
# tcp6 LISTEN 0 128 [::]:6379 [::]:* users:(("redis-server",pid=6789,fd=7))
Such scenarios not only steal the time of system administrators and DevOps engineers but also increase their stress levels. Every extra minute I spend solving a problem is a minute I steal from another, more important task.
Operational Cost and Career Burden: The Real Price
All these technical difficulties ultimately increase operational costs and place an unnecessary burden on the careers of those responsible for infrastructure, like me. Dual-stack implementation means more planning, more configuration, more testing, and more debugging time from start to finish. This directly translates to longer working hours, more stress, and less productivity.
While modernizing the VPN infrastructure for a bank's internal platform, the idea of going dual-stack was initially proposed. I conducted a feasibility and risk analysis that lasted approximately 2 weeks. In this analysis, I thoroughly examined topics such as the existing network infrastructure's IPv6 support, application compatibility, and how security layers would adapt to both protocols. As a result, I reported that the additional burden on the project's budget and timeline would far outweigh the benefits. This analysis alone took me 3 working days.
ℹ️ Related Topic: Similar Challenges in Microservice Architectures
I had previously performed a similar trade-off analysis when breaking down a monolithic ERP application into microservices. Each service having its own database, a separate deployment process, and different dependencies increased management complexity and operational cost. Dual-stack VPN similarly creates unnecessary separation and complexity at the network layer. Keeping it simple is often a better strategy.
This situation not only challenges your technical skills but also tests your time management and stress-coping abilities. As a career goal, I believe it's more valuable to focus on building robust, sustainable, and easy-to-manage systems rather than setting up overly complex ones. Every unnecessary complexity added is an element that increases your workload and burdens your career.
Alternatives and My Approach: Avoiding Forced Solutions
So, what should we do when the transition to IPv6 is inevitable? My approach to this is quite pragmatic: if your application or infrastructure is not directly dependent on IPv6, or if there's no such requirement, don't force dual-stack on the VPN side. Instead, maintain your existing IPv4 VPN infrastructure and handle the transition to IPv6 in a more controlled and phased manner.
There are smarter strategies for transitioning to IPv6. For example, if clients still need to connect to the VPN over IPv4 and access internal IPv6 resources, you can use technologies like NAT64/DNS64. With this approach, your VPN tunnel operates only over IPv4, but an internal DNS server (DNS64) translates IPv6 addresses to IPv4, and a NAT64 gateway routes the traffic. This brings much less complexity than making the VPN tunnel dual-stack.
| Approach | VPN Tunnel Complexity | IP Address Management | Troubleshooting Difficulty | Operational Cost |
|---|---|---|---|---|
| IPv4-Only VPN | Low | Low | Low | Low |
| Dual-Stack VPN | High | High | Very High | Very High |
| IPv4 VPN + NAT64 | Low | Medium | Medium | Medium |
Based on my experience, I have tested this table many times. In one of my projects, using only an IPv4 VPN, some IoT devices on the internal network needed to access IPv6 addresses. We solved this problem with NAT64/DNS64 without making the VPN tunnel dual-stack. This solution saved me from weeks of potential headaches and significantly reduced my operational burden.
💡 Simplicity Is Always Best
In network architecture and operations, "simplicity" is always the best strategy. Unnecessary complexities not only increase your chances of making mistakes but also make troubleshooting and maintenance processes much more challenging. Instead of forcibly integrating a technology just because it's "the future," it's essential to evaluate real needs and operational impacts.
Conclusion: Smart Choices, Peaceful Operations
VPN dual-stack implementation is a decision that seems logical on paper but in practice unnecessarily increases operational complexity and costs. My 20 years of field experience have shown that such "future-proof" forced solutions often create long-term headaches rather than immediate benefits.
In my career, as an infrastructure engineer, my most valuable resources are my time and mental energy. Every system I unnecessarily complicate, like a dual-stack VPN, consumes these resources. That's why, when making technology choices, I always ask the question, "how much additional burden will this bring to me or my team?" If there's no clear benefit and alternatives are simpler, my preference is always for simplicity. Remember, a good system is not just one that works, but one that is also easy to manage.
Top comments (0)