Static route via nftables firewall

I have a gateway "X" with 2 NICs

enp0s3 (192.168.0.100) connected to 192.168.0.0/24 (let's assume this is a WAN network)

enp0s8 (172.16.0.1) connected to 172.16.0.0/24 (presumably a LAN network)

I have created a NAT connection using nftables to allow hosts in the LAN (172.16.0.0/24) browse the internet via the gateway "X".

/etc/nftables/nftables_firewall

flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state {established, related} accept
    ct state invalid drop
    iifname lo accept
    iifname enp0s8 accept
    ip protocol icmp accept
    reject
  }

  chain forward {
    type filter hook forward priority 0;
    oifname enp0s3 accept
    iifname enp0s3 ct state related, established accept
    iifname enp0s3 drop
  }

  chain output {
    type filter hook output priority 0;
  }

}

/etc/nftables/nftables_nat

flush ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 0;
    oifname enp0s3 masquerade
  }
}

Now, I need a host (192.168.0.101) which is a laptop from the WAN (192.168.0.0/24 network) to access hosts in the LAN (172.16.0.0/24 network) via the gateway "X". i.e. I need to configure a static route from this host (192.168.0.101) in the WAN to the LAN (172.16.0.0/24 network).

This is the static route I am trying to add on the laptop that is on the 192.168.0.0/24 network via its wlo1 interface

ip route add 172.16.0.0/24 via 192.168.0.100 dev wlo1

The rules in the gateway firewall are blocking these packets from entering the 172.16.0.0/24 network.

How do I allow this on my gateway?

I know the packets are being dropped by the firewall rules because

testing with

ping 172.16.0.2 

from 192.168.0.101 while running

tcpdump -lnni any src 192.168.0.101

from the gateway "X" replies

11:41:53.240815 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 1, length 64
11:41:54.243947 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 2, length 64
11:41:58.247687 ARP, Request who-has 192.168.0.100 tell 192.168.0.101, length 46

Your two rulesets have a flaw:

flush ruleset

If both are executed in sequence, because of flush ruleset only the last will remain.

Each flush ruleset should should be changed into respectively:

table inet filter
delete table inet filter

and:

table ip nat
delete table ip nat

to get each time an idempotent table definition that won't fail at first use nor duplicate itself nor affect the other table.

Now about the question, it's as simple as inserting a forward rule to allow this at the right place: before the drop rule, so either of:

# nft insert rule inet filter forward index 2 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

or else:

# nft add rule inet filter forward index 1 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

to test,

or else directly by editing the ruleset at the right place to keep it:

...
iifname enp0s3 ct state related, established accept
ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept
iifname enp0s3 drop
...

The rule can be optionally added a iifname enp0s3 (=> iifname enp0s3 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept) for extra safety.

The return traffic is already handled by the stateful rule (... ct state related, established ...).