New VNS3 Firewall Features in VNS3 4.11

by | 22 Oct 2020

The VNS3 Firewall is a wrapper around Linux’s “iptables”. The VNS3 firewall abstracts away the concept of tables, removing a variable and making the process more user-friendly. Today we’ll take a look at some of the newest features of the VNS3 firewall.

For those unfamiliar, below is a short synopsis of how the VNS3 firewall works. You can also read our full Firewall Overview article here: https://cohesiveprod.wpenginepowered.com/firewall-overview-with-vns3

Each firewall rule is comprised of three parts:

  1. The chain (PREROUTING_CUST, INPUT_CUST, FORWARD_CUST, OUTPUT_CUST, or POSTROUTING_CUST)
  2. The conditions (packet parameters to match on), and
  3. The target (after the -j option; the action to be taken on the packet)

Packets entering VNS3 traverse the chains in a particular order. The chain determines at what point during packet processing a rule will be matched and an action taken on the packet. Certain conditions and targets may only be used in certain chains.

If a packet does not match any rule in a chain, the default action is ACCEPT, which simply sends the packet along to the next step.

A rule’s conditions determine which packets will be matched; all conditions of a rule must be met before an action will be taken. If any condition is not met, the packet will be checked against the next rule in the chain.

When a packet matches all conditions of a rule, the target operation is carried out and the packet moves on to the next step. That packet will NOT be checked against any other rules in that chain.

These basic conditions (as well as many more) are available:

  • -s <ip or cidr> : Matches the source address of the packet. Accepts an IP, a CIDR, or a comma-separated list of either.
  • -d <ip or cidr> : Same as the above, but matches the destination address.
  • -p <protocol> : Matches the protocol of the packet. (-p Also offers the additional –dport <port> and –sport <port> options if applicable to the protocol specified.)
  • -i <interface> : Matches the incoming interface by name. Not available in OUTPUT or POSTROUTING.
  • -o <interface> : Matches the outgoing interface by name. Not available in INPUT or PREROUTING.

The diagram below details the order of the steps packets take as they traverse VNS3.

VNS3 Firewall Map

Example: Pre-routing Firewall Rule

Lets take a look at a few examples, starting with this PREROUTING firewall rule:

PREROUTING_CUST -i eth0 -s 172.31.0.0/16 -j DROP

This rule matches packets entering on the eth0 interface (-i eth0) with a source inside the 172.31.0.0/16 network (-s 172.31.0.0/16). The DROP target causes matched packets to be discarded without any reply.

If the above rule is the only PREROUTING rule you have in place, any packet entering on VNS3’s eth0 interface with any source outside the 172.31.0.0/16 network will not be affected; the default ACCEPT action will be taken and the packet will move on to the next step.

Immediately after the PREROUTING chain, the destination IP of the packet is used to determine whether an attempt will be made to forward the packet or if VNS3 itself is the destination. If the packet’s destination IP is one on an interface belonging to VNS3, it will be sent to the INPUT chain. If the packet’s destination is any other address, an eventual outgoing interface is chosen and the packet is sent on to the FORWARD chain.

As an example, TCP port 8000 traffic for the VNS3 Web UI and API traverses the INPUT chain, as do response packets from VNS3’s configured DNS and time servers, among other internal services.

Following a routing decision to determine the outgoing interface and before being sent to the POSTROUTING chain, packets leaving VNS3 (including Web UI and API responses) traverse the OUTPUT chain.

With the following FORWARD rules in place, all traffic between the 10.0.0.0/24 and 192.168.0.0/24 networks is allowed, and nothing else.

FORWARD_CUST -s 10.0.0.0/24 -d 192.168.0.0/24 -j ACCEPT

FORWARD_CUST -s 192.168.0.0/24 -d 10.0.0.0/24 -j ACCEPT

FORWARD_CUST -j DROP

Only a packet with a source inside 10.0.0.0/24 and destination inside 192.168.0.0/24 (or vice-versa) would match one of the first two rules; those would skip over the DROP rule and be sent on to the POSTROUTING chain. Anything with a source or destination not matching those two networks is dropped by the third rule.

This is a basic example of how to configure whitelisting; the DROP rule at the end with no conditions matches all packets and defines a default action for the chain.

New Features: Masquerade-Once and GeoIP

Let’s take a brief look at a couple newer features of the VNS3 firewall: MASQUERADE-ONCE and geoip.

For this example, our local network is 192.168.0.0/24, and our goal is to SNAT all traffic outbound from the 192.168.0.0/24 network to the address on VNS3’s internet-facing interface.

The firewall rule could look like this:

POSTROUTING_CUST -s 192.168.0.0/24 -o eth0 -j MASQUERADE-ONCE

We recommend using MASQUERADE-ONCE over MASQUERADE where possible because it is more performant. It does this by calculating the source IP based on the -o outgoing interface only once – when the rule is created. This allows use of the connection tracking table to shorten the time packets spend traversing firewall rules.

The “geoip” module condition was added to the VNS3 firewall to allow users to block/allow traffic by country of origin/destination. The example rule below firewall blocks all traffic originating from Australia(AU), Canada(CA), and Japan(JP).

PREROUTING_CUST -m geoip –src-cc AU,CA,JP -j DROP

For more information about “geoip” blocking check out the Max Mind API. For more information about the VNS3 firewall, check out our documentation. If you have any questions please reach out to Cohesive Support via email at support@www.cohesive.net or through our contact us page.