MX Firewall Settings
This article provides an overview of what traditional and next generation firewalls are, in addition to the configuration and capabilities of the MX Security & SD-WAN Appliance.
The firewall settings page in the Meraki Dashboard is accessible via Security & SD-WAN > Configure > Firewall. On this page you can configure Layer 3 and Layer 7 outbound firewall rules, publicly available WAN appliance services, port forwarding, 1:1 NAT mappings, and 1:Many NAT mappings.
If you are looking for information regarding what firewall rules to put in place for communication between Meraki devices and the Meraki cloud, please reference the article for Firewall Rules for Cloud Connectivity.
Learn more with these free online training courses on the Meraki Learning Hub:
Comparing Next Generation Firewalls to Traditional Firewalls
When selecting a firewall for your network you will encounter a myriad of potential options. Some will be next generation, some will be traditional. Let's take a look at the key differences:
Features
Firewall selection most typically begins with a required feature set. Traditional firewalls have a limited feature set while next generation firewalls have an extended feature set. More details on the difference in features available is provided below.
Performance
When enabling additional features such as client and host tracking; intrusion detection and prevention, and stateful inspection there will be performance impacts. These features require additional resource utilization (memory and CPU) in order to perform the underlying packet scanning which enables these features. Comparing the performance of a next generation firewall to a traditional firewall is not typically possible given the default feature set enabled on each.
Management
A traditional firewall is managed via a CLI or GUI which is hosted on the device. Next generation firewalls typically have Cloud or Controller management capabilities.
What is a traditional firewall?
A traditional firewall will provide basic access control list (ACL) capabilities at layers 3 & 4 in addition to layer 3 routing and flow state tracking capabilities. We should expect for these features to be enabled by default, though the features may not be out of the box configured. Additional configuration capabilities are fairly limited, as many of the foundational features which enable Software Defined Routing (SD-Routing) are not available on traditional firewalls.
Standard Feature List
A standard firewall's default feature set will include functionality such as:
- Stateful or stateless flow tracking
- Standard firewalling capabilities such as:
- Access Control Lists (ACLs) based on layer 3 & layer 4 information
- Network Address Translation (NAT) and Port Address Translation (PAT)
Extended Feature List
- Traffic Shaping
- Rate limiting / policing
- Quality of Service
- DSCP & CoS Honoring / Marking
- Virtual Private Network (VPN)
What is a Next Generation Firewall?
A next-generation firewall (NGFW) is a network security device that provides capabilities beyond a traditional, stateful firewall. While a traditional firewall typically provides stateful inspection of incoming and outgoing network traffic, a next-generation firewall includes additional features like application awareness and control, integrated intrusion prevention, and cloud-delivered threat intelligence. NGFW appliances will also include Software Defined Networking (SDN) capabilities which traditional firewalls cannot achieve without orchestration and use of additional integrations.
The standard feature set of a NGFW is a 'generation ahead' of a that of a default firewall. These standard features are the foundation upon which Software Defined Networking (SDN) and threat protection implementations are built. We should expect for these features to be enabled by default, though the features may not be out of the box configured.
Standard Feature List
A next generation firewall's default feature set will include functionality such as:
- Stateful or stateless flow tracking
- Standard firewalling capabilities such as:
- Access Control Lists (ACLs) based on layer 3 & layer 4 information
- Network Address Translation (NAT) and Port Address Translation (PAT)
- Deep packet inspection (DPI)
- URL Filtering
- Traffic Shaping
- Rate limiting / policing
- Quality of Service (QoS)
- DSCP & CoS Honoring / Marking
- Software Defined WAN (SD-WAN) and SD-Routing decision capabilities
- Client and host tracking (layer 3 - layer 7)
Extended Feature List
Below are a few features which we would typically
- Stateful packet inspection
- Virtual Private Network (VPN)
- Intrusion Detection and Prevention (IPS)
- Malware Protection
Outbound rules
Note: The Layer 3 firewall rules configured on the Firewall page are stateful whilst the Layer 7 rules configured on the Firewall page are stateless.
Note: In NAT/Routed mode, all inbound connections are denied except for ICMP traffic to the appliance, by default. If you want to allow additional inbound traffic, you will need to create a new port forwarding rule or NAT policy and explicitly allow connections based on protocols, ports, or remote IP addresses (see below).
Outbound connections are allowed by default. Customers may need to add a default deny rule for compliance and increased security.
Note: To determine the priority of Layer 3 vs Layer 7 rules, please refer to our article, Layer 3 and 7 Firewall Processing Order.
Here you can configure permit or deny Access Control List (ACL) statements to determine what traffic is allowed between VLANs or out from the LAN to the Internet. These ACL statements can be based on protocol, source IP address and port, and destination IP address and port. These rules do not apply to VPN traffic. To configure firewall rules that affect traffic between VPN peers, please refer to Site-to-site VPN Settings.
Please note that in a Hub-Spoke topology where the spoke is using the Hub as its default route, internet-bound traffic from the Spoke will be subjected to the outbound Layer 3 firewall rules configured on the Hub. For information on Hub-Spoke topology please refer to Configuring Hub-and-spoke VPN Connections on the MX Security Appliance.
Configured firewall rules are flow-based, this means that once a change is made a flow will continue until that flow times out. The newly configured rule will then be applied to subsequent flows to either permit or deny traffic.
Click Add a rule to add a new outbound firewall rule.
- The Policy field determines whether the ACL statement permits or blocks traffic that matches the criteria specified in the statement.
- The Rule description can be used to add additional information or a comment about the rule.
- The Protocol field allows you to specify TCP traffic, UDP traffic, ICMPv4/ICMPv6 traffic, or Any.
- The Sources field support IPs or CIDR subnets. Multiple IPs or subnets can be entered comma-separated. "Any" can also be used to specify all networks. The source IP or CIDR subnet must be from the configured subnets in the MX Addressing & VLANs page. If "Any" is used as as source, it will cover all subnets configured on the MX Addressing & VLANs page.
- Destinations fields support IPs or CIDR subnets. Multiple IPs or subnets can be entered comma-separated. '"Any" can also be used to specify all networks. FQDN and Domain names are also supported as destinations.
- The Src Port and Dst Port fields support port numbers or port ranges. Multiple ports can be entered comma-separated. Port ranges cannot be entered comma-separated.
Template Firewall Rules
Additional options are available when configuring firewall rules on a configuration template. For details, see the Firewall rules for templates section of the Configuration Templates page.
Cellular Failover Rules
These firewall rules are appended to the existing outbound rules when the appliance has failed over to using a cellular modem as its uplink. This can be useful for limiting cellular traffic to only business-critical uses in order to prevent unnecessary cellular overages.
FQDN Support
In MX 13.4 and higher, fully qualified domain names can be configured in the Destination field.
If L3 firewall rules are configured using FQDNs and the MXs firmware version is downgraded to MX 13.3 or earlier, all pieces of the firewall configuration with FQDNs will be removed. Firmware versions below 13.4 do not support FQDNs in L3 firewall rules.
FQDN-based L3 firewall rules are implemented based on snooping DNS traffic. When a client device attempts to access a web resource, the MX will track the DNS requests and response to learn the IP of the web resource returned to the client device.
There are several important considerations for utilizing and testing this configuration:
- The MX must see a client DNS request and the server's response to learn the proper IP mapping. The DNS request doesn't need to be from a specific client, the MX will map the FQDN based on the DNS response, regardless of which client made the DNS Request. The communication between the client and DNS server can be an inter-VLAN or NAT'ed traffic flow, but cannot be intra-VLAN (this DNS traffic is not snooped).
- In some cases, a client device may already have IP information about the web resource it is attempting to access. This could be due to the client having cached a previous DNS response, or a local statically configured DNS entry on the device. The MX may not be able to properly block or allow communications to the web resource in these cases if the client devices do not generate a DNS request for the MX to inspect.
- FQDN rules imply a wildcard when no subdomain is used by prepending a * to the domain.tld. This wildcard is not shown on the Dashboard but is visible in syslog messages if syslog is configured for a network. For example, a rule to permit "yahoo.com" would permit any subdomain under yahoo.com such as mail.yahoo.com. Permitting "mail.yahoo.com" in the rule would only permit mail.yahoo.com and not the TLD or other subdomain of yahoo.com.
MX will not be able to snoop TCP-based or encrypted DNS traffic.
An example configuration is included below:
In order to ensure successful operation, DNS traffic must be allowed by the MXs layer 3 firewalls. Blocking DNS will result in the MX being unable to learn hostname and IP address mappings and, subsequently, from blocking or allowing traffic as expected.
WAN Appliance Services
- ICMP Ping: Use this setting to allow the WAN appliance to reply to inbound ICMP ping requests coming from the specified address(es). Supported values for the remote IP address field include None, Any, or a specific IP range (using CIDR notation). You can also enter multiple IP ranges separated by commas. To add specific IP addresses rather than ranges, use the format X.X.X.X/32.
- Web (local status & configuration): Use this setting to allow or disable access to the local management page (wired.meraki.com) via the WAN IP of the WAN appliance. Supported values for the remote IPs field are the same as for ICMP Ping.
- SNMP: Use this setting to allow SNMP polling of the appliance from the WAN. Supported values for the remote IPs field are the same as for ICMP Ping.
Note: The WAN appliance services configuration section is removed for WAN appliances operating in Passthrough or VPN Concentrator mode. As restrictions for these services will need to be configured on upstream network equipment.
Layer 7 Firewall Rules
Using Meraki's unique layer 7 traffic analysis technology, it is possible to create firewall rules to block specific web-based services, websites, or types of websites without having to specify IP addresses or port ranges. This can be particularly useful when applications or websites use more than one IP address, or when their IP addresses or port ranges are subject to change.
It is possible to block applications by category (e.g. 'All video & music sites') or for a specific type of application within a category (e.g. only iTunes within the 'Video & music' category). The figure below illustrates a set of layer 7 firewall rules that includes both blocking entire categories and blocking specific applications within a category:
It is also possible to block traffic based on HTTP hostname, destination port, remote IP range, and destination IP/port combinations.
Note: The remote IPs cannot be blocked inbound for L2TP VPN or AnyConnect VPN.
Geo-IP Based Firewalling
The Layer 7 Firewall can be used to block traffic based on the destination country of outbound traffic and the source of return traffic.
To do so, create a new Layer 7 Firewall rule and select Countries... from the Application drop-down. You have the option of blocking all traffic to or from a specified set of countries or blocking any traffic that is not to or from a specified set of countries. MaxMind is used for geo-IP based layer 7 rules.
Note: Geo-IP firewall rules are exclusive to physical MX appliances with Advanced Security Edition licenses. This functionality is not supported on Z3 devices or vMX appliances.
Note: When a Geo-IP firewall rule is set to block traffic, it is not possible to allow/exempt specific IP ranges that exist in a country that is blocked.
Note: Geo-IP firewall rules also apply to internally routed traffic. If the subnets configured on the Security & SD-WAN > Configure > Addressing & VLANs page geolocate to a country that is being blocked by a Geo-IP firewall rule, the MX will drop any traffic being sourced from those subnets.
Forwarding rules
Use this area to configure port forwarding rules and 1:1 NAT mappings as desired.
Port forwarding
Use this option to forward traffic destined for the WAN IP of the MX on a specific port to any IP address within a local subnet or VLAN. Click Add a port forwarding rule to create a new port forward. You need to provide the following:
-
Description: A description of the rule.
- Uplink: Listen on the Public IP of Internet 1, Internet 2, or both.
- Protocol: TCP or UDP.
- Public port: Destination port of the traffic that is arriving on the WAN.
- LAN IP: Local IP address to which traffic will be forwarded.
- Local port: Destination port of the forwarded traffic that will be sent from the MX to the specified host on the LAN. If you simply wish to forward the traffic without translating the port, this should be the same as the Public port.
- Allowed remote IPs: Remote IP addresses or ranges that are permitted to access the internal resource via this port forwarding rule.
You can also create a port forwarding rule to forward a range of ports. However, the range configured in the Public port field must be the same length as the range configured in the Local port field. The public ports will be forwarded to their corresponding local ports within the range. For instance, if you forward TCP 223-225 to TCP 628-630, port 223 would be translated to 628, port 224 would be translated to 629, and port 225 would be translated to 630.
1:1 NAT
Use this option to map an IP address on the WAN side of the MX (other than the WAN IP of the MX itself) to a local IP address on your network. Click Add a 1:1 NAT mapping to create a new mapping. You need to provide the following:
- Name: A descriptive name for the rule
- Public IP: The IP address that will be used to access the internal resource from the WAN.
- LAN IP: The IP address of the server or device that hosts the internal resource that you wish to make available on the WAN.
- Uplink: The physical WAN interface on which the traffic will arrive.
- Allowed inbound connections: The ports this mapping will provide access on, and the remote IPs that will be allowed access to the resource. To enable an inbound connection, click Allow more connections and enter the following information:
- Protocol: Choose from TCP, UDP, ICMP ping, or any.
- Ports: Enter the port or port range that will be forwarded to the host on the LAN. You can specify multiple ports or ranges separated by commas.
- Remote IPs: Enter the range of WAN IP addresses that are allowed to make inbound connections on the specified port or port range. You can specify multiple WAN IP ranges separated by commas.
You can move a configured rule up or down in the list using the + icon. Click the X to remove it entirely.
Creating a 1:1 NAT rule does not automatically allow inbound traffic to the public IP listed in the NAT mapping. By default all inbound connections are denied. You will have to configure Allowed inbound connections as described above in order to allow the inbound traffic.
1:Many NAT
1:Many NAT, also known as Port Address Translation (PAT), is more flexible that 1:1 NAT. It allows you to specify one public IP that has multiple forwarding rules for different ports and LAN IPs. To add a 1:Many NAT listener IP, click Add 1:Many IP.
- Public IP: The IP address that will be used to access the internal resource from the WAN.
- Uplink: The physical WAN interface on which the traffic will arrive.
A 1:Many NAT entry will be created with one associated forwarding rule. To add additional rules, click Add a port forwarding rule under the existing rule or rules for a particular 1:Many entry.
-
Description: A description of the rule.
- Protocol: TCP or UDP.
- Public port: Destination port of the traffic that is arriving on the WAN.
- LAN IP: Local IP address to which traffic will be forwarded.
- Local port: Destination port of the forwarded traffic that will be sent from the MX to the specified host on the LAN. If you simply wish to forward the traffic without translating the port, this should be the same as the Public port.
- Allowed remote IPs: Remote IP addresses or ranges that are permitted to access the internal resource via this port forwarding rule.
Bonjour Forwarding
Use this feature to allow Bonjour to work between VLANs. Click Add a Bonjour forwarding rule to create a new forwarding rule.
- Description: Specify a name for the rule.
- Service VLANs: Select one or more VLANs where network services are running. Bonjour requests from the Client VLANs will be forwarded to these VLANs.
- Client VLANs: Select one or more VLANs from which client Bonjour requests can originate. Requests on these VLANs will be forwarded to the Service VLANs. The list of services that can be forwarded include:
- All services
- AirPlay
- Printers
- AFP (Apple file sharing)
- Scanners
- iChat
