0

[EDITED] I'm receiving on physical interface ERSPAN-encapsulated traffic and need to process just a small part of it. In order to do this, I'm decapsulating traffic on local tunnel interface:

ip link add dev inspan type erspan seq key 10 local x.x.x.x erspan_ver 1
ip link set dev inspan up

and want to filter (drop/accept), rewrite and/or redirect accepted part to further processing - either local or towards set of remote workers. The configuration below supposed to be for the local processing.

Where I'm in stuck - the following rule works as expected:

table netdev filter {
        chain redir {
                type filter hook ingress device "inspan" priority filter; policy drop;
                iifname inspan udp dport 2311 ether daddr set 8a:b1:34:1d:35:ea ip daddr set 10.171.165.65 accept
        }
}

where MAC-address is inspan's address (where I receive decapsulated traffic) and IP address is local to this server (though, not inspan's).

Logs shows that rewrite done -

Aug 10 21:12:22 server kernel: [1726554.111664] IN=inspan OUT= MAC=8a:b1:34:1d:35:ea:a2:ee:e4:00:00:12:08:00 SRC=192.168.25.198 DST=10.171.165.65 LEN=372 TOS=0x00 PREC=0x00 TTL=125 ID=27044 PROTO=UDP SPT=50125 DPT=2311 LEN=352

but simple test fails: 'nc -l -u -k -p 2311' shows no incoming traffic. Though, if I explicitly connect (nc -u 10.171.165.65 2311) - it responds (so, address 10.171.165.65 is responsive and active).

According to the diagram https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks , I tried to check whether this traffic appears in inet/prerouting hook (as it seems to be next after netdev/ingress):

table inet prerouting {
        chain just_log {
                type filter hook prerouting priority filter; policy accept;
                iifname inspan log prefix "prerouting " meta nftrace set 1 accept
        }
}

and no, nothing in both syslog and 'nft monitor trace'

rp_filter for inspan interface set to 0; interface promisc mode on/off do not change the whole picture

Any ideas what I'm missing on this last step?

Thank you.

Volodymyr Litovka
  • 123
  • 5
  • 1
    Try using `meta nftrace set 1` in a rule that would match your packet early on and watch what happens to it with `nft monitor trace`. – Ginnungagap Aug 10 '23 at 21:46
  • Ahh, last rule is in action :-) trace id 1142d7fb netdev filter redir rule iifname "inspan" udp dport 1813 ether daddr set d6:ca:cc:cd:bc:47 ip daddr set 10.171.165.65 meta nftrace set 1 log (verdict continue) trace id 1142d7fb netdev filter redir rule iifname "inspan" drop (verdict drop) Thanks. Will look how to accept only matched packets and drop everything else on the specific interface. But may be you have ready recipe? Thank again. – Volodymyr Litovka Aug 11 '23 at 10:16
  • Did you know that (contrary to *iptables*) you can add `accept` after `log`? Now I can't know if you're supposed to move the packet to an other interface or not... – A.B Aug 11 '23 at 11:23
  • Yes, this rule do the part of job (rewrite/accept allowed and drop everything else) - / type filter hook ingress device "inspan" priority filter; policy drop; / iifname inspan udp dport 1234 ether daddr set ... ip daddr set ... accept / But I still can't see these packets in netcat's input on the port. According to doc, netdev ingress is the very first stage and routing decision (whether it's input or forward) will be done after and will use already rewritten header. Do I need to add more hook(s) to explicitly specify local processing of packets? – Volodymyr Litovka Aug 11 '23 at 12:51
  • edited the question, added more details. Thank you. – Volodymyr Litovka Aug 11 '23 at 13:54

1 Answers1

0

The issue wasn't with nftables. The issue is that tunnel interface is not an ethernet interface and tunnel encapsulation is expected, while after traffic was decapsulated from ERSPAN, it's an Ethernet frame.

As soon as I bridged this 'inspan' interface (in my case - into the local OVS bridge), I got this traffic in the running 'nc -l'

Volodymyr Litovka
  • 123
  • 5