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 interface
for 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:

../../../_images/fp-ip-packet-filtering-rule.svg

Specifically:

Rules are associated to an interface and a direction.
Forwarded packets are inspected twice (on ingress and egress)

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:

../../../_images/fp-ip-packet-filtering-processing.svg

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.

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

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:

../../../_images/fp-ip-packet-filtering-ct.svg

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 the ingress direction and another from a rule matching the egress direction.

Since conntracks are bidirectional, each action can be configured on the two directions (i.e. origin and reply)

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 traffic
set default_rule in the default rules
create a rule named ssh that authorizes ssh traffic from 1.1.1.1
create a rule named netconf that authorizes netconf traffic from 1.1.1.1
set this rule on interface eth1 for ingress

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 traffic
set default_rule in the default rules
create a conntrack rule set name conntrack_mark that adds a mark to the packet when a packet matches the conntrack
create a rule named rule_marker that tracks all packets and apply the conntrack_mark
set theses rules on interface eth1 for ingress

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.