Inbound Cellular Firewall Rules Configuration
Dashboard Location: Security and SD-WAN > Configure > Firewall > Inbound cellular failover rules
Cellular Failover Traffic Control
Section titled “Cellular Failover Traffic Control”Inbound cellular firewall rules configuration in Meraki appliances provides granular security control for traffic entering the network through cellular uplinks during WAN failover scenarios. This functionality enables administrators to define specific policies for incoming traffic when the appliance switches to a cellular connection due to primary WAN failure, supporting both IPv4 and IPv6 addressing. These rules are essential for maintaining consistent security posture during cellular failover events, ensuring that only authorized traffic is permitted while protecting internal network resources from potential threats that may target cellular-connected networks.
Diagram
Section titled “Diagram”Classes
Section titled “Classes”firewall (meraki.domains.organizations.networks.appliance)
Section titled “firewall (meraki.domains.organizations.networks.appliance)”| Name | Type | Constraint | Mandatory | Default Value |
|---|---|---|---|---|
| inbound_cellular_firewall_rules | List | [inbound_cellular_firewall_rules] | No |
inbound_cellular_firewall_rules (meraki.domains.organizations.networks.appliance.firewall)
Section titled “inbound_cellular_firewall_rules (meraki.domains.organizations.networks.appliance.firewall)”| Name | Type | Constraint | Mandatory | Default Value |
|---|---|---|---|---|
| comment | String | min: 1, max: 127 | No | |
| policy | Choice | allow, deny | Yes | |
| protocol | Choice | any, icmp, icmp6, tcp, udp | Yes | |
| source_port | Any | Integer[min: 0, max: 65535] or String[matches: `(?:[1-9][0-9]3 | [1-5][0-9]4 | 6[0-4][0-9]3 |
| source_cidr | String | Regex: ^(?i:any|(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|(?:[0-9a-fA-F]{1,4}:){1,7}:|(?:[0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|(?:[0-9a-fA-F]{1,4}:){1,5}(?::[0-9a-fA-F]{1,4}){1,2}|(?:[0-9a-fA-F]{1,4}:){1,4}(?::[0-9a-fA-F]{1,4}){1,3}|(?:[0-9a-fA-F]{1,4}:){1,3}(?::[0-9a-fA-F]{1,4}){1,4}|(?:[0-9a-fA-F]{1,4}:){1,2}(?::[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:(?::[0-9a-fA-F]{1,4}){1,6}|:(?::[0-9a-fA-F]{1,4}){1,7}|::)(?:\d{1,3})?|(\d{1,3}\.){3}\d{1,3}(\d{1,2})?|VLAN\((?:[1-9]|[1-9]\d|[1-9]\d{2}|[1-3]\d{3}|40[0-8]\d|409[0-4])\)\.(?:\*|[1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-4])$ | No | |
| destination_port | Any | Integer[min: 0, max: 65535] or String[matches: `(?:[1-9][0-9]3 | [1-5][0-9]4 | 6[0-4][0-9]3 |
| destination_cidr | String | Regex: ^(?i:any|(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|(?:[0-9a-fA-F]{1,4}:){1,7}:|(?:[0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|(?:[0-9a-fA-F]{1,4}:){1,5}(?::[0-9a-fA-F]{1,4}){1,2}|(?:[0-9a-fA-F]{1,4}:){1,4}(?::[0-9a-fA-F]{1,4}){1,3}|(?:[0-9a-fA-F]{1,4}:){1,3}(?::[0-9a-fA-F]{1,4}){1,4}|(?:[0-9a-fA-F]{1,4}:){1,2}(?::[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:(?::[0-9a-fA-F]{1,4}){1,6}|:(?::[0-9a-fA-F]{1,4}){1,7}|::)(?:\d{1,3})?|(\d{1,3}\.){3}\d{1,3}(\d{1,2})?|VLAN\((?:[1-9]|[1-9]\d|[1-9]\d{2}|[1-3]\d{3}|40[0-8]\d|409[0-4])\)\.(?:\*|[1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-4])$ | No | |
| syslog | Boolean | true, false | No |
Examples
Section titled “Examples”Example-1: The example below demonstrates inbound cellular firewall rule configuration.
This configuration implements granular security policies for inbound traffic control during cellular failover scenarios. The rules support traffic management through policy actions (allow/deny), protocol specifications (tcp/udp/icmp/any), source/destination addressing with IPv6 CIDR notation, and port ranges.
This configuration creates three inbound cellular firewall rules for network security enforcement.
The first rule, “Allow https access to the host”, allows HTTPS traffic (TCP port 443) from any source to the IPv6 destination 2001:440:3c4d:15::12/64. The second rule, “Allow TCP traffic between subnets”, allows HTTPS traffic from a specific IPv6 source subnet 2001:211:1111::/48 on port 5677 to the same IPv6 destination on port 443. The third rule, “Block Bad Traffic”, denies UDP traffic on port 1433 from any source to any destination, effectively blocking potentially malicious SQL-related traffic. Optional syslog settings are available to log matched traffic for monitoring and auditing purposes.
meraki: domains: - name: !env domain administrator: name: !env org_admin organizations: - name: !env org networks: - name: !env network_name product_types: - appliance - switch - wireless - camera - sensor - cellularGateway firewall: inbound_cellular_firewall_rules: - comment: "Allow https access to the host" policy: allow protocol: tcp source_cidr: "Any" source_port: "Any" destination_cidr: "2001:440:3c4d:15::12/64" destination_port: "443" # syslog: true - comment: "Allow TCP traffic between subnets" policy: allow protocol: tcp source_cidr: "2001:211:1111::/48" source_port: "5677" destination_cidr: "2001:440:3c4d:15::12/64" destination_port: "443" # syslog: true - comment: "Block Bad Traffic" policy: deny protocol: udp source_port: 1433 source_cidr: Any destination_port: 1433 destination_cidr: Any