SD-WAN and Migration Challenges: Merging Networks with Identical Address Space

Disclaimer

I work at a service company, and in my work, we often use Russian SD-WAN solutions. We perform large and non-standard deployments, as well as provide networks on a "subscription model," including SD-WAN. Although the SD-WAN concept itself and the main architectures were described many years ago, the real application of the technology is only gaining momentum.

In this article, I want to share a method for configuring NAT on CPE (Customer Premises Equipment) from Kaspersky SD-WAN, which will be useful when connecting networks with overlapping address ranges. Over two years of work, we have accumulated a fairly large and interesting experience with the SD-WAN implementation of this vendor. In this article, you will not find a discussion of SD-WAN technology as a whole, comparisons of different vendors' solutions, the advantages and disadvantages of the service, nor which solution is the "real" SD-WAN and which is just an optimization for internet access. This may be the subject of future articles. Here, I will focus solely on the technical details of configuration.

What will be discussed

Today, we will try to make what seems like an impossible configuration – namely, connecting networks with fully overlapping and even identical address spaces using the Kaspersky SD-WAN solution. Seamlessly merging networks from different organizations and departments has always been a challenging task for network architects and engineers.

On our setup, we have two identical networks of two companies with the address range 192.162.3.0/24, which need to be connected. For demonstration purposes, we have deployed three computers with various popular services:

• VM-WINSRV (Web Server, RDP)

• VM-LAMP (Web Server, SSH)

• VM-CLIENT (RDP)

Note that VM-LAMP and VM-CLIENT have completely identical IP addresses and even network configurations (mask, gateway, DNS server).

Our schematic is shown in the figure:

To accomplish this task, we first come up with alias addresses for our computers, otherwise the "trick" won't work, and the computers will connect to themselves, and packets won't be able to leave the "native" network. The table shows the alias addresses for each of the devices:

The alias addresses are taken "almost randomly" with a 32-bit mask. The 32-bit mask will minimize the chance of entering any working range on the internet or another network. You can use, for example, RFC 1918 ranges, but the most important condition is that the alias must be unique and not overlap with addresses that the computer interacts with.

Inside Kaspersky SD-WAN lies the classic iptables. If you are familiar with this tool, many configuration parameters will be more understandable for you. SNAT – Source Network Address Translation – is a mechanism in which the sender’s address in a packet passing through a router is changed (postrouting chain). DNAT – Destination Address Translation – here the recipient’s address is changed (prerouting chain).

For ease of understanding, I will first present the NAT configuration in the direction from VM-CLIENT to Company 1’s computers, and then from Company 1’s network to the VM-CLIENT computer.

The following diagram shows the concept of configuring SNAT and DNAT on the Kaspersky SD-WAN CPE used in this article:

In outgoing packets from VM-CLIENT, the sender address (SRC) must be replaced with 11.0.2.236 when exiting the CPE ICL-KESR1-02. When passing through CPE ICL-HABR-DEMO-YANDEX-01, the alias address must be replaced with the real address. The replacement takes place on two devices, and the substituted addresses are shown in the diagram above.

Let’s start configuring

We begin by setting up alias addresses. Kaspersky SD-WAN does not allow you to directly set an alias on interfaces, so we use a trick—configure VRRP. Choose a unique VRID, set the Master role, and define the alias address (VIP):

In fact, ICL-KESR1-02-B will always play the master role, but we do not need VRRP itself, just the result. Under the hood, we will see an additional address in the form of the so-called alias:

We do the same for ICL-HABR-DEMO-YANDEX-01:

Only in this case, we need to add two aliases, for VM-LAMP and VM-WINSRV. Result:

Since in my example an address with a 32-bit mask is used, it is also necessary to configure the routing table. When using a 24-bit mask for alias addresses in VRRP and with the CPE in the same overlay network, you could dispense with configuring routes.

The Gateway 192.168.1.4 is the address of CPE ICL-HABR-DEMO-YANDEX-01, and 192.168.1.221 is the address of ICL-KESR1-02-B in the overlay network.

Now let’s configure SNAT on ICL-KESR1-02-B:

More specifically, the content of the line:

In all outgoing packets from VM-CLIENT to address 11.0.0.0/24, we change the source address to the alias. Otherwise, if the real address is kept, the recipient will not be able to send a reply, since it is an address from the recipient’s own network. Then the packet in this form will be sent to CPE ICL-HABR-DEMO-YANDEX-01, where another type of translation will occur – DNAT.

We configure DNAT on ICL-HABR-DEMO-YANDEX-01:

And more specifically the first line:

For variety of examples, DNAT is configured differently for VM-LAMP and for VM-WINSRV. For the first host, we process only TCP/80 and TCP/22. For the second (VM-WINSRV) we do not specify ports and protocol, allowing all protocols encapsulated in IP.

Now let’s configure an example with traffic from Company 1’s computers to Company 2’s (VM-CLIENT) computer.

Here we allow computers of “Company 1” to connect to VM-CLIENT. As a demonstration of configuration options, this time I am not using alias addresses to substitute the sender’s address. Instead, I am using the overlay interface address (192.168.1.4).

SNAT configuration for ICL-HABR-DEMO-YANDEX-01:

In the previous example, we only configured DNAT in this tab.

DNAT configuration for ICL-KESR1-02-B:

In the previous example, we only configured SNAT in this tab, now I am showing the DNAT tab.

Instead of a conclusion

So, I have shown several ways to connect two “identical” networks using NAT configured in the Kaspersky SD-WAN management interface. Such tasks are regularly encountered in the work of network engineers, and it’s always convenient when the chosen solution allows configuration to be done quickly and clearly.

In conclusion, I would also like to note some limitations:

• limitations in the number of VRIDs in a single network (1–255). If VRIDs are repeated on different CPEs, we will see errors in the logs. In practice, we have not yet reached this limit;

• ALG is not supported. As of today, NAT and Firewall operation does not work at Layer 7. I don’t think it’s necessary. However, for those expecting more accurate Layer 7 translation, there is bad news;

• when working with firewalls, you should not forget about ICMP type 3 code 4. In the first tunnel ICMP is not allowed, therefore the PMTU mechanism cannot work.

Without such packets, two devices cannot negotiate the correct MTU. If your MTU across the network is 1500, then there is no problem, but if you encounter a segment with a reduced MTU, as in my example, there will be a connectivity issue.

Unfortunately, it is not possible to create a separate filter on SNAT/DNAT only for ICMP Type 3 Code 4; you will have to allow all IP and block selectively in the firewall. Kaspersky SD-WAN correctly processes responses, and PMTU works correctly if allowed, but I note that for complex cases the solution includes a “MSSclamptoPMTU” mechanism that can help solve the problem – but that again is a topic for another article.