Support for pf on FreeBSD?

[stilez]

The docs state that fwknop supports pf on OpenBSD, and ipfw on FreeBSD.

But popular FreeBSD setups often use pf not ipfw. (eg, pfSense for which issue #130 is logged).

Can fwknop be made to also support pf on FreeBSD as well, or, if it does already, can the docs be updated to say so?

Notes:

1. This issue probably blocks #130.
2. If fwknop is compatible with pf on FreeBSD, or becomes compatible, I'm a keen pfSense developer and if not too busy at the time, I'd be happy to help out on making this available.

[mrash]

Sorry for the delayed response. Indeed, fwknop is compatible with pf on FreeBSD. That is, fwknop doesn't really care about whether it is running on FreeBSD or OpenBSD - it just looks for the existence of the pfctl binary in the configure script. The check for ipfw is done first, but this can be overridden with './configure --with-pf=/path/to/pfctl'.

If you are interested in helping with adding pfSense support, this would be fantastic. This has been requested many times, and the fwknop project could certainly use your help in this area.

[stilez]

I'd be very glad to help.

Thinking about this, we need to first pin down how fwknop should work with pfSense - the features to implement and ways to integrate them. Like most sw, fwknop is quite flexible and one has to choose what is neded/desirable to expose in the GUI, how to expose them, and the key + other desirable use-cases it needs to handle. (A freeform box for "other config" is useful but the basic uses should be accessible via dedicated UI fields).

Initially, I think we should get wider input from fwknop users/devs, what they want to see. For example, if there's a fwknop mailing list/channel/forum (devs or users) it might be a good starting point to pose the questions there, and see what devs/users think is needed and what fwknop on pfSense should do.

(I can handle a lot of it - how it integrates, UI, etc. But what functionality should be exposed or is desirable, and what needs to happen in the background to make it so. As one simple example, fkwnop handles certs, but this adds complexity if needed, and if possible I'd like to skip it in a 1st try. But how necessary is this? Avoidable? Only fwknop users can say..... Ditto for whether it's important to be able t knock on one device to open ports on a second device, and how that works if needed. Stuff like that.... and it'll be the same for quite a few other use cases/capabilities. Bear in mind I like the concept of fwknop but haven't yet used it myself "live", so I need to understand enough real-world use to code what's needed :) )

Once some outline ideas emerge, we can set up a temp chat (IRC/IM) to talk around how it'll be implemented/integrated into pfSense, so I can check any specifics, and I'll have a go.

Two other thoughts:

• If this works out, you might want to ask for fwknop users/devs who can help maintain the extension now and then - it doesn't take much, but if an extension becomes outdated/incompatible, it'll be removed on the pfSense side. Keeping it working will be easy once it's set up. If relevant pfSense currently uses CLI "*.php" files and xml, for extensions (calling shell as needed), but they plan to move to Python in the next year or 3 - however not much coding is needed and extensions tend to be very easy to maintain once created.

• Aso, quite useful - can you update the website/FAQ to make it clear that fwknop does work with pf as well as ipfw on FreeBSD? If any pfSense committers check, they'd need to see that info, but right now it doesn't say so anywhere which might raise doubts.

Look forward to hearing back.

[mrash]

I think a good guide for what to implement is Jonathan's work to integrate fwknop into the OpenWRT project. I'm not sure of the latest status of this, but I know it worked quite well a while ago and probably still does. My guess is that we would just need relatively basic support in pfSense to create and manage encryption and HMAC keys, add any qualifiers for ports/protocols to open, etc. Also, the command cycle support could be a nice way of allowing the user to do something more complicated with pf or other things upon receiving a valid SPA packet. We can certainly ask the fwknop mailing list as well for feedback. I'll get the website/FAQ updated as you suggest. Thanks.

[stilez]

I've had a go at figuring a maximal set of options, meaning "unlikely to require beyond these". Obviously not all are necessarily implemented, but it gives me some idea of what might be needed which is helpful. The aim is to avoid a setup where the user gets a bare "enter fwknopd config here:" box, and allow rules to be provided and managed more intuitively. But it could well be overcomplicated or completely off track!! I get a list like this:

Global daemon options:

• disable/enable fwknop extension
• some kind of log level option
• max packet age to accept (seconds)

List of individual rules. Each rule comprises:

• Name + optional descriptive note - this is common for most config on pfSense
• Rule status - enabled, disabled, or testing only. (Testing would report if the knock worked, but not execute any actions)
• Packet criteria for this rule - where received (interface, IPv4/6/both, TCP/UDP/both, src IPs, src ports/ranges); valid usernames; times/days/dates rule is operational (ignored outside these times)
• List of actions to take on successful match could be any of - protocols/ports permitted to be opened + timeouts for closing them again (ports/protocols in pkt will be opened if compatible); or a freeform CLI command or short textbox script to be executed after X seconds

Unsure stuff:

• What if I actually want to connect to a LAN device, so I have kfwnop running on my workstation to protect SSH there, as well as on my boundary to protect the LAN generally. Should there be a way to fwd the pkt, or tell a second connected device to open a port, or is that outside scope?
• Not a clue about the encryption/keys/HMAC/digest aspects of fkwnop, so I'm likely to need to ask /check quite a lot to be clear. Are keys/MAC/digest/GPG data global to all kfwnop rules, or individual per-rule? What about certificates if any - any relevance? Are certs (if any) generated by the user and pasted in as text, or should they be generated by the pfSense "Certificates"/"CA" panels itself, to be copied to the client devices (or indeed both/either)?
• Is this over-complicated?

Just some quick thoughts. Obviously the less that's needed, the simpler it is to write, but this is my impressions from the docs - and could be sensible or could be way off-base!!

[greenmoss]

Hey, I just added a thumbs-up of encouragement for this idea. With new VPN vulnerabilities being found all the time, I'd really love to add this extra protection!

Source: https://media.defense.gov/2019/Oct/07/2002191601/-1/-1/0/CSA-MITIGATING-RECENT-VPN-VULNERABILITIES.PDF

@stilez Anything I can do to help?