[SOLVED] wireguard server not reachable with active nftables

General Discussion
1

Hi, I noticed that on my raspberry with the wireguard server installed, if I activate nftables I cannot connect remotely. If I shut down or disable nftables the connection is ok. In the rules of nftables I have set to accept incoming connections on the “wg0” device (created by wireguard) and the range of ip addresses connected to it, but it doesn’t work. Do you have any idea why? I am attaching the nftables configuration:

flush ruleset

table inet my_table {
        chain my_input {
                type filter hook input priority 0; policy drop;

                iif lo accept comment "Accept any localhost traffic"
                iif "eth0" ip saddr { 192.168.0.0/16 } accept comment "Accept any localhost traffic"
                iif "wg0" ip saddr { 10.6.0.0/16 } accept comment "Accept vpn traffic"
                ct state invalid drop comment "Drop invalid connections"
                ct state established,related accept comment "Accept traffic originated from us"

                meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"
                meta l4proto icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept comment "Accept ICMP"
                ip protocol igmp accept comment "Accept IGMP"

                udp dport mdns ip6 daddr ff02::fb accept comment "Accept mDNS"
                udp dport mdns ip daddr 224.0.0.251 accept comment "Accept mDNS"

                udp sport 1900 udp dport >= 1024 ip6 saddr { fd00::/8, fe80::/10 } meta pkttype unicast limit rate 4/second burst 20 packets accept comment "Accept UPnP IGD port mapping reply"
                udp sport 1900 udp dport >= 1024 ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } meta pkttype unicast limit rate 4/second burst 20 packets accept comment "Accept UPnP IGD port mapping reply"

                udp sport netbios-ns udp dport >= 1024 meta pkttype unicast ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept Samba Workgroup browsing replies"
                udp sport netbios-ns udp dport >= 1024 meta pkttype unicast ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept Samba Workgroup browsing replies"

                counter comment "Count any other traffic"
        }

        chain my_forward {
                type filter hook forward priority 0; policy drop;
                # Drop everything forwarded to us. We do not forward. That is routers job.
        }

        chain my_output {
                type filter hook output priority 0; policy accept;
                # Accept every outbound connection
        }

}
2

To be honest, I have no knowledge in this topic, but I’m very interested and read a bit about nftables and how to config it for the use with wireguard.
I stumbled upon this, and it’s seems like you have a typo iif “lo” accept (you’re missing the quotation marks) and you are also missing this:

# accept all WireGuard packets received on a public interface
        iif $pub_iface udp dport $wg_port accept

where the $pub_iface is probably eth0? and the $wg_port is your wireguard ListenPort.

There is also other stuff in this tutorial but I do not understand fully :slight_smile:

3

The “wg0” interface exists (this is created by wireguard itself). Even if the “lo” interface is not listed, the local connection works (ssh, vnc, scp, etc). Only connecting to wireguard with nftables running does not work.
I have now tried to modify the nftables.conf by inserting these parameters:

define pub_iface = "eth0"
define wg_port = 51820

in the chain input:

 iif $pub_iface udp dport $wg_port accept

for the moment this seems to be working

4

After a whole day without connection errors I would say that the problem is solved.
Thanks for the suggestions that led me to the solution.