Arch Linux

TJM

Member

Registered: 2016-09-18

Posts: 114

NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

I've used the shared network feature of NetworkManager for a long time. There was no problem, until one day NM suddenly switched to nft instead of iptable. Problems occurred since then. First of all, the default nft rules in /etc/nftables.conf forms a whitelist:

#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:

# IPv4/IPv6 Simple & Safe firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.

table inet filter
delete table inet filter
table inet filter {
  chain input {
    type filter hook input priority filter
    policy drop

    ct state invalid drop comment "early drop of invalid connections"
    ct state {established, related} accept comment "allow tracked connections"
    iifname lo accept comment "allow from loopback"
    ip protocol icmp accept comment "allow icmp"
    meta l4proto ipv6-icmp accept comment "allow icmp v6"
    tcp dport ssh accept comment "allow sshd"
    pkttype host limit rate 5/second counter reject with icmpx type admin-prohibited
    counter
  }
  chain forward {
    type filter hook forward priority filter
    policy drop
  }
}

It works well when no open ports are required for a specific system to function. When you active the Hotspot connection, the NetworkManager does add rules for allowing forwards and NAT. However, no input rules are added, which blocks dnsmasq from serve the Hotspot as DHCP and DNS server:

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state invalid drop comment "early drop of invalid connections"
		ct state { established, related } accept comment "allow tracked connections"
		iifname "lo" accept comment "allow from loopback"
		ip protocol icmp accept comment "allow icmp"
		meta l4proto ipv6-icmp accept comment "allow icmp v6"
		tcp dport 22 accept comment "allow sshd"
		meta pkttype host limit rate 5/second counter packets 151 bytes 46203 reject with icmpx admin-prohibited
		counter packets 237 bytes 112747
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
	}
}
table ip nm-shared-wlp3s0 {
	chain nat_postrouting {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
	}

	chain filter_forward {
		type filter hook forward priority filter; policy accept;
		ip daddr 10.42.0.0/24 oifname "wlp3s0" ct state { established, related } accept
		ip saddr 10.42.0.0/24 iifname "wlp3s0" accept
		iifname "wlp3s0" oifname "wlp3s0" accept
		iifname "wlp3s0" reject
		oifname "wlp3s0" reject
	}
}

Is annoying that every time I type it manually to add rules in the input chain. Is there any way to let NetworkManager automate this process?

TJM

Member

Registered: 2016-09-18

Posts: 114

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

Also, I found the "type filter hook forward priority filter; policy drop;" rule in  table inet filter overrides "ip saddr 10.42.0.0/24 iifname "wlp3s0" accept" in table ip filter

TJM

Member

Registered: 2016-09-18

Posts: 114

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

Is this a bug or just something by-design of NetworkManager?

TJM

Member

Registered: 2016-09-18

Posts: 114

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

Is there any documentation on whether inet supersedes ip and ip6? Not sure where to find relative information ¯\_(ツ)_/¯

dbear496

Member

Registered: 2022-05-23

Posts: 5

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

For the record, I am having the exact same issue. I'm not sure where to go to change the nftables rules that networkmanager adds for shared connections.

dbear496

Member

Registered: 2022-05-23

Posts: 5

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

I found where the nftables rules are generated in the networkmanager source code: https://github.com/NetworkManager/Netwo … ils.c#L696. In that function, there is an interesting comment:

/* This filter_input chain serves no real purpose, because "accept" only stops
 * evaluation of the current rule. It cannot fully accept the packet. Since
 * this chain has no other rules, it is useless in this form.
 *
 * _append(&strbuf,
 *         "add chain ip %s filter_input {"
 *         " type filter hook input priority 0; policy accept; "
 *         "};",
 *         table_name);
 * _append(&strbuf, "add rule ip %s filter_input tcp dport { 67, 53 } accept;", table_name);
 * _append(&strbuf, "add rule ip %s filter_input udp dport { 67, 53 } accept;", table_name);
 */

It would appear from this comment that the root of the issue is in how nftables works. The nftables wiki (https://wiki.nftables.org/wiki-nftables … ing_chains) says the following:

NOTE: If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is not true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.

Since networkmanager merely adds a table and since nftables does not treat 'accept' as final, the rules that networkmanager would add are useless. Furthermore, networkmanager cannot necessarily add its rules to an existing chain because it does not necessarily know the name of that table or chain.

So at least for now, it seems that adding the necessary rules manually is the way to go. Perhaps you can create a script to add the rules for you.

dbear496

Member

Registered: 2022-05-23

Posts: 5

Re: NetworkManager forgets to add input rule for dnsmasq when hosting WiFi

This feature request on nftables seems relevant: https://bugzilla.netfilter.org/show_bug.cgi?id=1471. If such a feature were implemented, then networkmanager could use it to accept dns and dhcp packets without being clobbered by a default deny firewall policy.