airMAX - Firewall Configuration

by Ubiquiti Employee on ‎05-23-2013 06:56 PM - edited on ‎07-31-2013 03:31 PM by Ubiquiti Employee (2,384 Views)

Overview


This article will detail using and configuring a firewall on your network.

 

Using the Firewall


The purpose of a firewall is to allow the admin-user to restrict specific network traffic, therefore, each firewall rule defines a specific type of network packet that will not be sent across the network. The range of reasons one might want to do this is beyond the scope of this article, however, I will describe in detail a complex scenario where I have done so; hopefully others will find something useful therein. My hope is that this scenario, and the various ways in which it utilizes firewall functionality, might serve as an example from which the reader can derive solutions to his/her own requirements.

 

Warning: A certain level of danger is inherent anytime you configure the firewall. It's easily possible to accidentally define a firewall rule that will make the radio inaccessible, which may in turn necessitate visiting that radio, and may even require a factory reset just to regain access to it. Always think any proposed firewall rule all the way through before defining it on a radio. As precautions, be sure to make a configuration backup before changing the firewall, and be prepared for the worst case.

For the simplest of use cases the standard firewall docs are relatively straight forward -- indeed, given an understanding of the firewall concept, the web UI for configuring the firewall is almost intuitive enough to make even those docs unnecessary. Their only shortfall is described by the following note:

 

Key Detail Omitted from AirOS Docs regarding Firewall

AirOS firewall docs do not explicitly state that the "MASK" portions of the source and destination inputs must be specified using CIDR notation, e.g., 192.168.1.0/24 (as opposed to the dotted-quad equivilent 192.168.1.0/255.255.255.0, used by earlier versions of AirOS.) If source or destination refers to a host (rather than a network) you must still specify the correct CIDR mask, which, for a host, is /32. If you fail to do so, the UI will accept your input, but the entry will have no affect, i.e., it will not cause any traffic to be blocked.

Even so, how often are the simplest of use cases highly applicable to the real world of networking? If the networks I have created/altered/maintained are any example, the answer would be, "not very often at all," there always seem to be multiple subnets in the mix, each with connectivity and security requirements. As case in point I offer you the following example network (that actually exists in real life, as well as in this article):

 

Example Network Description

A DOCSIS 2.0 cable modem (8 mbps down, 2 mbps up) connects a Belkin router to the Internet. One of that router's [wired] Ethernet ports connects a Bullet2HP (AP WDS/router mode) to the router's local/internal network (and thus, to the Internet, via NAT.) Another Bullet2HP (station WDS/bridge mode) 3 miles away connects wirelessly to the first -- two sides of a long-distance point-to-point link, essentially a backhaul. The bridge radio's Ethernet port connects to yet another Bullet2 (AP/router mode) and wirelessly connected to that third Bullet2 there are several other CPE radios, of various makes and in various modes. (See diagram below.)


The IP addresses assigned to each device are as follows:

  • Belkin Router
    • WAN IP: [public IP, obtained via DHCP]
    • Gateway: [public IP, obtained via DHCP]
    • LAN IP: 192.168.1.1
    • Local/internal network: 192.168.1.0/24
  • Bullet2HP P2P AP/WDS Router
    • LAN IP [Ethernet port]: 192.168.1.10
    • Gateway: 192.168.1.1
    • WLAN IP: 192.168.4.1
    • Local/internal [wireless] network: 192.168.4.0/24
  • Bullet2HP P2P Station/WDS Bridge
    • IP: 192.168.4.5
    • Gateway: 192.168.4.1
  • Bullet2 AP Router
    • LAN IP [Ethernet port]: 192.168.4.10
    • Gateway: 192.168.4.1
    • WLAN IP: 192.168.5.1
    • Local/internal [wireless] network: 192.168.5.0/24
  • Various CPE radios
    • Each is assigned a static IP in 192.168.5.0/24
    • IPs for dedicated-purpose hosts behind CPE [bridges] are statically assigned
    • Generic hosts behind CPE in bridge mode obtain DHCP-assigned addresses from 192.168.5.1
    • Generic hosts behind CPE in router mode obtain DHCP-assigned addresses from the CPE/router

 

Firewall Requirements

  1. For security reasons, hosts in the 192.168.1.0/24 network need to be inaccessible to any networks/hosts connected via 192.168.1.10 (AP/WDS Router).
  2. Also for security, because it is possible for clients other than the bridge to connect to the AP/WDS Router, networks/hosts beyond the bridge need to be inaccessible to hosts on the 192.168.4.0/24 network
  3. I discovered the need to block ICMP traffic from a router that's behind a certain subscriber's CPE [bridge] to any other hosts, because the traffic it generated was ridiculous.
  4. I did not want any Address Resolution Protocol (ARP) discovery broadcast frames leaking between networks behind any of the CPE.


