1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
:lastproofread: 2024-07-02
.. _firewall-flowtables-configuration:
#################################
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.
.. cfgcmd:: set firewall flowtables ...
From the main structure defined in
:doc:`Firewall Overview</configuration/firewall/index>`
in this section you can find detailed information only for the next part
of the general structure:
.. code-block:: none
- 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.
.. figure:: /_static/images/firewall-flowtable-packet-flow.png
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 for ``offload-target``.
Creating a flow table:
.. cfgcmd:: set firewall flowtable <flow_table_name> interface <iface>
Define interfaces to be used in the flowtable.
.. cfgcmd:: set firewall flowtable <flow_table_name> description <text>
Provide a description to the flow table.
.. cfgcmd:: set firewall flowtable <flow_table_name> offload
<hardware | software>
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:
.. cfgcmd:: set firewall [ipv4 | ipv6] forward filter rule <1-999999>
action offload
Create firewall rule in forward chain, and set action to ``offload``.
.. cfgcmd:: set firewall [ipv4 | ipv6] forward filter rule <1-999999>
offload-target <flowtable>
Create firewall rule in forward chain, and define which flowtbale
should be used. Only applicable if action is ``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
--------
.. code-block:: none
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.
3. 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
.. code-block:: none
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:~$
|
