Feature #7674
open
source/tunnels: config option to distinguish tunnels
Added by Philippe Antoine 2 months ago.
Updated 22 days ago.
Description
The ebpf xdp_filter.c program does not handle encapsulated flows (with erspan, VXLAN, or some other tunnel)
But it could.
Even if it does, Suricata AFPXDPBypassCallback checks PacketIsTunnel and falls back to local bypass in this case
The feature request here is to
- Have config options for which kinds of tunnels
AFPXDPBypassCallback can handle
- have the example xdp_filter.c handle these
Some other improvements to xdp_filter.c will be proposed : ARP bypass, and tunnel stripping ( related to https://github.com/OISF/suricata/pull/11472 )
Related issues
1 (1 open — 0 closed)
- Subject changed from xdp: possibility to bypass encapsulated flows to source/tunnels: config option to distinguish tunnels
This means adding a tunnel identifier based on suricata.yaml configuration which will define these tunnels (packet sources)
The use case is when the network stream to be monitored is brought to Suricata using one or more tunnels (GRE, VXLAN, ...).
Suricata.yaml could look like
capture-tunnels:
- id: 1
type: erspan
src: 192.168.1.1
dst: 192.168.1.3
session: 123
- id: 2
type: vxlan
src: 192.168.1.2
dst: 192.168.1.3
session: 42
Then a ping from 192.168.5.6 -> 192.168.5.7 in tunnel 1, and one ping from 192.168.5.6 -> 192.168.5.7 in tunnel 2 will not be the same flow ! (and not the same as the same not encapsulated ping)
Adding this feature will lead to other possible implementable stuff :
- we will be able to bypass at XDP level the encapsulated flows while taking care that one encapsulated flow in tunnel 1 is not mistaken in another same-looking encapsulated flow in tunnel 2
- we could also use this tunnel identifier as a multi-tenant selector
- a config option could be used to skip the traffic that is not part of the defined tunnels
- Related to Bug #7717: vxlan: treat as its own tunnel added
- Status changed from New to In Review
Also available in: Atom
PDF