Re: does nft 'tcp option ... exists' work?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



FYI, I upgraded the router to OpenWrt 23.05.2 with 5.15.137 and it
doesn't appear to have changed anything, ie. 'tcp option fastopen
exists' still does not appear to match.

Also note that I'm putting this in table inet filter postrouting like
below... but that shouldn't matter should it?

root@mf286a:/usr/share/nftables.d/table-post# cat disable-ipv4-fastopen.nft
chain postrouting {
type filter hook postrouting priority filter; policy accept;
meta nfproto ipv4 oifname "464-xlat" tcp dport 853 tcp flags syn /
fin,syn,rst,ack counter tcp option fastopen exists counter drop
comment "Drop Outbound IPv4 TCP FastOpen"
}

On Sun, Dec 3, 2023 at 4:24 AM Maciej Żenczykowski
<zenczykowski@xxxxxxxxx> wrote:
>
> (ran into this while debugging
> https://bugzilla.redhat.com/show_bug.cgi?id=2252550 &
> https://forum.openwrt.org/t/how-to-block-outbound-ipv4-tcp-fast-open/179518
> )
>
> CC'ing Florian directly based on:
> https://lore.kernel.org/all/20211119152847.18118-6-fw@xxxxxxxxx/
>
> f39vm# tcpdump -i eth0 -nn 'ip and tcp and dst port 853 and
> (tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-fin|tcp-rst) == tcp-syn)'
> dropped privs to tcpdump
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
>
> 03:59:51.539225 IP 192.168.10.2.34324 > 8.8.4.4.853: Flags [S], seq
> 2804210339:2804210653, win 32120, options [mss 1460,sackOK,TS val
> 417951723 ecr 0,nop,wscale 7,tfo  cookie d2f9ee39dc952129,nop,nop],
> length 314
>
> and yet on the OpenWrt 22.03.5, r20134-5f15225c1e (5.10.176) router I see:
>
> meta nfproto ipv4 oifname "464-xlat" tcp flags syn / fin,syn,rst,ack
> counter packets 1 bytes 386 tcp option fastopen exists counter packets
> 0 bytes 0 drop comment "Drop Outbound IPv4 TCP FastOpen"
>
> so AFAICT it sees the SYN, but not the option.
>
> (and yes, if I run it longer the first counter increments exactly when
> tcpdump shows an outbound syn with fastopen, the second counter never
> increments)
>
> btw. this doesn't appear to be limited to the fastopen option.
> Changing 'fastopen' to 'mss'/'maxseg' or 'sack-perm' or 'nop' also
> does not appear to result in it matching and the post match counter
> does not increment...
>
> I understand "tcp option fastopen exists" translates to:
> inet
>   [ exthdr load tcpopt 1b @ 34 + 0 present => reg 1 ]
>   [ cmp eq reg 1 0x00000001 ]
> (but I don't know how to read that)
>
> Is there perhaps some minimal kernel version dependency for the above?
> (but if so... why does the ruleset even load into the kernel)
>
> - Maciej





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux