Checking existence of IPSEC as a meta expression in nftables

Question

Whilst recently setting up a router manually from scratch using Debian, I decided to use nftables along with strongSwan to provide an IKEv2 VPN access into this.

After much frustration along with trial and error, I have finally discovered the correct rules to use with nftables to allow VPN access into the router and the LAN behind it.

In addition to this I wanted to also make sure the router is forwarding traffic back out so that when connected, it does not disrupt Internet access to the connected device (e.g. a smartphone).

I discovered that by using meta ipsec exists accept in the filter input/forward tables, this allows the traffic into the router correctly.

Allowing it via input allows access into the router, and the forward allows forwarding traffic to the LAN.

While these rules work, I'm not sure how secure they are.

Should I be using this meta expression match or should I be matching on anything else? Perhaps anything else that is provided by IPSEC that can be configured through strongSwan?

Answer 1

Actually went ahead and checked since I too was wondering how to translate iptables policy rules to nftables as well.

nftables has a more or less undocumented ipsec match which can be seen in the doc/primary-expression.txt of the nftables repository.

ipsec {in | out} [ spnum 'NUM' ] {reqid | spi}

ipsec {in | out} [ spnum 'NUM' ] {ip | ip6} {saddr | daddr}

An ipsec expression refers to ipsec data associated with a packet.

The 'in' or 'out' keyword needs to be used to specify if the expression should examine inbound or outbound policies. The 'in' keyword can be used in the prerouting, input and forward hooks. The 'out' keyword applies to forward, output and postrouting hooks.

The optional keyword spnum can be used to match a specific state in a chain, it defaults to 0.

Which roughly translates to what the policy module was checking although I didn't actually compare the entire xt_policy and the nft_meta/nft_xfrm to ensure they verify the same things.

All in all, something along the lines of nft add rule ip filter INPUT meta ipsec exists ipsec in ip saddr 192.168.1.0/24 accept should be what you're looking for.

Answer 2

All in all, something along the lines of nft add rule ip filter INPUT meta ipsec exists ipsec in ip saddr 192.168.1.0/24 accept should be what you're looking for.

meta ipsec exists appears to be implied by ipsec in. The rule it successfully parsed without it.