Fast path IP packet filtering¶
Fast path IP packet filtering replaces regular IP packet filtering, Virtual Service Router provides a faster implementation, leveraging the fast path.
Caution
Fast path IP packet filtering and regular IP packet filtering cannot be used together.
Overview¶
Fast path IP packet filtering
is a IP packet filter, supporting IPv4 and IPv6, as well
as transport protocols such as TCP, UDP and ICMP.
Packet Flow¶
Processing is performed on each interface a packet is traversing, either as ingress
or egress
.
Thus, the filtering interception happens at two different levels of IP stack:
for
ingress
: before the routing decision, for packets coming from an interfacefor
egress
: after the routing decision, for packets routed to an interface
The following diagram illustrates rule evaluation with respect to network interfaces if0
and
if1
, assuming traffic is being forwarded between them. (1) points to traffic in one direction
and (2) to the opposite direction:
Specifically:
Rules are associated to an interface and a direction.
Forwarded packets are inspected twice (on
ingress
andegress
)
Packet Inspection¶
As explained in the previous part, the fast path firewall intercepts the packets at the IP layer of the network packet.
First, the packet is intercepted from an interface (ingress
) or before going to an interface
(egress
).
The following diagram illustrates how the packet inspection is done:
The first step of packet processing is to do a conntrack lookup in function of source/destination IP address, protocol, and source/destination ports. More information is provided about the conntrack feature the Connection tracking section.
If no conntrack is found, packet is evaluated against the rules specific to an interface and
a direction. In this example, the rules evaluated are for the if0
interfaces and the ingress
direction. If a conntrack is found, rule evaluation is bypassed.
The packet is evaluated against each rule’s matching criteria. Rules evaluation is done until a rule matches the packet. If no rules match, the packet is evaluated against the default rules.
It no default rules match, the packet is dropped.
Definitions¶
Rules¶
A rule is defined by a name, a verdict decision, optional actions, and one or several match parameters.
vsr running vrf main# / vrf main firewall fast-path rule ssh accept
vsr running vrf main# / vrf main firewall fast-path rule ssh match family ipv4 source-address 1.1.1.1
vsr running vrf main# / vrf main firewall fast-path rule ssh match family ipv4 protocol tcp destination-port 22
When a packet matches a rule, the following verdict decisions can be taken:
accept : Accept the packet. It continues through the network stack.
track : Accept the packet and track it by creating a conntrack. Next packet matching the conntrack are directly accepted without evaluating filtering rules.
drop : Drop the packet.
reject : Drop the packet and notify the sender by sending a
rst
message for TCP packets or by sending ICMP Unreachable message for other packets.
The maximal number of rules can be configured into fast path limits:
vsr running vrf config# / system fast-path limits fp-firewall max-rules 2000
Note
The number of rules loaded in fast path corresponds to the number of times of rules are assiocated to an interface. To check how many rules are loaded into fast-path:
vsr running vrf config# show state / system fast-path limits fp-firewall cur-rules
cur-rules 3
Warning
If the number of rules in the fast path firewall is bigger that the fast path limits, the configuration will not be loaded. Please make sure to configure max-rules to be large enough for loading your configuration. Each time a fast path limits is changed, the fast path is restarted. Until fast path restarting is done, network processing is interrupted.
Interfaces and directions¶
In order to configure the fast path firewall, it is necessary to specify the
interfaces on which the rules are applied. These interfaces correspond to the
interfaces configured in the current VRF. To apply a rule to an interface, it is
necessary to specify the ingress
or egress
direction. A rule can be applied in
both directions, if necessary. When adding a rule to an interface, the specified
index is used to define the execution order of the rules.
vsr running vrf main# / vrf main firewall fast-path interface eth1 ingress rule 1 rule-name ssh
Match criteria¶
A rule can match a packet with the following criteria:
inet family: IPv4 or IPv6
source and destination ip addresses
protocol number
source and destination ports
application
address/network group
DCSP
ICMP type and code
Application¶
Applications can be configured to facilitate the identification of application protocols.
vsr running vrf main# / vrf main network-stack application ftp tcp port 20-21
vsr running vrf main# / vrf main network-stack application tftp udp port 69
vsr running vrf main# / vrf main group application-group ftp-tftp application ftp application tftp
This application can be used in the match criteria of a rule.
vsr running vrf main# / vrf main firewall fast-path rule ftp-drop drop
vsr running vrf main# / vrf main firewall fast-path rule ftp-drop match family any destination-application ftp
vsr running vrf main# / vrf main firewall fast-path rule ftp-tftp-drop drop
vsr running vrf main# / vrf main firewall fast-path rule ftp-drop match family any destination-application ftp-tftp
Address/network group¶
An address group is a set of IPv4 or IPv6 addresses. A network group is a set of IPv4 or IPv6 networks.
vsr running vrf main# / vrf main group ipv4 network-group ipv4-local network 192.168.0.0/24 network 10.0.0/24
vsr running vrf main# / vrf main group ipv4 address-group malicious address 19.1.3.86 address 19.3.3.88
These groups can be used in the match criteria of a rule.
vsr running vrf main# / vrf main firewall fast-path rule local-accept accept
vsr running vrf main# / vrf main firewall fast-path rule local-accept match family ipv4 destination-address ipv4-local
vsr running vrf main# / vrf main firewall fast-path rule malicious-drop drop
vsr running vrf main# / vrf main firewall fast-path rule malicious-drop match family ipv4 source-address malicious
The maximal number of network/address group and the maximal number of addresses/networks can be configured into fast path limits:
vsr running vrf config# / system fast-path limits fp-firewall max-networks 2000
vsr running vrf config# / system fast-path limits fp-firewall max-network-groups 2000
Network or address are allocated into the same object in fast-path. Thus to increase the maximal number of addresses supported, you must set max-networks.
Warning
If the number of networks or network-groups in the fast path firewall is bigger than the fast path limits, the configuration will not be loaded. Please make sure to configure these ones to be large enough for loading your configuration. Each time a fast path limits is changed, the fast path is restarted. As consequence, network processing is interrupted until fast path has finished to restart.
Default rules¶
The default rules are applied when packets don’t match any rule or any conntrack. It is mandatory to set at least one default rule.
Connection tracking¶
The fast path firewall is a stateful packet filter capable of tracking TCP connections, as well as
performing UDP and ICMP tracking. To track a connection, the firewall creates a conntrack
.
The conntrack
is stored in a database with two different keys: origin and reply.
These keys are used to retrieve the conntrack with the original stream and the reply stream
of the connection.
The keys have the following fields:
the source and destination addresses,
the source and destination port
the protocol (i.e. TCP, UDP, ICMP, ICMPv6)
Additionally, the connection tracking feature is in charge of tracking the state of the connections. It also validates that the state transitions are correct according to the protocol standards. Packets leading to an invalid state transitions are dropped (e.g. receiving a non SYN TCP packet for a new connection).
For TCP connections, the connection tracking can also verify the validity of the sequence and window numbers of packets received.
As an optimization, once a connection tracking entry (conntrack) is created, subsequent packets in the original stream are passed without rules inspection, as is the case for packets in the reply stream after having been confirmed to belong to the same connection.
The rule inspection is bypassed on an interface basis. For example, forwarded traffic entering an interface and exiting through another has to encounter a track rule once on each interface to completely bypass rule inspection.
If a packet doesn’t match any rule for this interface and this direction, it is evaluated against the default rules. The default rules always has an implicit rule to let pass packets matching a conntrack. When this implicit rule is matched, subsequent packets are also passed without rule inspection on this interface.
In the following diagram, the first packet (1) of a bidirectional connection forwarded between
interfaces if0
and if1
goes through rules inspection twice, as represented by dashed arrows.
Assuming this packet is matched by two track rules (one for each interface), ruleset inspection is then bypassed by the resulting conntrack for subsequent packets of the original stream (3) and all packets in the reply stream (2), as represented by solid arrows:
Conntrack rule sets¶
A conntrack rule set is a set of actions applied to tracked packets. It is
associated with the conntrack, and configured in the rule with the track <name>
keyword.
Actions¶
Actions describe something that alters packets in some way.
They can be configured after the action
keyword of a filtering rule as shown below:
vsr running vrf main# / vrf main firewall fast-path rule ssh accept action set-mark 0x80
Several actions can be combined for a given rule.
A rule can specify only one action of each kind.
Their order is not relevant.
Actions are performed immediately for each packet at the same processing stage of the matching rule.
Regarding
track
rules, specified actions are additionally saved in the conntrack entry to be performed on traffic bypassing ruleset inspection (refer to the Connection tracking section for details).Conntracks support two independent sets of actions, one inherited from a
track
rule matching theingress
direction and another from a rule matching theegress
direction.Since conntracks are bidirectional, each action can be configured on the two directions (i.e.
origin
andreply
)See DSCP section to see an example of action with a conntrack.
Packet mark¶
Packet marks are user metadata meant to facilitate traffic processing in the fast path. Although marks are attached to packets, they do not appear on the network.
They are typically set by the filtering stage to feed traffic classification, since relying on a mark is much more efficient than matching an entire packet header.
Synopsis
Set packet mark on both ingress and egress TCP traffic:
vsr running vrf main# / vrf main firewall fast-path rule tcp-mark accept action set-mark 0x3011986
vsr running vrf main# / vrf main firewall fast-path rule tcp-mark match family any protocol tcp
vsr running vrf main# / vrf main firewall fast-path interface eth1 ingress rule 1 rule-name tcp-mark
vsr running vrf main# / vrf main firewall fast-path interface eth1 egress rule 1 rule-name tcp-mark
TCP MSS¶
Modify TCP SYN packets to limit their advertised MSS to the specified value without affecting those already below the limit.
Oddball TCP SYNs lacking the MSS option are also expanded to include it with the specified value whenever possible (i.e. it won’t be done if options space is already full).
Although not recommended, limiting below standardized minimum values is supported. They are normally 536 bytes for IPv4 according to RFC 1122, and 1220 bytes (1280 - 60) for IPv6 according to RFC 2460.
Alternatively, the special value auto
relies on Fast Path PMTU discovery module to automatically
choose an appropriate limit for each session.
Synopsis
Limit MSS to 1300 bytes for egress TCP traffic:
vsr running vrf main# / vrf main firewall fast-path rule tcp-mss accept action set-mss 1300
vsr running vrf main# / vrf main firewall fast-path rule tcp-mss match family any protocol tcp
vsr running vrf main# / vrf main firewall fast-path interface eth1 egress rule 1 rule-name tcp-mss
Rely on path MTU for the proper value:
vsr running vrf main# / vrf main firewall fast-path rule tcp-mss accept action set-mss 1300
DSCP¶
Update the DSCP field of IP headers, specifically the six most significant bits of what used to be known as the ToS field. The two least significant bits constituting ECN are not affected.
With IPv6 packets, this action affects the DS portion of Traffic Class instead.
In addition to set-dscp
which forces a specific DSCP value, the
following actions are available in a conntrack rule set:
save-dscp
: record current packet DSCP into conntrack.restore-dscp
: restore previously recorded value (if any) into packet.
Without a conntrack, these actions are not supported. They are useful in a forwarding scenario where one side is expected to keep the original DSCP value in both directions, while a specific value is needed for the other.
Synopsis
Force DSCP to value 38 on egress traffic:
vsr running vrf main# / vrf main firewall fast-path rule tcp-dscp accept action set-dscp 38
vsr running vrf main# / vrf main firewall fast-path interface eth1 egress rule 1 rule-name tcp-dscp
Record the original DSCP value of incoming traffic on eth0
in the conntrack
and restore it to the recorded value for outgoing traffic:
vsr running vrf main# / vrf main firewall fast-path conntrack-rule-set save_restore_dcsp origin save-dscp
vsr running vrf main# / vrf main firewall fast-path conntrack-rule-set save_restore_dcsp reply restore-dscp
vsr running vrf main# / vrf main firewall fast-path rule rule_dscp track apply save_restore_dcsp
vsr running vrf main# / vrf main firewall fast-path interface eth0 egress rule 1 rule-name rule_dscp
Configuration¶
Basic¶
This example configures Virtual Service Router so traffic incoming on eth1
for port 22 and
830 will be allowed. The rest of the traffic will be dropped.
create a rule named
default_rule
that blocks all the trafficset
default_rule
in the default rulescreate a rule named
ssh
that authorizes ssh traffic from1.1.1.1
create a rule named
netconf
that authorizes netconf traffic from1.1.1.1
set this rule on interface
eth1
foringress
vsr running vrf main# / vrf main firewall fast-path rule default_rule drop
vsr running vrf main# / vrf main firewall fast-path default rule 1 rule-name default_rule
vsr running vrf main# / vrf main firewall fast-path rule ssh accept
vsr running vrf main# / vrf main firewall fast-path rule ssh match family ipv4 source-address 1.1.1.1
vsr running vrf main# / vrf main firewall fast-path rule ssh match family ipv4 protocol tcp destination-port 22
vsr running vrf main# / vrf main firewall fast-path rule netconf accept
vsr running vrf main# / vrf main firewall fast-path rule netconf match family ipv4 source-address 1.1.1.1
vsr running vrf main# / vrf main firewall fast-path rule netconf match family ipv4 protocol tcp destination-port 830
vsr running vrf main# / vrf main firewall fast-path interface eth1 ingress rule 1 rule-name ssh
vsr running vrf main# / vrf main firewall fast-path interface eth1 ingress rule 2 rule-name netconf
vsr running vrf main# commit
Note
This configuration is partial, and only shown as an example. It should not be used as is in production.
vsr> show config xml absolute / vrf main firewall fast-path
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<firewall xmlns="urn:6wind:vrouter/firewall">
<fast-path xmlns="urn:6wind:vrouter/fp-firewall">
<enabled>true</enabled>
<rule>
<name>default_rule</name>
<drop/>
<match>
<source/>
<destination/>
</match>
</rule>
<rule>
<name>ssh</name>
<accept/>
<match>
<family>
<ipv4>
<source-address>
<value>1.1.1.1</value>
</source-address>
<protocol>
<tcp>
<destination-port>
<value>22</value>
</destination-port>
</tcp>
</protocol>
</ipv4>
</family>
</match>
</rule>
<rule>
<name>netconf</name>
<accept/>
<match>
<family>
<ipv4>
<source-address>
<value>1.1.1.1</value>
</source-address>
<protocol>
<tcp>
<destination-port>
<value>830</value>
</destination-port>
</tcp>
</protocol>
</ipv4>
</family>
</match>
</rule>
<interface>
<name>eth1</name>
<ingress>
<rule>
<id>1</id>
<rule-name>ssh</rule-name>
</rule>
<rule>
<id>2</id>
<rule-name>netconf</rule-name>
</rule>
</ingress>
<egress/>
</interface>
<default>
<rule>
<id>1</id>
<rule-name>default_rule</rule-name>
</rule>
</default>
</fast-path>
</firewall>
</vrf>
</config>
Let’s show the resulting state:
vsr running vrf main# show state / vrf main firewall fast-path
fast-path
enabled true
rule default_rule
drop
..
statistics
match
packets 0
bytes 0
..
conntrack
origin
packets 0
bytes 0
..
reply
packets 0
bytes 0
..
..
..
..
rule ssh
accept
..
match
family
ipv4
source-address 1.1.1.1
protocol
tcp
destination-port 22
..
..
..
..
..
..
statistics
match
packets 0
bytes 0
..
conntrack
origin
packets 0
bytes 0
..
reply
packets 0
bytes 0
..
..
..
..
rule netconf
accept
..
match
family
ipv4
source-address 1.1.1.1
protocol
tcp
destination-port 830
..
..
..
..
..
..
statistics
match
packets 0
bytes 0
..
conntrack
origin
packets 0
bytes 0
..
reply
packets 0
bytes 0
..
..
..
..
interface eth1
ingress
rule 1
rule-name ssh
statistics
match
packets 0
bytes 0
..
conntrack
origin
packets 0
bytes 0
..
reply
packets 0
bytes 0
..
..
..
..
..
..
default
rule 1
rule-name default_rule
statistics
match
packets 0
bytes 0
..
conntrack
origin
packets 0
bytes 0
..
reply
packets 0
bytes 0
..
..
..
..
..
Conntrack rule sets¶
This example configures Virtual Service Router so that incoming packets on eth1
matching a
conntrack will have a 0x1
mark set.
create a rule named
default_rule
that allows all the trafficset
default_rule
in the default rulescreate a conntrack rule set name
conntrack_mark
that adds a mark to the packet when a packet matches the conntrackcreate a rule named
rule_marker
that tracks all packets and apply theconntrack_mark
set theses rules on interface
eth1
foringress
vsr running vrf main# / vrf main firewall fast-path rule default_rule accept
vsr running vrf main# / vrf main firewall fast-path default rule 1 rule-name default_rule
vsr running vrf main# / vrf main firewall fast-path conntrack-rule-set conntrack_mark origin set-mark 0x1
vsr running vrf main# / vrf main firewall fast-path rule rule_marker track apply conntrack_mark
vsr running vrf main# / vrf main firewall fast-path interface eth1 ingress rule 1 rule-name rule_marker
vsr running vrf main# commit
Limitations¶
The fast path firewall have the following limitations:
it performs filtering only on accelerated ethernet NICs.
it doesn’t support filtering packets on tunneling interface like GRE, VXLAN, ipip.