I'm trying to set up fwknopd to manage access to a forwarded port (for ssh). Setting up the port forwarding obviously causes the port to be opened without needing any authentication. My question is how and where should I close it so that fwknopd can then temporarily reopen it? This is on OpenWrt 24.10.5.
The port forwarding, set up using luci, happens in the dstnat chain in prerouting.
Allowing established connections through is done in the forward chain. All other forwarded packets are subsequently accepted in forward_lan. So, the logical place to reject forwarded packets is at the start of forward_lan.
I could fairly easily set up scripts to do this and call the scripts from fwknopd but it seems like it should be possible to this without scripting, through either uci or luci. But I cannot see how to do this and don't understand how it would integrate with fwknopd.
This seems like a pretty straightforward requirement (use fwknopd to limit access to a forwarded service), and the ENABLE_IPT_FORWARDING configuration option suggests that this should be doable but I just don't see how.
Suggestions welcomed. Thanks.
__
Marc
You don’t open it at all. Leave it closed (which should be default policy).
Fwknopd listens without open ports and then opens the requested/configured ones.
1 Like
Maybe I misunderstood, but that's quite a loaded question. The port isn't opened by default.
That makes sense to me but I'm struggling with the details. As I see it the firewall needs to do 3 things
- let ongoing established ssh connections through
- forward an incoming port to our ssh host
- temporarily allow new connections from authenticated sources
If we build the port-forward rule from fwknopd, then we can't have it time out (at least not quickly) as we need the forwarding to remain in place for established connections.
I hope I've got something wrong in the above, but if not we will want to build the port forwarding in fw4.
In this case the port forwarding rule will open the incoming port. This means we need to add an explicit rule to reject such packets and apply this after accepting established connections. Fwknopd can then insert a specific short-term accept rule for new connections that is applied before the reject rule.
If I'm making this more complicated than it needs to be, I'm up for a simpler solution.
__
Marc
You and lleachii, to whom I have replied, make similar points. If you can offer more suggestions, I'd appreciate it.
__
Marc
The firewall handles this.
The port forward is only needed to establish the initial connection. Once this has happened and it switches to ESTABLISHED, connection tracking rules take over and as long as it is kept alive by regular heartbeats it should just work even if the port forward rule expires.
I’ve never used fwknopd or looked at the source but this is my assumption of how it works.
You do appear to be over complicating it, have you tried just, using it? Take it at face value and then ask questions then?
2 Likes
Good to know, thanks.
As for just using it, I’m trying. Face value doesn’t tell me anything much about port forwarding. Will try running it on my local server, to eliminate the port-forwarding aspect. Experiments continue…
__
Marc
I now have it working, and will document it in a separate post. The following forum post helped greatly: FWKNOPD on 24.10.2
Also this github repository provided useful insights: https://github.com/sfgets/fwknop-nft
The bottom line is that fsknopd does not support nftables and the luci package to manage fwknopd appears to expect fwknopd to just work with fw4, which uses nftables.
1 Like