Meraki NAT Exceptions and Inbound Firewall

This blog post focuses on 2 Meraki MX beta features, NAT Exceptions and Inbound Firewall. We will explain how to enable and configure them in your environment. The purpose is to provide extra means for you as a network or security technician to achieve smooth transition from other Cisco or third party firewalls to full-stack Meraki. 

Nat Exceptions (Beta)

Nat Exception or "No-NAT" is a feature designed for situations where you want certain traffic to bypass Network Address Translation on an MX security appliance. This is particularly useful when you have traffic that needs to maintain the original source IP address for proper routing or functionality, such as in a site-to-site VPN or MPLS topology. The NAT Exception allows specific internal IPs to send traffic without undergoing NAT, preserving the original source IP address. NAT is applied by default for traffic from LAN to WAN on an MX, but is disabled for traffic routed on the LAN side of the firewall (e.g. MPLS) or for Auto-VPN traffic.

Prerequisite

Meraki support needs to be contacted via phone to enable this feature. 

Configuration

After Meraki support has enabled the feature on your network, you can configure it by following these steps. Check Figure 1 for more details. 

• Navigate to Security & SD-WAN > Addressing and VLANs.
• At the bottom of the page you will find NAT Exceptions
• Choose the uplink where you want to disable NAT
• Choose if you want to Override NAT per VLAN, in case you have several VLANs
• Override the NAT Config per VLAN if it has to be different based on the uplink

Fig 1. Example of Nat Exception configuration

Note

Remember that exempting NAT will affect all traffic going out through the specific uplink, which could potentially disrupt internet traffic for all your internal networks. 

Inbound Firewall (Beta)

The Inbound Firewall feature provides extra flexibility for your Meraki MX security appliance. This feature allows you to specify which inbound connections from the WAN to the LAN are permitted. The default behavior in an MX WAN is to allow returning LAN traffic (established) and any traffic which has been forwarded via NAT rules. The rest is blocked by default. Inbound Firewall rules are particularly useful when you want to limit the incoming traffic to specific IP addresses and/or ports, providing a higher level of granularity for your specific needs. 

Prerequisite

Same as with NAT Exceptions, Meraki support needs to be contacted via phone to enable the feature. 

Configuration

Navigate to Security & SD-WAN > Firewall. 

Two new sections for Layer 3 Inbound Rules and Inbound cellular failover rules have been added to the configuration. 

The configuration is pretty straight forward. 

• Policy: Allow or Deny
• Description: Provide a description of the rule.
• Protocol: TCP/UDP/ICMPv4/v6 or Any
• Source IP/Network
• Source Port
• Destination IP/Network
• Destination Port

Fig 2. Example of Inbound Firewall configuration

A few notes

The rules are limited to inbound traffic from WAN/Cellular in their respective sections. This can not be used for traffic between vlans or routed on the inner side of the firewall. In that case, outbound rules must be used. 

After enabling Inbound Firewall, all inbound traffic through the WAN/Cellular is allowed by default, so it's crucial to implement layer 3 firewall rules immediately to prevent potential security breaches. Warnings appear on both the Inbound Firewall and Security Appliance sections. 

Warning: Cisco Meraki Support has enabled the use of custom layer 3 inbound firewall rules which defaults to "allow all" behavior unless configured otherwise. Settings previously designated under "Security appliance services" should be configured as explicit firewall rules (e.g. adding a rule to block TCP over port 80 to restrict access to the local status page). We recommend that you configure layer 3 inbound rules to whitelist authorized network routes and append a "deny all" rule to avoid exposing Meraki host services.

Security Appliance Services: Normally, these fields control what services are available from remote IPs, e.g., ICMP ping, web (local status & configuration), and SNMP. However, because Cisco Meraki Support has enabled the use of custom layer 3 inbound firewall rules on this network, remote access to security appliance services will be restricted according to the layer 3 inbound rules configured above.

Use Cases

Depending on your current scenario and problem you are trying to solve, it can be handy to have some extra enterprise features like NAT Exception and Inbound Firewall in a Meraki MX. While the MX appliance running in Routed(NAT) mode is often associated with edge or WAN-side functionality (including acting as an Internet gateway, providing VPN functionality, and serving as a firewall), it can also be effectively used within the LAN for purposes like network segmentation. It can enforce security policies and control access between different VLANs or network segments, effectively acting as an internal firewall. This combined with IDS/IPS, Advanced Malware Protection and URL filtering will block the attacks very close to the source. 

Is this supported?

Since these are beta features, there is some risk for them to be unstable. The NAT Exceptions appeared already back in the beta version 15.4, so it has been there for a while.Several scenarios have been tested in my lab environment and no unexpected results have been encountered. Meraki supports by default the most recent Beta releases of their software as well as older versions with best effort.

Conclusions

While the Nat Exceptions and Inbound Firewall features offer greater flexibility and control, they can potentially expose your internal resources or disrupt your services if not configured properly. Always plan and assess your network needs carefully, considering both functionality and security when you decide. 

References

General MX Best Practices

MX and MS Basic Recommended Layer 3 Topology - Cisco Meraki

Read More