RFC 5684
Unintended Consequences of NAT Deployments with Overlapping Address Space
Unintended Consequences of NAT Deployments with Overlapping Address Space 🎀
okay bestie, here's the vibe check on the header first 💅
- Stream: Independent Submission. This one came in from outside the normal IETF process 🦋
- Number: RFC 5684
- Authors: P. Srisuresh (EMC Corporation) and B. Ford (Yale University) 👑
- Category: Informational, so it's not a standards-track spec ✨
- ISSN: 2070-1721
- Date: February 2010 🌸
- Obsoletes/Updates: the header doesn't list anything it obsoletes or updates 🙈
Abstract ✨
okay so this doc is about two setups that popped up because people built wild network layouts with Network Address Translator (NAT) boxes 🧚
First, NAT and DHCP together are SO easy to set up that people keep stacking private networks inside other private networks, and those networks end up using overlapping private IP address spaces. 😭
Second, private networks are everywhere now (enterprises, hotels, conferences), and lots of people use Virtual Private Networks (VPNs) to get into a company intranet from far away. That means the remote network and the corporate network can end up with overlapping private IP address space too 💀
The doc doesn't say these setups are invalid. It says they're REAL, and it gives recommendations so they can work without a total meltdown 🫶
Status of This Memo 🌈
This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🍓
It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Docs approved by the RFC Editor aren't a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 📚
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5684. 💜
Copyright 🔥
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication. Read those carefully, because they spell out your rights and restrictions for this document 🎀
Table of Contents 🗂️
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
3. Multi-Level NAT Network Topologies ..............................4
3.1. Operational Details of the Multi-Level NAT Network .........6
3.1.1. Client/Server Communication .........................7
3.1.2. Peer-to-Peer Communication ..........................7
3.2. Anomalies of the Multi-Level NAT Network ...................8
3.2.1. Plug-and-Play NAT Devices ..........................10
3.2.2. Unconventional Addressing on NAT Devices ...........11
3.2.3. Multi-Level NAT Translations .......................12
3.2.4. Mistaken End Host Identity .........................13
4. Remote Access VPN Network Topologies ...........................14
4.1. Operational Details of the Remote Access VPN Network ......17
4.2. Anomalies of the Remote Access VPNs .......................18
4.2.1. Remote Router and DHCP Server Address Conflict .....18
4.2.2. Simultaneous Connectivity Conflict .................20
4.2.3. VIP Address Conflict ...............................21
4.2.4. Mistaken End Host Identity .........................22
5. Summary of Recommendations .....................................22
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................251. Introduction and Scope 🦋
okay so the Internet was originally designed around ONE global 32-bit IP address space. Every host could uniquely identify itself, and any app on one host could reach any app on any other host, no matter where that host was or whose it was 🌍
But for a bunch of practical reasons, the Internet slowly drifted away from that single flat global address space. It moved toward a hierarchy of smaller "private" address spaces [RFC1918] clustered around one big central "public" address space. The main practical causes of this unplanned evolution seem to be these 💅
- Running out of 32-bit IPv4 addresses 😭 The number of hosts on the Internet exploded. IPv6 promises to fix this, but adoption has been slower than everyone expected.
- Perceived Security and Privacy 🔒 Traditional NAT devices filter traffic so that sessions can only cross the NAT in one direction, from private hosts out to public network hosts. People see this filtering as a security win. On top of that, swapping a host's original private IP address and port number for an unrelated external IP address and port number is seen by some as a privacy win too 🙈
- Ease-of-Use 🧚 NAT vendors often put a DHCP server function in the same box as the NAT. That makes a super convenient "plug-and-play" setup for small personal networks, which is way easier for non-techy people than configuring an IP subnet. Lots of popular, cheap consumer NAT devices come ready to grab one "public" IP address from an ISP or "upstream" network using DHCP [DHCP]. The NAT then acts as both the DHCP server and default router for any "downstream" hosts (and even other NATs) you plug in. Basically, consumer NATs quietly create and manage home networks for you, no networking knowledge required. Auto-configuration of private hosts is why NAT devices are such a compelling solution in this common scenario ✨
[NAT-PROT] lists various complications that NAT devices cause for application protocols. This document is an adjunct to [NAT-PROT] 📚
The scope here is limited to the two scenarios in Sections 3 and 4, which come from unconventional NAT deployments and private address space overlap. These setups look unconventional, but they're honestly not uncommon 👑 For each scenario, the doc describes the seeming anomalies and offers recommendations for making the topologies work.
Section 2 covers the terminology and conventions. Section 3 covers the overlapping private address space problem in a multi-level NAT topology, the anomalies in that topology, and recommendations for them. Section 4 covers the overlapping private address space problem with remote access Virtual Private Network (VPN) connections, the anomalies in that topology, and recommendations for those. Section 5 covers the security considerations for these scenarios 🎀
2. Terminology and Conventions Used 🌸
In this document, the IP addresses 192.0.2.1, 192.0.2.64, 192.0.2.128, and 192.0.2.254 are used as example public IP addresses [RFC5735]. These addresses all sit in the same /24 network, but that's just a limitation of the example addresses available in [RFC5735]. In practice, these addresses would be on different networks 🧚
Readers are urged to check [NAT-TERM] for NAT taxonomy and terminology 💜 Unless a NAT type is prefixed or stated otherwise, the term NAT, used all through this document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has two variations: Basic NAT and Network Address Port Translator (NAPT). NAPT is by far the most commonly deployed NAT device 😭 NAPT lets multiple private hosts share a single public IP address at the same time 🫶
3. Multi-Level NAT Network Topologies 🌸
okay so, because of the pragmatic reasons we just covered (and probably some others too), NATs are being used more and more to build hierarchically connected clusters of private networks. and honestly? it's often totally unintentional 💀 multi-level hierarchies just kinda happen, since each level of NAT is usually set up by a different administrative entity, like an ISP, a corporation, or a home user. it's giving accidental architecture 🧚
Public Internet
(Public IP Addresses)
----+---------------+---------------+---------------+----
| | | |
| | | |
192.0.2.1 192.0.2.64 192.0.2.128 192.0.2.254
+-------+ Host A Host B +-------------+
| NAT-1 | (Alice) (Jim) | NAT-2 |
| (Bob) | | (CheapoISP) |
+-------+ +-------------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 1 Private Network 2
(Private IP Addresses) (Private IP Addresses)
----+--------+---- ----+-----------------------+----
| | | | |
| | | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12
Host C Host D +-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 | Private Network 4
(Private IP Addresses)| (Private IP Addresses)
----+-----------+---+ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host IFigure 1. Multi-Level NAT Topology with Overlapping Address Space
so in this scenario, Bob, Alice, Jim, and CheapoISP have each scored a "genuine", globally routable IP address from an upstream service provider 🎀 Alice and Jim went with just one machine per public IP, which keeps the originally intended architecture of the Internet vibing, and it means their hosts, A and B, are globally addressable all over the Internet 🦋 Bob, on the other hand, bought and plugged in a typical consumer NAT box. Bob's NAT gets its external IP address (192.0.2.1) from Bob's ISP via DHCP, and it automatically creates a private 10.1.1.x network for Bob's hosts C and D. it acts as the DHCP server and default router for that network too. Bob probably doesn't even know anything about IP addresses 🙈 he just knows that plugging the NAT into the Internet like the ISP said, then plugging his hosts into the NAT like the NAT's manual says, seems to work and gives all his hosts Internet access. no notes, iconic behavior honestly 💅
CheapoISP is an inexpensive service provider that got only one or a few globally routable IP addresses, so it uses NAT to share those public addresses among its many customers 💜 this setup is becoming super common, especially in rapidly developing countries where the explosion of Internet-attached hosts way outpaces the ability of ISPs to get globally unique IP addresses for them. CheapoISP picked the popular 10.1.1.x address block for its private network, since it's one of the three well-known private IP address blocks allocated in [RFC1918] specifically for this purpose 🍓
the last two of the three incentives listed in section 1 for NAT deployment still apply even to customers of ISPs that use NAT, and that's how you get multi-level NAT topologies, like the right side of the diagram above 😭 three-level NAT topologies are known to exist too, no cap. CheapoISP's customers Ann, Mary, and Lex each got a single IP address on CheapoISP's network (Private Network 2) via DHCP. Mary only attaches a single host at this point, but Ann and Lex each independently buy and deploy consumer NATs the same way Bob did. plot twist: these consumer NATs also happen to use 10.1.1.x addresses for the private networks they create, because those are the configuration defaults hard-coded into the NATs by their vendors ✨ Ann and Lex probably know nothing about IP addresses, and they're probably unaware that the IP address spaces of their own private networks overlap not only with each other, but also with the private IP address space used by their immediately upstream network. chaotic, but make it make sense 🤪
and yet, despite this direct overlap, all the "multi-level NATed hosts" (F, G, H, and I in this case) nominally function and can initiate connections to any public server on the public Internet that has a globally routable IP address 🔥 connections from these hosts to the main Internet just get translated twice: once by the consumer NAT (NAT-3 or NAT-44) into the IP address space of CheapoISP's Private Network 2, and then again by CheapoISP's NAT-2 into the public Internet's global IP address space 👑
3.1. Operational Details of the Multi-Level NAT Network
in the "de facto" Internet address architecture that comes out of all these pragmatic and economic incentives, only the nodes on the public Internet have globally unique IP addresses assigned by the official IP address registries 🌈 IP addresses on different private networks are typically managed independently. either the private network's own administrator handles them manually, or the NAT that connects that private network to its "upstream" service provider handles them automatically.
by convention, nodes on private networks usually get IP addresses from one of the private address space ranges that RFC 1918 specifically set aside for this purpose 🫶 this keeps private IP addresses easy to spot and stops them from clashing with the public IP addresses officially given to globally routable Internet hosts. however, when plug-and-play NATs are used to build hierarchically connected clusters of private networks, a given private IP address can be, and often is, reused across lots of different private networks. in figure 1 above, for example, private networks 1, 2, 3, and 4 all have a node with IP address 10.1.1.10 🦋
3.1.1. Client/Server Communication
when a host on a private network starts a client/server-style communication session with a server on the public Internet, using the server's public IP address, the NAT intercepts the packets that make up that session (usually because it's the default router for the private network). then it modifies the packets' IP and TCP/UDP headers so the session looks, from the outside, like the NAT itself started it 🎀
for example, if host C above starts a connection to host A at IP address 192.0.2.64, NAT-1 modifies the packets in that session so they appear on the public Internet as if the session came from NAT-1. similarly, if host F on private network 3 starts a connection to host A, NAT-3 modifies the outgoing packet so it appears on private network 2 as if it came from NAT-3 at IP address 10.1.1.10. when that modified packet goes through NAT-2 on private network 2, NAT-2 modifies the outgoing packet again so it appears on the public Internet as if it came from NAT-2 at public IP address 192.0.2.254. the NATs basically work as proxies, giving their private "downstream" client nodes a temporary presence on "upstream" networks so individual communication sessions can happen 💖
in summary, all hosts on private networks 1, 2, 3, and 4 in figure 1 above are able to establish client/server-style communication sessions with servers on the public Internet 🌸
3.1.2. Peer-to-Peer Communication
this network setup works fine in practice for client/server-style communication 🧚 but when the client is behind one or more levels of NAT and the server is on the public Internet, the lack of globally routable addresses for hosts on private networks makes direct peer-to-peer communication between those hosts hard. for example, two private hosts, F and H, on the network shown above might "meet" and find out about each other through a well-known server on the public Internet, like host A, and want to set up direct communication between G and H without having A forward every single packet. but if G and H just learn each other's (private) IP addresses from a registry kept by A, their connection attempts will fail, because G and H live on different private networks 😭 even worse, if their connection attempts aren't properly authenticated, they might look like they succeed but end up talking to the wrong host. for example, G might end up talking to host F, the host on private network 3 that happens to have the same private IP address as host H. host H could similarly end up accidentally connecting to host I 💀
in summary, peer-to-peer communication between hosts on disjoint private networks 1, 2, 3, and 4 in figure 1 above is a real challenge without help from a well-known server on the public Internet. however, with help from a node on the public Internet, all hosts on private networks 1, 2, 3, and 4 in figure 1 above are able to establish peer-to-peer-style communication sessions with each other, as well as with hosts on the public Internet 👑✨
3.2. Anomalies of the Multi-Level NAT Network ✨
Okay so, conventional wisdom says this network is seriously broken 💀, but ngl it still works in a bunch of ways 🫶. We split figure 1 into two sub-figures so the weirdness is easier to see. Figure 1.1 is the left half of figure 1. It's the regular single NAT setup that shows up all over last-mile locations 🏠. People see it as a practical workaround for running out of IPv4 address space, and it's not considered broken. Figure 1.2 is the right half of figure 1, and it's the one full of anomalies we're about to dish on 👀.
Public Internet
(Public IP Addresses)
----+---------------+---------------+-----------
| | |
| | |
192.0.2.1 192.0.2.64 192.0.2.128
+-------+ Host A Host B
| NAT-1 | (Alice) (Jim)
| (Bob) |
+-------+
10.1.1.1
|
|
Private Network 1
(Private IP Addresses)
----+--------+----
| |
| |
10.1.1.10 10.1.1.11
Host C Host D
Figure 1.1. Conventional Single-level NAT Network topology Public Internet
(Public IP Addresses)
---+---------------+---------------+----
| | |
| | |
192.0.2.64 192.0.2.128 192.0.2.254
Host A Host B +-------------+
(Alice) (Jim) | NAT-2 |
| (CheapoISP) |
+-------------+
10.1.1.1
|
|
Private Network 2
(Private IP Addresses)
----+---------------+-------------+--+-------
| | |
| | |
10.1.1.10 10.1.1.11 10.1.1.12
+-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 Private Network 4
(Private IP Addresses) (Private IP Addresses)
----+-----------+------ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host I
Figure 1.2. Unconventional Multi-Level NAT Network Topology3.2.1. Plug-and-Play NAT Devices
Consumer NAT devices are mostly plug-and-play 🔌, which means they assume minimal user intervention during setup. These devices hand out DHCP service on one interface and do NAT on another. The vendors make assumptions about how consumers will configure and hook up their PCs. When consumers don't follow those assumptions, they can end up with a broken network 😭.
A plug-and-play NAT device provides DHCP service on the LAN attached to its private interface, and it assumes that all private hosts at the consumer site have DHCP client enabled and are connected to that single LAN. Consumers need to be aware that all private hosts must be on a single LAN, with no router in between 🚫.
A plug-and-play NAT device also assumes there's no other NAT device or DHCP server on the same LAN at the customer premises. But if there are multiple plug-and-play NAT devices on the same LAN, each one will offer DHCP service on that LAN, and they might even pull from the same private address pool. That can leave multiple end nodes on the same LAN with identical IP addresses, and connectivity goes right out the window 💀.
Here's the plot twist though: most consumer deployments have a single LAN where they deploy one plug-and-play NAT device, so the concerns above haven't really been an issue in reality ✨.
3.2.2. Unconventional Addressing on NAT Devices
Let's talk about the unconventional addressing on NAT-3 and NAT-4 🧐. Both of them are apparently multi-homed on the same subnet through both of their interfaces. NAT-3 sits on subnet 10.1.1/24 through its external interface facing NAT-2, and also through its private interface facing clients host F and host G. NAT-4 has two interfaces on the same subnet, 10.1.1/24, too.
In a traditional network, if a node has multiple interfaces with IP addresses on the same subnet, it's natural to assume that all of those interfaces are on one connected LAN (a bridged LAN or a single physical LAN). Clearly, that's not the case here 🙃. Even though NAT-3 and NAT-4 each have two interfaces on the same subnet 10.1.1/24, the NAT devices see those two interfaces as being on two disjoint subnets and routing realms. So the plug-and-play NAT devices aren't really multi-homed on the same subnet in the traditional sense.
In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should be incapable of communicating reliably as transport endpoints with other nodes on their adjacent networks (for example, private networks 2 and 3 in the case of NAT-3, and private networks 2 and 4 in the case of NAT-4). The reason is that applications on either NAT device can't tell apart packets from hosts on either of the subnets that share the same IP address. If NAT-3 tries to resolve the IP address of a neighboring host the conventional way, by broadcasting an Address Resolution Protocol (ARP) request on all of its physical interfaces on the same subnet, it may get a different response on each physical interface 😬.
Even though both NAT-3 and NAT-4 have hosts with the same IP address on their adjacent networks, the NAT devices do communicate effectively as endpoints 💖. Many plug-and-play NAT devices offer a limited number of services. For example, many of them respond to pings from hosts on either interface. Even though a NAT device is often not actively managed, many of them can be managed from the private interface 🛠️. This unconventional communication with NAT devices works because many of these NAT devices conform to REQ-7 of [BEH-UDP] and view the two interfaces as being on two disjoint routing domains. They also distinguish between sessions initiated from hosts on either interface (private or public) 🦋.
3.2.3. Multi-Level NAT Translations
Using a single NAT to connect private hosts to the public Internet, as in figure 1.1, is a pretty common practice. Lots of consumer NATs are deployed this way 🌸. However, multi-level NAT translations, as in figure 1.2, are not common and aren't well understood 🤔.
Let's look at the conventional single NAT translation in figure 1.1. Because the public and private IP address ranges are numerically disjoint, nodes on private networks can use both public and private IP addresses when they start communication sessions. Nodes on a private network can use private IP addresses to refer to other nodes on that same private network, and public IP addresses to refer to nodes on the public Internet. For example, host C in figure 1.1 is on private network 1 and can directly address hosts A, B, and D using their assigned IP addresses. That's true even though hosts A and B are on the public Internet and host D is the only other host on the private network 🎀.
Next up, the unconventional multi-level NAT topology in figure 1.2 🌈. In this scenario, private hosts can connect to hosts on the public Internet. But private hosts can't connect with all the other private hosts. For example, host F in figure 1.2 can directly address hosts A, B, and G using their assigned IP addresses, but F has no way to address any of the other hosts in the diagram. Host F in particular can't address host E by its assigned IP address, even though host E is on the immediately "upstream" private network that F is connected through to reach the Internet. Host E has the same IP address as host G. Yet this addressing is "legitimate" in the NAT world, because the two hosts are on different private networks 🧚.
It might look like the topology in figure 1.2, with multiple NAT translations, is broken because private hosts can't address each other directly. But the network isn't actually broken 🙅♀️. Nodes on any private network have no direct way to address nodes on other private networks. Private networks 1, 2, 3, and 4 are all disjoint, so hosts on private network 1 can't directly address nodes on private networks 2, 3, or 4, and vice versa. Multiple NAT translations weren't the cause of this 💅.
As described in sections 3.1.1 and 3.1.2, client-server and peer-to-peer communication can and should be possible even with a multi-level NAT topology deployment 🫶. A host on any private network must be able to communicate with any other host, no matter which private network it's attached to or where that private network is located. Host F should be able to communicate with host E and carry out both client-server and peer-to-peer communication, and vice versa 👑. Host F and host E form a hairpin session through NAT-2 to communicate with each other. Each host uses the public endpoint assigned by the Internet-facing NAT (NAT-2) to address its peer ✨.
When the deployed NAT devices conform to the hairpin translation requirements in [BEH-UDP], [BEH-TCP], and [BEH-ICMP], peer nodes can connect even in this type of multi-level NAT topology 🎉.
3.2.4. Mistaken End Host Identity 🕵️♀️
Okay so this one is a total plot twist 😭 Mistaken end host identity can cause accidental malfunctions in some multi-level NAT deployments. Check out the scenario in figure 1.3, which shows two levels of NATs sitting between an end-user in private network 3 and the public Internet.
Say CheapoISP assigns 10.1.1.11 to its DNS resolver and advertises it through DHCP to NAT-3, which is the gateway for Ann's home. NAT-3 then passes 10.1.1.11 along as the DNS resolver to host F (10.1.1.10) and host G (10.1.1.11) on private network 3. Now here's the drama 💀: when host F sends a DNS query to 10.1.1.11, the query gets delivered locally to host G on private network 3 instead of reaching CheapoISP's DNS resolver. That's a clear case of mistaken identity, and it happens because CheapoISP advertised a server whose address could overlap with its customers' IP addresses 🙈
Public Internet
(Public IP Addresses)
---+---------------+---------------+----
| | |
| | |
192.0.2.64 192.0.2.128 192.0.2.254
Host A Host B +-------------+
(Alice) (Jim) | NAT-2 |
| (CheapoISP) |
+-------------+
10.1.1.1
|
|
Private Network 2
(Private IP Addresses)
------------+------------------+-------+----------
| |
10.1.1.10 |
+-------+ 10.1.1.11
| NAT-3 | Host E
| (Ann) | (DNS Resolver)
+-------+
10.1.1.1
| Private Network 3
| (Private IP Addresses)
----+---+-----------+----------------
| |
| |
10.1.1.10 10.1.1.11
Host F Host G
Figure 1.3. Mistaken Server Identity in Multi-Level NAT TopologyRecommendation-1: ISPs, using NAT devices to provide connectivity to customers, should assign non-overlapping addresses to servers advertised to customers. One way to do this would be to assign global addresses to advertised servers. ✨
4. Remote Access VPN Network Topologies 🎀
Enterprises use remote access VPN to let employees who are working outside the enterprise premises get secure access 🔐 An employee might be in a home office, a hotel, a conference, or a partner's office. In every one of those cases, it's really important that the remote employee has unhindered access to their corporate network and the applications running on it. And while they're doing that, they should not put the integrity and confidentiality of the corporate network and its applications at risk. No pressure, right? 😅
IPsec, Layer 2 Tunneling Protocol (L2TP), and Secure Socket Layer (SSL) are some of the best-known secure VPN technologies that remote access vendors use. Besides checking employees' identities before granting access, remote access VPN servers often enforce different forms of security (for example, IPsec or SSL) to protect the integrity and confidentiality of the run-time traffic between the VPN client and the VPN server 💜
Lots of enterprises deploy their internal networks using private address space defined in RFC 1918, and they use NAT devices to connect to the public Internet. On top of that, many applications in the corporate network refer to information (like URLs) and services using private addresses inside the corporate network. Applications such as the Network File Systems (NFS) rely on simple source-IP-address-based filtering to limit access to corporate users. That's why remote access VPN servers are often configured with a block of IP addresses from the corporate private network to hand out to remote access clients. VPN clients use the virtual IP (VIP) address they were assigned (by the corporate VPN server) to reach applications inside the corporate network 🦋
Here's the remote access VPN scenario in figure 2:
(Corporate Private Network 10.0.0.0/8)
---------------+----------------------
|
10.1.1.10
+---------+-------+
| Enterprise Site |
| Remote Access |
| VPN Server |
+--------+--------+
192.0.2.1
|
{---------+------}
{ }
{ }
{ Public Internet }
{ (Public IP Addresses) }
{ }
{ }
{---------+------}
|
192.0.2.254
+--------+--------+
| Remote Site |
| Plug-and-Play |
| NAT Router |
+--------+--------+
10.1.1.1
|
Remote Site Private Network |
-----+-----------+-----------+-------------+-----------
| | | |
10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13
Host A Host B +--------+ Host C
| VPN |
| Client |
| on a PC|
+--------+
Figure 2. Remote Access VPN with Overlapping Address SpaceSo here's the tea ☕ An employee is at a remote location and tries to reach the corporate network using the VPN client. The corporate network is laid out using the 10.0.0.0/8 address pool from RFC 1918, and the VPN server has an address block of 10.1.1.0/24 for handing out virtual IP addresses to remote access VPN clients. Now the remote site's network also happens to use RFC 1918 address space, and it coincidentally overlaps the corporate network. In this case, it's conventionally problematic for the VPN client to connect to the server(s) and other hosts at the enterprise. Yikes 😬
Even so, despite the direct address overlap, the remote access VPN connection between the VPN client at the remote site and the VPN server at the enterprise should stay connected and should be made to work. The NAT device at the remote site should not get in the way of the VPN connection traveling through it. And the remote user should be able to reach any host at the enterprise through the VPN from their remote desktop. Main character energy ✨
The following subsections cover the operational details of the VPN, the anomalies that come with address overlap, and recommendations on how best to handle the situation 🌸
4.1. Operational Details of Remote Access VPN Network 🧚
As mentioned earlier, in the "de facto" Internet address architecture, only the nodes on the public Internet have globally unique IP addresses assigned by the official IP address registries. A lot of networks at the edges use private IP addresses from RFC 1918 and NAT devices to connect their private networks to the public Internet. Many enterprises adopted the approach of using private IP addresses internally. Employees on the enterprise's intranet private network are "trusted" and can connect to any of the internal hosts with minimal administrative or policy enforcement overhead. When an employee leaves the enterprise premises, remote access VPN gives the remote user the same level of intranet connectivity 🔑
The goal of this section is to give you an overview of how a remote access VPN application works operationally, so you can appreciate the problem of remote address space overlap. This is not a tutorial or a specification of remote access VPN products, per se. Just the vibes, not the product manual 📖
When an employee at a remote site launches their remote access VPN client, the VPN server at the corporate premises asks the VPN client to authenticate itself. Once authentication succeeds, the VPN server assigns a Virtual IP (VIP) address to the client so it can connect to the corporate intranet. From that point on, while the VPN is active, outgoing IP packets headed for hosts in the corporate intranet are tunneled through the VPN. The VPN server acts as the next-hop, and the VPN connection acts as the next-hop link for those packets. Inside the corporate intranet, the outbound IP packets appear to be arriving from the VIP address. So IP packets from corporate hosts to the remote user get sent to the remote user's VIP address, and they're tunneled inbound to the remote user's PC through the VPN tunnel 🚇
This works beautifully as long as the subnets in the corporate network don't conflict with the subnets at the remote site where the remote user's PC is located. But when the corporate network is built using RFC 1918 private address space, and the remote location where the VPN client is launched is also using an overlapping network from RFC 1918 address space, addressing conflicts can happen. The remote user's PC will have a conflict when it tries to reach nodes at the corporate site and nodes at the remote site that bear the same IP address at the same time 😵💫 As a result, the VPN client may be unable to have full access to the employee's corporate network and the local network at the remote site simultaneously.
Despite the address overlap, remote access VPN clients should still be able to successfully establish connections with intranet hosts in the enterprise 💖
4.2. Anomalies of the Remote Access VPNs 🦄
Conventional wisdom says that a remote access VPN scenario with overlapping address space should be seriously broken, but in practice it still works in a lot of ways 🤷♀️ Let's look at some anomalies where there might be a problem, and figure out solutions that let the remote access VPN application work even in those problem situations. Let's gooo 🚀
4.2.1. Remote Router and DHCP Server Address Conflict ✨
Okay so routing and DHCP are the bootstrap services 💖, and the remote host literally can't start a VPN without them. No DHCP lease means the host can't talk on the IP network at all 😭. No router means it can't get past its local subnet to reach the VPN server at the enterprise. So neither of these can get messed with at the remote host, or the VPN connection won't stay operational 🫶. Usually a plug-and-play NAT device at the remote site handles both routing and DHCP from the same IP address 🎀.
When the enterprise intranet and the remote site have overlapping addresses, the remote VPN user is often clueless about the conflict 🙈. That overlap could cut them off from the enterprise completely, or from some random chunk of enterprise hosts 💀.
Say the IP address of the DHCP server at the remote site matches a host at the enterprise. When the remote PC goes to renew its locally assigned address, the VPN client thinks the DHCP renewal is meant for an enterprise host and tunnels it over the VPN to the remote VPN server 😤. Those renewal requests never reach the DHCP server at the remote site. Eventually the PC loses its lease on the IP address, and the VPN connection to the enterprise breaks 💔.
Now say the IP address of the remote user's router overlaps with a host in the enterprise network. If the PC sends a ping or periodic keep-alive packets to the router to check it's still alive 🔍, the VPN client grabs them and redirects them into the tunnel. That's a double whammy 🙃: critical packets meant for the router get hijacked, and the enterprise host with the same IP gets bombarded with keep-alives it never asked for. Losing connectivity to the router can break the VPN connection too.
Clearly, traffic aimed at the local router or DHCP server should not be redirected to the corporate intranet 🙅. A VPN client on a remote PC should be configured so that IP packets whose target IP address matches any of the following are disallowed to be redirected over the VPN:
- a) IP address of the VPN client's next-hop router, used to access the VPN server.
- b) IP address of the DHCP server, providing address lease on the remote host network interface.
Recommendation-2: A VPN client on a remote PC should be configured such that IP packets whose target IP address matches any of (a) or (b) are disallowed to be redirected over the VPN:
- a) IP address of the VPN client's next-hop router, used to access the VPN server.
- b) IP address of the DHCP server, providing address lease on the remote host network interface.
4.2.2. Simultaneous Connectivity Conflict 🧁
Ideally, the corporate intranet shouldn't conflict with any of the hosts at the remote site 🌸. As a general practice, if simultaneous communication with end hosts at the remote location matters to you, it's advisable to disallow access to any corporate network resource that overlaps the client's subnet at the remote site ✨. Then the remote user can connect to all local hosts at the same time while the VPN connection is active.
Some VPN clients let the remote PC reach the corporate network over VPN while all other subnets are accessed directly, without going through the VPN. That's called a "Split VPN" configuration 💅. It lets apps talk to hosts at the remote site, the public Internet, and the corporate intranet, unless there's address overlap with the remote subnet. Apps reaching hosts at the remote site or the public Internet skip the VPN, so they're likely to perform better than they would if they went through it 🚀. That's a big deal for latency-sensitive stuff like Voice over IP (VoIP) and interactive gaming 🎮. If there's no overriding security concern with directly accessing hosts at the remote site or the public Internet, the VPN client on the remote PC should be configured in "Split VPN" mode 🦋.
If simultaneous connectivity to hosts at the remote site isn't important, the VPN client can be set to send all of the remote user's communication traffic into the VPN. That's a "Non-Split VPN" configuration 🔒. Everything from the remote user's PC traverses the VPN link and is routed through the VPN server, except traffic aimed at the router and DHCP server at the remote site. No other communication happens with hosts at the remote site. Apps needing the public Internet also go through the VPN. If the goal is to maximize the security and reliability of connectivity to the corporate network, the VPN client on the remote PC should be configured in "Non-Split VPN" mode 🛡️. That setup will minimize the likelihood of losing access to corporate hosts.
Recommendation-3: A VPN client on a remote PC should be configured in "Non-Split VPN" mode if the deployment goal is (a), or in "Split VPN" mode if the deployment goal is (b):
- a) If the goal is to maximize the security and reliability of connectivity to the corporate network, the VPN client on the remote PC should be configured in "Non-Split VPN" mode. "Non-Split VPN" mode ensures that the VPN client directs all traffic from the remote user to the VPN server (at the corporate site), with the exception of traffic directed to the router and DHCP server at the remote site.
- b) If there is no overriding security concern to directly accessing hosts at the remote site or the public Internet, the VPN client on the remote PC should be configured in "Split VPN" mode. "Split VPN" mode ensures that only the corporate traffic is directed over the VPN. All other traffic does not have the overhead of traversing the VPN.
4.2.3. VIP Address Conflict 😬
When the VIP address assigned to the VPN client at the remote site directly conflicts with the IP address of an existing network interface, the VPN client might be unable to establish the VPN connection 💔.
Picture this: the VIP address assigned by the VPN server exactly matches the IP address of the networking interface at the remote site. When the VPN client on the remote host tries to set the VIP address on a virtual adapter (the one specific to the remote access application), that configuration just fails because of the conflict with the existing network interface 🙃. That failure can mean the remote access VPN tunnel never gets established.
Clearly, it's not advisable to have the VIP address overlap the IP address of the remote user's existing network interface 🚫. As a general rule, it's not advisable for the VIP address to overlap any IP address in the remote user's local subnet either. The VPN client on the remote PC might be forced to respond to ARP requests on the remote site, and it might not handle those ARP requests gracefully 🙈.
Some VPN vendors offer provisions to detect conflicts between VIP addresses and the address space at the remote site, and to switch between two or more address pools with different subnets so the VIP address isn't in conflict with the remote site 🔁. Enterprises deploying VPNs that support this vendor provisioning are advised to configure the VPN server with a minimum of two distinct IP address pools. However, this isn't universally the case 🤷.
Alternately, enterprises may deploy two or more VPN servers with different address pools 🌈. That way, a VPN client that detects a VIP conflict with the subnet at the remote site can switch to an alternate VPN server that won't conflict.
Recommendation-4: Enterprises deploying remote access VPN solutions are advised to adapt a strategy of (a) or (b) to avoid VIP address conflict with the subnet at the remote site.
- a) If the VPN server being deployed has been provisioned to configure two or more address pools, configure the VPN server with a minimum of two distinct IP address pools.
- b) Deploy two or more VPN servers with distinct IP address pools. By doing so, a VPN client that detects conflicts of VIP addresses with the subnet at the remote site will have the ability to switch to an alternate VPN server that will not conflict.
4.2.4. Mistaken End Host Identity 😱
When "Split VPN" is configured on the VPN client on a remote PC, there's a potential security threat from mistaken identity 🫣. Say a service, like SMTP mail, is configured on exactly the same IP address at both the corporate site and the remote site. The user could be using the remote site's version of that service without knowing it, which violates the integrity and confidentiality of that application's content 💀. Remote user mail messages could potentially get hijacked by the ISP's mail server.
Enterprises deploying remote access VPN servers should allocate global IP addresses for the critical servers the remote VPN clients typically need to access 🌍. Even if most of the private corporate network uses RFC 1918 address space, this makes sure the remote VPN clients can always reach those critical servers, no matter what private address space is used at the remote attachment point 🧩. This is akin to Recommendation-1, which goes along with multi-level NAT deployments.
Recommendation-5: When "Split VPN" is configured on a VPN client of a remote PC, enterprises deploying remote access VPN servers are advised to assign global IP addresses for the critical servers the remote VPN clients are likely to access.
5. Summary of Recommendations ✨
Okay bestie, NAT vendors, go check the BEHAVE docs ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]) for the full list of conformance requirements for NAT devices. That's the complete list, so don't skip it 💅
Here's the recap of the recs for the weird NAT topologies we covered earlier. These are deployment-specific and aimed at the people actually running the networks, like ISP admins and enterprise IT folks 🫶
Recommendation-1: ISPs using NAT devices to give customers connectivity should give servers advertised to customers non-overlapping addresses. One way to do that is to give advertised servers global addresses 🌍
Recommendation-2: A VPN client on a remote PC should be set up so that IP packets whose target IP address matches any of (a) or (b) are not allowed to be redirected over the VPN 🚫
- a) The IP address of the VPN client's next-hop router, which is used to reach the VPN server.
- b) The IP address of the DHCP server that gives the remote host's network interface its address lease.
Recommendation-3: A VPN client on a remote PC should be set to "Non-Split VPN" mode if the goal is (a), or "Split VPN" mode if the goal is (b) 🎀
- a) If the goal is to maximize the security and reliability of connecting to the corporate network, use "Non-Split VPN" mode. This makes the VPN client send all traffic from the remote user to the VPN server at the corporate site, except traffic going to the router and DHCP server at the remote site 🔒
- b) If there's no big security concern about directly reaching hosts at the remote site or the public Internet, use "Split VPN" mode. This makes only corporate traffic go over the VPN, so everything else skips the VPN overhead ⚡
Recommendation-4: Enterprises deploying remote access VPN solutions should use strategy (a) or (b) to avoid a VIP address conflict with the subnet at the remote site 🧚
- a) If the VPN server has been provisioned to configure two or more address pools, configure it with a minimum of two distinct IP address pools.
- b) Deploy two or more VPN servers with distinct IP address pools. That way, a VPN client that detects a VIP address conflict with the subnet at the remote site can switch to an alternate VPN server that won't conflict 🦋
Recommendation-5: When "Split VPN" is configured on a remote PC's VPN client, enterprises deploying remote access VPN servers should give global IP addresses to the critical servers the remote VPN clients are likely to access 🌸
6. Security Considerations 🔐
Okay, so this document doesn't inherently create new security issues 🙌 But security issues known to DHCP servers and NAT devices still apply, they're just outside the scope of this doc. Same deal with remote access VPN devices: their security issues apply to the remote access VPN topology too, but we're not covering them here. The security issues we review are only the ones relevant to the topologies in Sections 2 and 3, specifically how they relate to private address space overlap in those topologies 💀
Mistaken end host identity is a security concern in both topologies we talked about. It's described in Sections 2.2.4 and 3.2.4 for each topology. Basically, it means application services can get hijacked by the wrong application server, like a mail server 😭 The security violation mostly happens because critical servers are given RFC 1918 private addresses. For both scenarios, the suggested fix is to give critical servers globally unique public IP addresses 🌍✨
Heads up: this is the big one. Mistaken end host identity can let the wrong server take over an application service, so don't leave critical servers on private addresses.
We also recommend in Section 2.1.2 that applications use end-to-end authentication and not depend on the source IP address for authentication. Doing this will stop connection hijacking and denial-of-service attacks 🛡️💖
7. Acknowledgements 🫶
The authors want to thank Dan Wing for reviewing the document in detail and making helpful suggestions about reorganizing the format 🎀 They also want to thank Ralph Droms for helping reword the text and Recommendation-1 in Section 3.2.4, and Cullen Jennings for helping reword the text and Recommendation-3 in Section 4.2.2 💜
8. References 📚
8.1. Normative References
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
[BEH-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP
142, RFC 5382, October 2008.
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.8.2. Informative References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.Authors' Addresses 💌
Pyda Srisuresh
EMC Corporation
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
Bryan Ford
Department of Computer Science
Yale University
51 Prospect St.
New Haven, CT 06511
Phone: +1-203-432-1055
EMail: bryan.ford@yale.edu📦 where this page comes from
- ietf: rfc5684 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms