Firewall

• Filtering by source and destination IP, IP protocol, source and destination port for TCP and UDP traffic
• Able to limit simultaneous connections on a per-rule basis
• M-Wall utilizes p0f, an advanced passive OS/network fingerprinting utility to allow you to filter by the Operating System initiating the connection. Want to allow FreeBSD and Linux machines to the Internet, but block Windows machines? M-Wall can do so (amongst many other possibilities) by passively detecting the Operating System in use.
  
• Option to log or not log traffic matching each rule.
• Highly flexible policy routing possible by selecting gateway on a per-rule basis (for load balancing, failover, multiple WAN, etc.)
• Aliases allow grouping and naming of IPs, networks and ports. This helps keep your firewall ruleset clean and easy to understand, especially in environments with multiple public IPs and numerous servers.
• Transparent layer 2 firewalling capable - can bridge interfaces and filter traffic between them, even allowing for an IP-less firewall (though you probably want an IP for management purposes).
• Packet normalization - Description from the pf scrub documentation - "'Scrubbing' is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations."
• Enabled in M-Wall by default
• Can disable if necessary. This option causes problems for some NFS implementations, but is safe and should be left enabled on most installations.
• Disable filter - you can turn off the firewall filter entirely if you wish to turn M-Wall into a pure router.

State Table

The firewall's state table maintains information on your open network connections. M-Wall is a stateful firewall, by default all rules are stateful.

Most firewalls lack the ability to finely control your state table. M-Wall has numerous features allowing granular control of your state table, thanks to the abilities of OpenBSD's pf.

• Adjustable state table size - there are multiple production M-Wall installations using several hundred thousand states. The default state table size is 10,000, but it can be increased on the fly to your desired size. Each state takes approximately 1 KB of RAM, so keep in mind memory usage when sizing your state table. Do not set it arbitrarily high.
• On a per-rule basis:
  • Limit simultaneous client connections
  • Limit states per host
  • Limit new connections per second
  • Define state timeout
  • Define state type
• State types - M-Wall offers multiple options for state handling.
  • Keep state - Works with all protocols. Default for all rules.
  • Modulate state - Works only with TCP. M-Wall will generate strong Initial Sequence Numbers (ISNs) on behalf of the host.
  • Synproxy state - Proxies incoming TCP connections to help protect servers from spoofed TCP SYN floods. This option includes the functionality of keep state and modulate state combined.
  • None - Do not keep any state entries for this traffic. This is very rarely desirable, but is available because it can be useful under some limited circumstances.
• State table optimization options - pf offers four options for state table optimization.
  • Normal - the default algorithm
  • High latency - Useful for high latency links, such as satellite connections. Expires idle connections later than normal.
  • Aggressive - Expires idle connections more quickly. More efficient use of hardware resources, but can drop legitimate connections.
  • Conservative - Tries to avoid dropping legitimate connections at the expense of increased memory usage and CPU utilization.

Network Address Translation (NAT)

• Port forwards including ranges and the use of multiple public IPs
• 1:1 NAT for individual IPs or entire subnets.
• Outbound NAT
  • Default settings NAT all outbound traffic to the WAN IP. In multiple WAN scenarios, the default settings NAT outbound traffic to the IP of the WAN interface being used.
  • Advanced Outbound NAT allows this default behavior to be disabled, and enables the creation of very flexible NAT (or no NAT) rules.
• NAT Reflection - in some configurations, NAT reflection is possible so services can be accessed by public IP from internal networks.

NAT Limitations

• PPTP and GRE Limitation - The state tracking code in pf for the GRE protocol can only track a single session per public IP per external server. This means if you use PPTP VPN connections, only one internal machine can connect simultaneously to a PPTP server on the Internet. A thousand machines can connect simultaneously to a thousand different PPTP servers, but only one simultaneously to a single server. The only available work around is to use multiple public IPs on your firewall, one per client, or to use multiple public IPs on the external PPTP server. This is not a problem with other types of VPN connections. A solution for this is currently under development. 
• SIP Limitation - By default, all TCP and UDP traffic other than SIP and IPsec gets the source port rewritten. More information on this can be found in the static port documentation. Because this source port rewriting is how pf tracks which internal IP made the connection to the given external server, and most all SIP traffic uses the same source port, only one SIP device can connect simultaneously to a single server on the Internet. Unless your SIP devices can operate with source port rewriting (most can't), you cannot use multiple phones with a single outside server without using a dedicated public IP per device.
  
• NAT Reflection limitations - NAT reflection can only be used with port ranges less than 500 ports and cannot be used with 1:1 NAT hosts.

Redundancy

CARP from OpenBSD allows for hardware failover. Two or more firewalls can be configured as a failover group. If one interface fails on the primary or the primary goes offline entirely, the secondary becomes active. M-Wall also includes configuration synchronization capabilities, so you make your configuration changes on the primary and they automatically synchronize to the secondary firewall.

pfsync ensures the firewall's state table is replicated to all failover configured firewalls. This means your existing connections will be maintained in the case of failure, which is important to prevent network disruptions.

Limitations

• Only works with static public IPs, does not work with DHCP, PPPoE, PPTP, or BigPond type WANs (will be resolved in a future release)
• Requires a minimum of three public IP addresses (will be resolved in a future release)
• Backup firewalls are idle (active-passive failover), no active-active clustering is possible at this time.
• Failover is not instantaneous, it takes about 5 seconds to switch a backup host to master. During this time no traffic will be passed, but existing states will maintain connectivity after failover is completed. This 5 second outage during a failure isn't even noticeable in most environments.