The firewall module protects the system from Internet exposure. Every network packet iterates from top-to-bottom over a list of firewall rules until a match is found, if no match is found the packet gets dropped. The outcome of a packet will depend on the matched firewall rule: accept, reject or drop. Rejected packet senders are notified using ICMP destination-unreachable notifications. Senders of dropped packets will never be notified and time-out (or wait indefinitely) and accepted traffic may pass the firewall.

The firewall rules can be applied to any interface. However in practice it's convention to use firewall rules mainly for WAN ports (upstream or management networks) since the HSMX will manage the subscriber network interfaces using it's built-in default policies or configurable per Location, Billing-plan or individual subscriber using Network Policies.

Every firewall rule has a descriptive name; is applied to one or all interface(s) and has a traffic direction set. The direction of a packet can be Incoming or Outgoing from the point of view of the HSMX gateway. The firewall provides stateful features so it's possible to filter out traffic depending on TCP state. The final three parameters are (destination) port, source and destination IP (or network).

• Avoid taking unnecessary risks, only reveal a minimum number of required services to the Internet, every open port provides an attack vector.

• Be careful when editing firewall rules. It's easy to lock yourself out of the system. For example removing an allow on destination port 22 in TCP (any state) will not (immediately) drop existing established SSH sessions. New connections however will not be accepted anymore.

• Direction is viewed from the HSMXes point-of-view: in is towards the HSMX, out is leaving the HSMX. It sometimes can be tricky when working with traffic from subscriber networks towards WAN (management networks) or unmanaged interfaces.

• For cluster interfaces: if the cluster interface is a point-to-point link between two nodes you can safely configure the firewall to pass all traffic on that interface. In all other cases we suggest only opening up the necessary ports (there are presets available in the drop-down in top-right corner) with the remote cluster IP as source or if possible, eg. if node one holds 172.19.1.14/29 and node two 172.19.1.15/29 we can configure 172.19.1.14/31 as source and destination.

• nmap -sU -sS <ip address>: Execute a port scan for most active/known services using NMap