On Fri, Jan 12, 2024 at 07:35:14PM +0100, Michel Verdier wrote: > meta l4proto udp log level info prefix "udp" accept
Thanks for that, and thanks to Michael Kjörling, your replies really helped. I found log lines similar to: 2024-01-12T19:51:32.999346+01:00 pi kernel: [3401524.305759] ralphfilterudpIN=en2 OUT=en2 MAC=08:00:1e:02:00:02:6c:cf:39:00:42:f4:86:dd SRC=2a02:0ab8:redacted DST=2a00:63c1:redacted LEN=96 TC=0 HOPLIMIT=63 FLOWLBL=279176 PROTO=UDP SPT=40840 DPT=123 LEN=56 with interestingly IN and OUT interfaces the same en2 (=dmz). And to my surprise, I found a double IPv6 default route: default via fe80::e25f:b9ff:fe1e:a100 dev ppp0 proto ra metric 1024 expires 1791sec hoplimit 64 pref medium default via fe80::a00:1eff:fe01:0 dev en2 proto ra metric 1024 expires 1588sec hoplimit 64 pref medium Now I don't understand why pings/ICMP and tcp traffic seem to decide for the correct route via ppp0 and only udp sems to prefer the one via en2, but when I delete it, everything works. So while nftables might still contain some problematic stuff, at the core of my problem seems to be routing. I "only" have to find out what mechanism adds the lower, en2 default route within a few minutes, once I delete it. I ran "radvdump", but that only dumped the correct announcement my provider sends for the net over the PPPoE connection. Hm. Thanks everybody, of course hints on how to find out what's adding default routes would also be appreciated ;) Ralph
