Feature request: firewall_type: SCRIPT

[PaulGWebster]

Good day,

I understand there was some trouble getting miniupnpd working with ipfw, so I would like to suggest a small work around, though this workaround would really solve quite a few problems in a rather hacky way.

I would like the ability to specify a firewall type of 'script' in the event this happens a path to an executable script is given, when an event occurs or a lookup is required, as expected the script is executed with any arguments that are availible.

My thought personally was making a perl script that could handle all the different calls perhaps reliant on a sqlite database that then dealt with IPFW, though it would not be restricted to just perl or just ipfw, I imagine it would be quite helpful in a number of situations.

Perhaps having it as a free standing option so even users of pf could have such ability, for logging or debugging?

[miniupnp]

ipfw support was not updated for a long time. I guess nobody really uses it.

not launching scripts is the reason I developed miniupnpd in the first place.

[PaulGWebster]

Myself and a few users on #freebsd on freenode would really like to use IPFW over PF due to performance issues, but we run residential gateways that really require miniupnpd, I remember speaking with you years ago about the trouble finding the calls required to get miniupnpd working with IPFW,

So I assumed a singular script type call system would be a nice workaround with the possibility of uses for other users as well in the case of logging, if you was to make a call out to -S /some/arbitrary_script/path a reality I would happily develop a perl script to be able to sanely understand the arguments it was passed.

It would really allow the admittedly few of us that do use IPFW a way to integrate, plus it is not really forcing miniupnpd to be 'script based' more a temporary work around for when there is no other solution.

[miniupnp]

I would prefer if someone could update/fix the current ipfw code in miniupnpd that has not been updated for something like 10 years ;).

There is already a branch supporting calling scripts : https://github.com/miniupnp/miniupnp/tree/ix2015

[miniupnp]

There is already a branch supporting calling scripts : https://github.com/miniupnp/miniupnp/tree/ix2015

hum no. it is using telnet or something...

[PaulGWebster]

There is already a branch supporting calling scripts : https://github.com/miniupnp/miniupnp/tree/ix2015

hum no. it is using telnet or something...

hehe as for the IPFW code let me have an ask about in the FreeBSD crowd see if anyone has any ideas, but this will take a bit of digging, most certainly the scripts call would be nice in the mean time :)

[PaulGWebster]

Do you have any notes or such on the IPFW code that is present? something I could directly link people to

[kevans91]

I unfortunately don't have any kind of setup to test this on, but an interested party should start with migrating to the new hotness: IP_FW3 (sockopt). It takes opcodes[0] with quite a bit of flexibility, passed in a similar manner[1] to the existing setup. ipfw(8) appears to set the version of the ip_fw3_opheader (definition [2]) to 1. I note that the versions in the kernel appear to all be 0 at the moment, but that's ok because it'll just find the closest matching handler.

[0] https://cgit.freebsd.org/src/tree/sys/netinet/ip_fw.h#n80
[1] https://cgit.freebsd.org/src/tree/sbin/ipfw/ipfw2.c#n630
[2] https://cgit.freebsd.org/src/tree/sys/netinet/ip_fw.h#n74

[miniupnp]

Do you have any notes or such on the IPFW code that is present? something I could directly link people to

what do you mean ? all ipfw code is there : https://github.com/miniupnp/miniupnp/tree/master/miniupnpd/ipfw

[PaulGWebster]

I unfortunately don't have any kind of setup to test this on, but an interested party should start with migrating to the new hotness: IP_FW3 (sockopt). It takes opcodes[0] with quite a bit of flexibility, passed in a similar manner[1] to the existing setup. ipfw(8) appears to set the version of the ip_fw3_opheader (definition [2]) to 1. I note that the versions in the kernel appear to all be 0 at the moment, but that's ok because it'll just find the closest matching handler.

[0] https://cgit.freebsd.org/src/tree/sys/netinet/ip_fw.h#n80 [1] https://cgit.freebsd.org/src/tree/sbin/ipfw/ipfw2.c#n630 [2] https://cgit.freebsd.org/src/tree/sys/netinet/ip_fw.h#n74

if I could provide you with a server that would be able to run a system suitable for this, do you think you could progress the support?

[paulgwebster-oe]

Well I have a setup I can do it on now \o/, lets see how bad it could be to have type script :)

[trinity-1686a]

I use nftables. I believe miniupnpd would work with my setup, however I don't really like having a software adding and removing rules from my firewall. As nftables has a contept of maps, I'd prefer for miniupnpd to add/remove entries from these, and have my own configuration says what happen when a packet matches the map.

I understand miniupnpd can't accommodate everyone's strange wishes, but having a type script would give me the flexibility of doing exactly what I want

[PaulGWebster]

I should also comment here that if firewall_type script was not to anyones taste firewall_type: SOCKET could work also, same sort of idea different transport.

In effect miniupnpd listens on /var/run/minoupnpd.sock and your perl, python or other thing simply connects to it and listens.

When an event happens like a client requests a port mapping, it is announced on the Socket and well ... yeah then its up to whatever is listening for what to do about it

Over time you could even be really fancy and allow python/perl/whatever to talk back to the miniupnpd daemon if it was so desired