LAN 1:1 NAT

The LAN 1:1 NAT feature in flexiWAN facilitates Source and Destination Network Address Translation (SDNAT) specifically tailored for local area network (LAN) interfaces. LAN NAT is a type of NAT in which both the source or destination IP addresses of a packet are changed as it traverses a network. This can be used to rewrite the destination address of incoming packets to direct them to the correct internal device, while simultaneously rewriting the source address to ensure that reply packets are sent back to the correct external device.

Getting started

LAN NAT, or Local Area Network Network Address Translation, is a specific implementation of SDNAT (Source and Destination Network Address Translation) that works exclusively on LAN-based network interfaces. It modifies both the source and destination IP addresses of packets as they traverse through a network, ensuring optimal routing and delivery of data within a LAN environment. By changing both the source and destination addresses, LAN NAT allows for improved flexibility and control in managing internal network traffic, providing an efficient means of routing data packets within a local area network. LAN NAT allows to use the same LAN subnet across devices while using unique NATted address.

Configuration

To configure LAN NAT, navigate to device settings and from the Configuration tab click on Firewall & NAT. From there click on + sign under LAN NAT.

../_images/LANNAT_case_3.PNG

LAN NAT configuration window will open, see below for details of each section.

../_images/LANNAT_case_0.PNG

The window shows two sections, source and destination.

Source

  • Match IP/Mask - used to mark source IP, from where the traffic is originating.

  • Action IP/Mask - once configured, source Match IP will be translated to Action IP.

  • LAN Interface - select interface for this specific rule. Used in case there are multiple LAN interfaces.

Destination

  • Match IP/Mask - used for setting remote / destination IP which source network / client is accessing.

  • Action IP/Mask - actual IP to which the traffic from Match IP translates.

Depending on the use case, configuration of both sections is not obligatory always. In order to understand how LAN NAT feaute is used, two use cases are prepared below:

  1. Rewriting destination IP address

  2. Communication between overlapping LAN range

Use cases

The following use cases are tested and supported by flexiWAN, however many other use cases are possible.

Rewriting destination IP

In a network configuration comprising multiple branch offices (spokes) connected to a central hub, each spoke utilizes an identical LAN IP range of 192.168.130.0/24. The hub operates on a distinct LAN IP range of 192.168.132.0/24, hosting a main server with the actual IP address of 192.168.132.100/32. Spoke LAN clients / devices are configured to communicate with this server via a designated virtual IP address of 200.8.8.1/32. This IP cannot be changed and is hardcoded at the clients, which is common use case in industrial devices, ATMs etc.

For this use case, two devices are prepared with the following networking configuration:

  • Ottawa - Spoke - LAN range 192.168.130.0/24

  • Madrid - Hub - LAN range 192.168.132.0/24

  • Madrid - Server - LAN IP 192.168.132.100/32

  • Hardcoded server IP at Ottawa LAN clients - 200.8.8.1/32

The LAN NAT feature on flexiWAN addresses the challenge of this uniform IP schema across the branches. It allows network administrators to implement rules that match the source IP from the spoke clients with the pre-configured destination IP and seamlessly redirect this traffic to the main server’s actual IP address at the hub. This scenario exemplifies how LAN NAT facilitates communications between similarly addressed LANs across a hub-and-spoke topology without the need for reconfiguration at each endpoint.

To configure this use case, navigate to the Devices page. In this example, Ottawa is spoke site while Madrid is spoke. Click on the Ottawa edge.

../_images/LANNAT_case_1.PNG

From the interfaces page, observe LAN IP and its range of 192.168.130.0/24

../_images/LANNAT_case_2.PNG

Navigate to Configuration > Firewall & NAT. Click on the + sign under LAN NAT rules to add a new rule.

../_images/LANNAT_case_3.PNG

In the following section, configure the IP’s as in screenshot to match the source IP from the spoke clients with destination IP and redirect its traffic to the main server’s actual IP address at the hub, which is in this case 192.168.132.100/32. See below screenshot for more details.

../_images/LANNAT_case_4.PNG

