Flowtables Firewall Configuration
Note
Documentation under development
Overview
In this section there’s useful information on all firewall configuration that can be done regarding flowtables.
From the main structure defined in Firewall Overview in this section you can find detailed information only for the next part of the general structure:
- set firewall
* flowtable
- custom_flow_table
+ ...
Flowtables allow you to define a fastpath through the flowtable datapath. The flowtable supports for the layer 3 IPv4 and IPv6 and the layer 4 TCP and UDP protocols.

Once the first packet of the flow successfully goes through the IP forwarding path (black circles path), from the second packet on, you might decide to offload the flow to the flowtable through your ruleset. The flowtable infrastructure provides a rule action that allows you to specify when to add a flow to the flowtable (On forward filtering, red circle number 6)
A packet that finds a matching entry in the flowtable (flowtable hit) is transmitted to the output netdevice, hence, packets bypass the classic IP forwarding path and uses the Fast Path (orange circles path). The visible effect is that you do not see these packets from any of the Netfilter hooks coming after ingress. In case that there is no matching entry in the flowtable (flowtable miss), the packet follows the classic IP forwarding path.
Note
Flowtable Reference: https://docs.kernel.org/networking/nf_flowtable.html
Flowtable Configuration
In order to use flowtables, the minimal configuration needed includes:
Create flowtable: create flowtable, which includes the interfaces that are going to be used by the flowtable.
Create firewall rule: create a firewall rule, setting action to
offload
and using desired flowtable foroffload-target
.
Creating a flow table:
Define interfaces to be used in the flowtable.
Provide a description to the flow table.
Define type of offload to be used by the flowtable: hardware
or
software
. By default, software
offload is used.
Note
Hardware offload: should be supported by the NICs used.
Creating rules for using flow tables:
Create firewall rule in forward chain, and set action to offload
.
Configuration Example
Things to be considered in this setup:
Two interfaces are going to be used in the flowtables: eth0 and eth1
Minimum firewall ruleset is provided, which includes some filtering rules, and appropriate rules for using flowtable offload capabilities.
As described, the first packet will be evaluated by the firewall path, so a desired connection should be explicitly accepted. Same thing should be taken into account for traffic in reverse order. In most cases state policies are used in order to accept a connection in the reverse path.
We will only accept traffic coming from interface eth0, protocol tcp and destination port 1122. All other traffic trespassing the router should be blocked.
Commands
set firewall flowtable FT01 interface 'eth0'
set firewall flowtable FT01 interface 'eth1'
set firewall ipv4 forward filter default-action 'drop'
set firewall ipv4 forward filter rule 10 action 'offload'
set firewall ipv4 forward filter rule 10 offload-target 'FT01'
set firewall ipv4 forward filter rule 10 state 'established'
set firewall ipv4 forward filter rule 10 state 'related'
set firewall ipv4 forward filter rule 20 action 'accept'
set firewall ipv4 forward filter rule 20 state 'established'
set firewall ipv4 forward filter rule 20 state 'related'
set firewall ipv4 forward filter rule 110 action 'accept'
set firewall ipv4 forward filter rule 110 destination address '192.0.2.100'
set firewall ipv4 forward filter rule 110 destination port '1122'
set firewall ipv4 forward filter rule 110 inbound-interface name 'eth0'
set firewall ipv4 forward filter rule 110 protocol 'tcp'
Explanation
Analysis on what happens for desired connection:
1. Firstly, a packet is received on eth0, with destination address 192.0.2.100, protocol tcp and destination port 1122. Assume such destination address is reachable through interface eth1.
2. Since this is the first packet, connection status of this connection, so far is new. So neither rule 10 nor 20 are valid.
Rule 110 is hit, so connection is accepted.
4. Once an answer from server 192.0.2.100 is seen in opposite direction, connection state will be triggered to established, so this reply is accepted in rule 20.
5. The second packet for this connection is received by the router. Since connection state is established, then rule 10 is hit, and a new entry in the flowtable FT01 is added for this connection.
6. All the following packets will skip the traditional path, will be offloaded and use the Fast Path.
Checks
It’s time to check the conntrack table, to see if any connections were accepted, and if it was properly offloaded
vyos@FlowTables:~$ show firewall ipv4 forward filter
Ruleset Information
---------------------------------
ipv4 Firewall "forward filter"
Rule Action Protocol Packets Bytes Conditions
------- -------- ---------- --------- ------- ----------------------------------------------------------------
10 offload all 8 468 ct state { established, related } flow add @VYOS_FLOWTABLE_FT01
20 accept all 8 468 ct state { established, related } accept
110 accept tcp 2 120 ip daddr 192.0.2.100 tcp dport 1122 iifname "eth0" accept
default drop all 7 420
vyos@FlowTables:~$ sudo conntrack -L | grep tcp
conntrack v1.4.6 (conntrack-tools): 5 flow entries have been shown.
tcp 6 src=198.51.100.100 dst=192.0.2.100 sport=41676 dport=1122 src=192.0.2.100 dst=198.51.100.100 sport=1122 dport=41676 [OFFLOAD] mark=0 use=2
vyos@FlowTables:~$