(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