The screenshot above shows the following:

  • LAN Interface: Make sure to select LAN

  • Source - Match IP/Mask: from where traffic will be originating, 192.168.130.0/24.

  • Source - Action IP/Mask: IP range from which the remote hub end will see traffic arriving from, 10.10.11.0/24.

  • Destination - Match IP/Mask: IP which LAN clients have hardcoded to access resources from, 200.8.8.1/32

  • Destination - Action IP/Mask: Actual IP to which the matched IP will be translated to, 192.168.132.100/32

Confirm everything is correctly configured.

../_images/LANNAT_case_5.PNG

Now its time to test the configuration. From the LAN client, attempt to access the remote server resource using its IP 200.8.8.1. As screenshot shows, remote IP is responding.

../_images/LANNAT_case_6.PNG

On the other end, running tcpdump on LAN client of IP 192.168.132.100 confirms traffic from spoke is arriving and from its IP 10.10.11.100. This IP range was set in the LAN NAT rule configuration.

../_images/LANNAT_case_7.PNG

Communication between overlapping LAN ranges

In this scenario, multiple flexiEdge locations are established in a full mesh topology, each with LANs configured identically using the IP range of 192.168.130.0/24. Given that flexiWAN employs OSPF for network routes propagation between sites, direct communication between LAN clients with duplicate IP ranges is not possible out-of-the-box. This use case demonstrates how the LAN NAT feature resolves this challenge by enabling configurations that facilitate inter-site communication, despite the identical LAN configurations. Through LAN NAT, source traffic from these overlapping networks is selectively matched and rerouted to a unique range, ensuring seamless connectivity across the meshed network.

For this use case, two devices are prepared with the following networking configuration:

  • Ottawa - LAN IP 192.168.130.10/24

  • Madrid - LAN IP 192.168.130.20/24

  • Both devices have DHCP server enabled serving IP’s from the set LAN range.

  • LAN client is connected at each end. Both LAN clients have an IP 192.168.130.100/32

The aim is to establish communication across multiple sites with identical LAN IP ranges, including cases where the same LAN client IP addresses are in use. To achive this, each site will configure transit IP range

  • Ottawa - 10.10.11.0/24

  • Madrid - 10.10.10.0/24

For this configuration, proceed to the Devices page, select the settings for the Ottawa device. From the Configuration tab, access Firewall & NAT and hit the plus (+) icon in the LAN NAT section. As seen in the screenshot below, the ‘Match IP’ is set as 192.168.130.0/24 and the ‘Action IP’ as 10.10.11.0/24, indicating that outgoing traffic from the 192.168.130.0/24 network will be converted to the 10.10.11.0/24 network.

../_images/LANNAT_case2_1.PNG

After setting up LAN NAT on the initial device, it’s crucial to carry out the same steps for the corresponding device at the other location, here referred to as the Madrid device. Go to its Firewall & NAT settings and establish a new LAN NAT rule. In the provided screenshot, the source ‘Match’ is again 192.168.130.0/24, similar to the first device. However, the ‘Action IP’ differs; on the Madrid device, it’s assigned to the 10.10.10.0/24 network.

../_images/LANNAT_case2_2.PNG

Once both edges are configured, its time to test the configured rules. The following points are important to note:

  • The action IP’s on both edges will be used for inter-edge communication, instead of their actual IP’s from 192.168.130.0/24 range.

  • LAN client from Ottawa edge has an IP of 192.168.130.100, so LAN client from Madrid site must use 10.10.11.100 to reach it.

  • LAN client from Madrid edge has an IP of 192.168.130.100, so LAN client from Ottawa edge must use 10.10.10.100 to reach it.

To test the configuration, the following screenshot shows a ping response of Madrid LAN client. Ottawa LAN client is pinging 10.10.10.100 which is then translated to remote IP of 192.168.130.100.

../_images/LANNAT_case2_client1.PNG

tcpdump output on Madrid LAN client confirms traffic received from action IP of Ottawa LAN client 10.10.11.100.

../_images/LANNAT_case2_client2.PNG