Posts
Meraki Source NAT and IP Aliases Features: An Overview
This post provides a look into Meraki's NAT for inter-vlan traffic. There have been some rumors in the forums discussing this feature, but since it's still a hidden/beta feature, there is no documentation available, which is why I decided to write about it.
What is Source NAT? (Beta)
In simple terms, Source NAT is a mechanism that modifies the source IP address of traffic as it moves between domains, whether it's between LAN and WAN, VLANs or VPN sites. This is particularly beneficial in environments where there's a need to mask the original source or destination IP address of a device in one domain when communicating with devices in a different domain.
What is IP Alias? (Beta)
I like the fact that Meraki has decided to call this IP Aliases, as it's basically destination NAT combined with Proxy ARP. Our traffic would be destined to an IP within our current VLAN, which is not in use, and the Meraki firewall will translate the destination to an IP in another VLAN. The MX will respond to ARP requests as if the IP was assigned to it (Proxy ARP).
Activating the Features
Since they're beta features, both inter-VLAN Source NAT and IP Alias aren't immediately accessible. To enable them, you need to:
- Contact Meraki Support.
- Express interest in the beta feature and explain the specific scenario you are willing to solve.
- Wait for it to be activated on your dashboard.
Remember, beta features are still under testing, so ensure you have proper backups and testing procedures before implementing them in production environments.
Configuring Source NAT and IP Alias on Meraki
Once the features are activated, the configuration is quite straightforward:
- Navigate to the Meraki Dashboard: Log in and choose the network you want to configure.
- Go to the Security & SD-WAN -> Addressing & VLANs and choose the specific VLAN, in our previous example we would choose the red VLAN.
- Hit Next on the first 2 screens related to generic VLAN config and IPv4 config, and you will reach the section on figure 2.
- Enable Source NAT traffic and pick the Source NAT VLAN.
- You have the possibility to enable IP aliases, which requires a source and destination IP. Even though it's called source, it's actually the destination as seen from the host that initiated the traffic. The Destination IP is the IP in the target VLAN we aim to direct traffic towards.
- Save and Test: After configuring, save the changes and start testing to ensure that the NAT is functioning as expected.
Here comes an example configuration:
Fig.1 Source NAT and IP aliases configuration
Use cases
The most traditional use of Source NAT is when translating our private IP's to a single public IP, in order for us to be able to reach the internet. Another scenario would be in translating our traffic as it goes through a VPN, to avoid duplicate IP's between the 2 parties, or just to comply with the addressing schemes. A less traditional use would be to translate the source traffic between 2 networks in our environment. It's this last scenario that we are interested in.
Let's consider 2 VLAN's in our domain, where one is using the MX as gateway, while the other one is using a third party firewall, according to the following diagram. The Meraki MX has the blue and the red VLANs directly attached. Traffic going from the blue VLAN towards a device in the red VLAN, would reach the destination without issues, however return traffic would be sent to the third party firewall, instead of the MX, since the gateway for the blue VLAN is pointing to that one. The third party firewall would have the job to return the traffic back to us. For this to work, we would need a static route with destination the blue VLAN using the MX as next hop. Let's suppose that we don't control this firewall, so we can't configure the static route.
Fig 1. Traffic with and without Source NAT on the MX
In this case we could use Source NAT. We would translate the source of the traffic to be the MX IP on the red VLAN. When traffic would reach the devices on the red VLAN, it would think that we reside within the same VLAN, so it would send the traffic back to the MX, instead of it's gateway, the third party firewall. Now let's discuss how we do this on an MX firewall.
IP Aliases on the other hand are used to hide the destination of the traffic. Instead of sending traffic directly to the destination, we would send it to a local IP within our own VLAN. Our MX would use proxy ARP to respond to the initiator of the traffic, as if this IP was assigned to a local interface. The MX would then translate this further to the destination VLAN/IP. You can see a simplified illustration in the Fig.2 below.
Fig 2. Traffic sent to the IP alias on the Blue VLAN
What are the benefits?
In most cases, you would want to avoid using Source NAT or IP aliases in the internal domain, since it will hide some of the traffic as seen from the source or the destination. This might pose some security concerns, as logs might not record the original IPs. We might not be able to track the actual source and destination, which might as well be an internal threat. It could still be used in some scenarios though:
Privacy and Security: In environments where device anonymity is crucial, such as in labs or testing facilities, masking the original IP can add another layer of security. This would provide privacy as well as security by obscurity to some extent.
Network Migrations: When migrating from a firewall configured with source NAT between VLANs, we might want to do a one to one replacement and introduce changes in a later moment. In this case, it can be handy to have all features supported.
Conclusion
MX firewalls are great for edge use, but they are not widely used in the internal domain for internal segmentation purposes. By introducing more features similar to the ones supported on ASA, Secure Firewall and other third party firewalls, we will see MX eventually become an Internal Segmentation Firewall. While these features are still in beta, the results seem promising. While source NAT and IP aliases might not be a great idea for most scenarios, it can still be used to provide security by obscurity or to ease migrations from firewalls that already support these features.
.jpg)
