I'm trying to get fwknop working on OpenWrt 22.03.2 r19803-9a599fee93 x86/64.
The problem that I'm facing is:
I can see the SPA packet:
Fri Nov 25 19:45:19 2022 daemon.info fwknopd[3431]: (stanza #1) SPA Packet from IP: xx.xx.xx.xx received with access source match
Fri Nov 25 19:45:19 2022 daemon.info fwknopd[3431]: Added FORWARD rule to FWKNOP_FORWARD for xx.xx.xx.xx -> 0.0.0.0/0 tcp/222, expires at 1669398379
Fri Nov 25 19:45:19 2022 daemon.info fwknopd[3431]: Added DNAT rule to FWKNOP_PREROUTING for xx.xx.xx.xx -> 0.0.0.0/0 tcp/222, expires at 1669398379
but, I get a connection refused on port 222 while trying to ssh into the router. (moved from default port 22 to 222).
tried it with telnet on port 80, same behavior.
The "pkts" count in iptables for this rule is always 0, no matter how many times I try to connect in the allocated interval.
Initially after installing fwknopd I got an error from iptables saying that some "nat" module was not available and I fixed that by installing "iptables-mod-nat-extra".
This was while fwknopd was launched with -v otherwise it would not tell anything.
Where should I look to debug this issue ?
might the problem be ralated to: nftables vs iptables ?
Did you have any luck? Because I'm seeing the exact same thing. Fwiw I had a working fwknop config going back continuously to probably 18.06. It was working fine in 21.02 and it stopped working in 22.03. My assumption is the same as yours: nftables vs iptables. I saw this in 22.03.0 as well, but I figured that's what I get for running a .0, yet it's still happening in .2.
have not worked on the problem in the meantime.
But, it's working on OpenWrt 21.02.3 r16554-1d4dea6d4f , TP-Link Archer C7 v5.
I think I will drop a few versions if this is the only solution for now.
fwknopd is basically useless on "nftables"-style openwrt, unless you add script glue that does the firewall manipulation.
It is not just the iptables/nftables difference, one could have done in openwrt what basically every other non-joke distro did, and have the nftables-compatibility iptables userspace installed.
But openwrt fw4 uses its own table, so it basically and fundamentally cannot interoperate on anything that expects the usual iptables-style chains and tables. If any table or chain does a DROP in nftables, it cannot be overriden to an ACCEPT by some other table/chain, not even a higher priority one.
So, the openwrt fwknopd package in 22.0x is buggy. It needs to add such fwknopd action scripts, and use them instead of the built-in fwknopd iptables manipulation. Even if upstream fwknopd would fix an issue requested more than half a decade ago and add nftables support, it would not help on openwrt due to the fw4 table. We need to add openwrt-specific glue for it to work, and that should be done by the openwrt fwknopd package.
At this point, it probably makes more sense to use a (road-warrior type-) wireguard VPN setup, than fwknop. Like fwknop, wireguard won't respond/ reveal itself unless you have the correct wireguard key, on the pro side, all communication after this handshake will be part of the VPN as well (and is encrypted).
I think I may have a working solution without extra scripts and awkward config. If you install kmod-ipt-nat and kmod-ipt-nat-extra, along with luci-app-fwknopd, the forwarding rules work correctly. I'm not sure if other modes work, but forwarding seemed the most complicated to stitch together with nft rules.
Well, I would rather at least include replay protection into the project before considering it a viable replacement for fwknop. You could however use the project in its current form, it works as is.