miniupnp: Miniupnpd + nftables does not seem to work properly

should be fixed by @paul-chambers work

Thanks, @4np. Glad those changes fixed the issue, since I didn’t know how I was going to diagnose a problem I couldn’t reproduce. Sounds like I can submit a pull request with a clear conscience 😃

I’ve been testing with NoMachine, Plex Media Server and Zerotier One, on a firewall machine also running firewalld and sshguard with their respective nftables backends.

Yes, that’s the order I’d expect. Strange…

What happens if you do:

table inet filter {
	...
	chain forward {
		type filter hook forward priority 0; policy accept;
		iifname "enp2s0" oifname "eno0" accept
		iifname "eno0" oifname "enp2s0" ct state established,related accept
	}
}
table inet networking {
	chain forward {
		type filter hook forward priority 25; policy drop;
	}
}

I’ll play around with transmission later, after my day job 😃

hmm… I suspect changing your default policy is letting packets through from the filter/forward chain to allow miniupnpd/forward chain to process them too. If they are both the same priority, I doubt there’s a guarantee what order the two chains will be processed in, and if one is default drop, well, the other never gets to see it.

The convention appears to be for all filter chains to be priority 0. I would suggest you leave your forward/filter chain at priority 0 and change the policy to accept, and define another forward chain with a default drop policy, with a decreased priority (e.g. +25) so that all forward/filter chains at priority 0 will see the packets, and and the default drop policy will only apply if no chains at the default filter priority (NF_IP_PRI_FILTER, i.e. zero) handle the packet. Could you give that a try?

I’ve increased the priority of miniupnpd’s forward chain (i.e. making it more negative) to guarantee that it runs before your filter/forward chain. If you would be so kind as to pull and build again, and let me know? thank you

@4np Jeroen, I have something that seems to work, would you like to give it a try?

https://github.com/paul-chambers/miniupnp branch ‘nftables’

I’d like to make sure someone else can replicate my results before submitting the pull request to @miniupnp/Thomas. It’s not a small patch.

You’re right, of course. But where’s the fun in that? 😉

I’m only beginning to get into the code, but already suspect I’ll be making a structural change or two. For one thing, I would like to implement some privilege separation between the front end (UPnP server) and back end (iptables, nftables, etc. support).

The back end has to run with root privileges (or at least CAP_NET_ADMIN) to be able to update the rules, but running userspace code that receives and processes network packets with root privileges makes me a little nervous. Not that the UPnP protocol is exactly a paragon of security, but still…

I’m currently thinking that the classic pipe()/fork() approach and dropping privileges on one of the two processes may be both simple and secure enough. It would also help impose a cleaner boundary between the two, rarely a bad thing.

p.s. I’m also looking to enable remote access to my Plex Media Server 😃

It doesn’t work for me, either. I’m hoping to work on it as my time allows, if no-one else has the bandwidth. It may take me a while, though, spare time is scarce.

I think it would be better to create a separate table for miniupnpd, to keep everything related to miniupnpd separate. Something like this:

table ip miniupnpd {
	chain input {
		type filter hook input priority 100; policy accept;
		tcp dport 32400 ct state established,related,new counter packets 0 bytes 0 accept comment "accept Plex Media Server"
	}

	chain forward {
		type filter hook forward priority 100; policy accept;
		iifname "eno0" oif "enp2s0" ip daddr 192.168.2.10 tcp dport 32400 ct state new accept comment "forward port 32400 to 192.168.2.10"
	}

	chain prerouting {
		type nat hook prerouting priority 100; policy accept;
		iifname "eno0" dnat to tcp dport map { 32400 : 192.168.2.10 } comment "forward port 32400 to 192.168.2.10"
	}
}

Something like this:

# Remove the existing miniupnpd table if present
nft --check list table miniupnpd > /dev/null 2>&1
if [ $? -eq "0" ]; then
	echo "delete table miniupnpd"
	nft delete table miniupnpd
fi

# Create miniupnpd table
nft add table ip miniupnpd
nft add chain ip miniupnpd input '{ type filter hook input priority 100; policy accept; }'
nft add chain ip miniupnpd forward '{ type filter hook forward priority 100; policy accept; }'
nft add chain ip miniupnpd prerouting '{ type nat hook prerouting priority 100; policy accept; }'

nft add rule ip miniupnpd input tcp dport $plex_port ct state new,established,related counter packets 0 bytes 0 accept comment \"accept Plex Media Server\"
nft add rule ip miniupnpd forward iifname $wan oif $lan ip daddr $plex_ip tcp dport $plex_port ct state new accept comment \"forward port 32400 to 192.168.2.10\"
nft add rule ip miniupnpd prerouting iifname $wan dnat to tcp dport map { $plex_port : $plex_ip } comment \"forward port 32400 to 192.168.2.10\"

Unfortunately I have been unable to get this to work. It looks like nftables does not accept the traffic to 32400, even though it is processing the miniupnpd table. Tracing shows continue but not accept (tcp dport 32400 nftrace set 1).