12.3. Firewall Rules (Forward and Input)

Firewall Rules are the core of the VT AIR Firewall. When you open the Rules site you can see that Firewall Rules are grouped by interface. The interface is the incoming interface, meaning the interface the traffic enters the firewall first.

For example if your computer is behind LAN and the internet behind WAN and you are going to visit a website, then the traffic originates from your computer and enters the firewall on the LAN interface first. A firewall rule to allow the traffic has to be defined on LAN. A backwards rule is not necessary, since the firewall will create a state which will keep track of the open connection. The backwards connection from the WAN to LAN is implied and allowed.

There are also Global Firewall Rules (Forward and Input) which are more flexible and have the option to set the incoming and outgoing interface or set them to any.

On each Firewall Rule page you will see the builtin rules with a gray background. You can not change them or move them. Only user created rules can be changed.

12.3.1. Move Rules

Rules are gouped by interface and are paged in groups of 20 rules. You can drag and drop user created rules to a different position and you can save that position by pressing save on the bottom navigation. You can also move a rule to the next or previous page or the first or last page if you mark the rule on the left (click on the first cell of the firewall rule) and use the arrows on the bottom left. If you hover over the buttons they will also show you their description.

12.3.2. Create and Update Rules

If you click Add you will create a new rule on the current interface where you are. You have various options for the rule to set and the rules are structured by the following sections:

  • General Settings
  • ICMP Settings
  • Sources
  • Destinations
  • Advanced

12.3.2.1. General Settings

You can change the following options here:

Enabled Enable or Disble the rule

Interface You can change the Interface of this rule. It will be added to the end of the rule list of that interface if you change it.

Action We have three actions defined here:

  • Accept
  • Drop (Silently drops the package)
  • Reject (Send back a reject ICMP message)

Address Family Is either IPv4, IPv6 or both. Depending on the sources and destinations you define the system might not generate a rule for both if you choose IPv4+IPv6.

Protocol The Layer 2 Protocol of the rule.

12.3.2.2. ICMP Settings

If you choose ICMP as protocol you can also filter by ICMP Type here.

12.3.2.3. Sources

The Source setting has options for the Source IPs, Source Mac Addresses and if applicaple Source Ports. You can add muliple entries of each and also mix IPv4 and IPv6. The system will figure out the rule for you.

Source Mac Addresses and Source Ports can be found under Advanced Source Settings.

The Invert IP Match option will invert IPs and Macs as well as the ports.

12.3.2.4. Destinations

The Destination setting has options for the Destination IPs and if applicaple Destination Ports. You can add muliple entries of each and also mix IPv4 and IPv6. The system will figure out the rule for you.

The Invert IP Match option will invert IPs as well as the ports.

Be aware that due to the structure in Firewall Flow you have to explicitly choose the Interface IP Alias if you want the destination to be the firewall itself. Custom IPs or Aliases are not recognized.

12.3.2.5. Advanced

In the Advanced Settings you can configure a couple of extra options.

Logging You can log the rules traffic and also add a prefix so you can find it easier. Be aware that firewall logging is an expensive operation and generates a lot of log entries. This disables the Flowtable Bypass optimization and connections might be slower.

Force Input Rule This option will make this rule an Input rule so the firewall is the destination with whatever IP you set in the destination field. Usually VT AIR will try and figure out if it needs to put the rule into Input or Forward or both. This will override the detection and only put the Rule in Input.

Stateless If set no state is created for this connection. You must create a second rule for the return traffic. This is mostly needed for asymmetric routing.

Limit Limit the rule. You can set for how many matches the rule should be active for a given time. It can be a speed (KBit/MBit/Byte/KByte/MByte) or time in packages per second/minute/hours. Please also refer to QoS for more explanations.

TCP Flags If the protocol is TCP you can also filter by TCP Flags.

TCP MSS If the protocol is TCP you can also set the MSS. This might be necessary if the MTU is smaller than ususal. This setting is also available on a per Interface basis in the Interface Settings.

Routing Table Choose a different Routing Table for matches. The main routing table is used by default. This allows for Policy Routing. Matching traffic will use the selected routing table.

QoS Class Input The class used for input shaping on any interface this traffic is passing and that has QoS enabled. Be aware that the directions must be assigned accordingly. If you create a rule on LAN to be shaped on WAN, make sure that QoS is active on WAN and you pick the correct class that you want to have for WAN. Unline QoS Output, QoS Input can only configured for non Bridge members.

QoS Class Output The class used for output shaping on any interface this traffic is passing and that has QoS enabled. If you create a rule on LAN to be shaped on WAN, make sure that QoS is active on WAN and you pick the correct class that you want to have for WAN.

DSCP Types Differentiated services code point (DSCP) for QoS in the IP or IP6 Header. You can match the different types with this option. The option is only matched when a new firewall state is created on the first packet of the connection. Afterwards any change of the DSCP Type is not recognized for an open firewall state.

Master No HASync This option will stop the High Availibility Sync of this rule to a slave.

Slave No HASync Delete Usually the High Availibility Sync will delete all settings on the slave that are not present on the master. This option will preserve the rule if it is only available at the slave.

12.3.2.6. Changes

At the bottom of each rule you can see the Created date, Modified date and the user that last modified the rule Modified user.

12.3.3. Hostnames in Rules

We support hostnames in rules as destination or source. Be aware though that they MUST be resolvable when the firewall rules are loaded, applied or reapplied. The firewall rules CAN NOT be updated, if there is no working DNS. The reload will fail and leave the old ruleset in place.