Skip to main content
Cisco Meraki Documentation

MX Firewall Settings

This article in regards to the various firewall configuration options and capabilities of the MX 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.

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 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.

Outbound rules

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.
     

Outbound.png

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.

Cellular.png

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:

  1. 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 cannot be intra-VLAN (this DNS traffic is not snooped).
  2. 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.
  3. 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:

FQDN.png

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.

 

Additionally, hostname visibility should be enabled on the network for the FQDN-based firewall rules to take effect correctly.

 

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.

Security_Appliance_Services.png

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:

L7_Rules.png

It is also possible to block traffic based on HTTP hostname, destination port, remote IP range, and destination IP/port combinations.

Geo-IP Based Firewalling

The Layer 7 Firewall can also be used to block traffic based on the source country of inbound traffic or the destination country of outbound 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 available only in the Advanced Security Edition.

Note: When a Geo-IP firewall rule is set to block traffic, it is not possible to whitelist/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.

L7_Countries.png

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.

Port_Forwarding.png

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.

Screen Shot 2022-11-16 at 9.37.56 AM.png

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.

1_to_many_NAT.png

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

Bonjour.png