Before I describe how and where the requirements above are enforced, it's significant to note a misconception that's apparently common: you may encounter posts to Ubiquity forums, or even documentation topics, stating that firewall functionality is not available to radios in bridge mode. Whether this was the case in older versions of AirOS I'm uncertain, but it is definitely not true now. Firewall rules can be used in bridge mode to prevent traffic from being sent across it; logically only traffic that must cross the bridge will be affected (which, by definition, means said traffic must originate in and be destined for hosts within the same subnet.)

Implementation

Requirement #1

This is enforced on the AP/WDS Router, via the following firewall rule:

File:firewall41.png

This rule blocks any traffic originating in 192.168.4.0/24, from reaching any destination host in 192.168.1.0/24. (Apparently the gateway address, 192.168.1.1, is implicitly exempted.) This effectively protects the 192.168.1.0/24 network from any connections originating in WiFi-connected hosts/networks.

Requirement #2

This is enforced on the Station/WDS Bridge, via the following firewall rule:

File:firewall45.png

This rule blocks traffic sent from any host other than 192.168.4.1 in the 192.168.4.0/24 network, to the AP Router, thus preventing any static routes to the 192.168.5.0/24 network (which would necessarily need to specify 192.168.4.10 as gateway.)

Note that none of the rules above explicitly specify 192.168.5.anything. That's because no address in that network is meaningful in the contexts of the AP/WDS Router or the Station/WDS Bridge. 192.168.5.0/24 is defined by another piece of equipment; the two networks are connected because that other piece of equipment has two interfaces, one with an IP in 192.168.4.0/24, and the other in 192.168.5.0/24. But neither AP/WDS Router nor Station/WDS Bridge have any way (or even any reason) to know this, they only see traffic to/from 192.168.4.10. (NAT performed by the other equipment handles the rest.)

Requirement #3

This is enforced on the AP Router, via the following firewall rule:

File:firewall51.png

This rule prevents any ICMP traffic sent by a specific subscriber's router (which had to be assigned a static IP) from reaching any other host on the network. Said router was sending ICMP host redirect frames to any other host that touched it, because it erroneously believed it was closer to the Internet than its gateway. These spurious frames were annoyingly disruptive to other hosts; this rule causes them to be dropped. This rule could've been enforced on the subscriber's CPE, but that would've left hosts on that subscriber's network unable to ping the AP/Router (undesirable any time trouble-shooting might be required.)

Requirement #4

This could only be enforced by each connected CPE. Blocking ARP traffic between connected hosts on the AP Router would effectively break connectivity between those hosts. Conversely, ARP discovery broadcasts originating inside subscriber networks are merely useless in the best case, theoretically disruptive in the worst.

File:firewall5245.png

This rule prevents any ARP discovery broadcasts not sent by the AP Router from crossing the CPE bridge. It does not affect any ARP traffic between hosts within the subscriber's network, it only affects traffic trying to cross the bridge

Note that this requirement could be easily implemented by compelling CPE to use router mode, but in most cases the only host directly connected to CPE is another router. Imposing a redundant layer of NAT seemed excessive so CPE bridges are allowed, as long as ARP discovery broadcasts originating behind them are kept there.


Conclusion

In conclusion it should be noted (as mentioned briefly above) that input validation for firewall configuration entries is practically nil. Use of CIDR notation for masks is suggested by the maximum length of source and destination inputs (which is less than the 31 characters needed by the worst case) but it will allow you to enter a dotted-quad mask that happens to fit. It will also accept IP addresses in networks that are meaningless in the context of the device's network configuration. Rules containing such invalid input have no affect, but you will receive no warning that this is the case.

More, there is nothing to protect you from defining a rule that will make the radio impossible to reach. As case in point, one time I accidentally set a rule on the AP/WDS Router that specified 192.168.4.0/24 as both source and destination! This made it impossible to gain access to the radio via its IP 192.168.4.1 (and also broke the Internet link between it and the Station/WDS Bridge as well.) The mistake would've cost me a trip to that radio, but luckily I was still able to reach it via its other IP 192.168.1.10.

So be careful, think twice, apply once, and never leave yourself in a position where the need for a factory reset would be impractical, if the worst occurs.

File:netdiagram.png

Contributors
FCC Compliance Information
For information on compliance with FCC rules and requirements, please read this: FCC Compliance Information
Disclaimer
The articles in the knowledge base are voluntarily provided by community members, and Ubiquiti Networks makes no guarantee of the validity of this content.