Skip to main content

Tutorial: Managing nftables Settings in Access Server

Abstract

How to manage the nftables settings in Access Server: configure custom nftables rules.

Overview

This tutorial explains how to manage custom nftables rules alongside the firewall rules automatically generated by Access Server 3.1.0 and newer. It's intended for experienced Linux administrators who need behavior beyond what's configurable in the Admin Web UI.

Access Server uses nftables to manage packet filtering, NAT, and routing. While the default rules are sufficient for most deployments, advanced environments may require custom nftables tables or chains.

Prerequisites

  • An installed Access Server 3.1.0 or later.

  • Console access and the ability to get root access.

  • Basic knowledge of nftables and the Linux command line.

Note

In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.

Ensure you replace them with valid IPv4 addresses and subnets for your network(s).

Step 1: Understand Access Server nftables behavior

When using iptables, Access Server prepends its rules to existing rules. Access Server places its generated rules before the existing iptables rules. With nftables, rule order is controlled via hooks and priorities defined on base chains.

By default, Access Server creates several nftables tables and base chains attached to Netfilter hooks with predefined priorities.

Default Access Server nftables tables and chains

Table

Family

Chain

Type

Hook

Priority

as_filter

ip / ip6

FORWARD

filter

forward

0

INPUT

filter

input

0

OUTPUT

filter

output

0

as_nat

ip / ip6

PREROUTING

nat

prerouting

-100

POSTROUTING

nat

postrouting

100

as_mangle

ip / ip6

PREROUTING

filter

prerouting

-150

POSTROUTING

filter

postrouting

-150

Step 2: View existing nftables rules

  1. Connect to the console and get root privilege.

  2. List the full nftables ruleset:

    nft --numeric list ruleset

  3. List a specific table (for example, the as_filter table):

    nft --numeric list table ip as_filter

  4. List a specific chain (for example, the FORWARD chain under as_filter):

    nft --numeric list chain ip as_filter FORWARD

Step 3: Create a custom nftables table and chain (recommended approach)

If you want to add custom nftables rules, the recommended approach is to create your own table and chain, using a hook and priority that determine when your rules are evaluated relative to Access Server’s rules.

Important

  • Custom table and chain names must not conflict with Access Server–generated names.

  • Custom tables must use the ip or ip6 family. Other families aren't supported.

  • Choose priorities carefully to avoid unexpected rule ordering.

For our example, we create a custom FORWARD rule evaluated before Access Server rules. Traffic destined for 192.0.2.5 is accepted before Access Server's FORWARD rules by configuring it with a priority lower than the default (such as 0).

  1. Connect to the server and get root privileges.

  2. Create a custom table:

    nft add table ip brandonfilter

  3. Create a base chain with an earlier priority:

    nft add chain ip brandonfilter FORWARD_EARLY '{ type filter hook forward priority -100; policy accept; }'

    Tip

    This creates a chain called FORWARD_EARLY under the brandonfilter table with hook forward and priority -100.

  4. Add a rule to the chain:

    nft add rule ip brandonfilter FORWARD_EARLY ip daddr 192.0.2.5 counter accept

  5. Verify the configuration:

    nft --numeric list table ip brandonfilter
nft --numeric list chain ip brandonfilter FORWARD_EARLY

    • Example output:

      root@openvpnas:~# nft --numeric list table ip brandonfilter
table ip brandonfilter {
        chain FORWARD_EARLY {
                type filter hook forward priority -100; policy accept;
                ip daddr 192.0.2.5 counter packets 0 bytes 0 accept
        }
}
root@openvpnas:~#
root@openvpnas:~#
root@openvpnas:~# nft -n list chain ip brandonfilter FORWARD_EARLY
table ip brandonfilter {
        chain FORWARD_EARLY {
                type filter hook forward priority -100; policy accept;
                ip daddr 192.0.2.5 counter packets 0 bytes 0 accept
        }
}

Understanding chain priority and rule evaluation

  • If a packet is accepted, and another base chain with the same hook but a later priority exists, the packet continues to traverse subsequent chains.

  • A drop verdict takes immediate effect and stops further evaluation.

  • An accept verdict in an earlier chain can be overridden by a later drop rule in another chain.

For more information, refer to nftables chain priority.

Example: Accept overridden by a later drop

If a packet is accepted by a rule and there is another base chain within the same hook with a later priority that matches and drops the packet, the packet is dropped.

root@openvpnas:~# nft --numeric list table ip brandonfilter
table ip brandonfilter {
        chain FORWARD_EARLY {
                type filter hook forward priority -100; policy accept;
                ip daddr 192.0.2.5 counter packets 15 bytes 900 accept
        }

        chain FORWARD_LATER {
                type filter hook forward priority 100; policy accept;
                ip daddr 192.0.2.0/24 counter packets 4 bytes 240 drop
        }
}

In this case, traffic to 192.0.2.5 is still dropped due to the later chain.

Correct approach: Order rules within the same chain

In this example, you allow 192.0.2.5 and deny the rest of the traffic from 192.0.2.0/24. Configure the drop rule within the same chain as the accept rule:

root@openvpnas:~# nft --numeric list table ip brandonfilter
table ip brandonfilter {
        chain FORWARD_EARLY {
                type filter hook forward priority -100; policy accept;
                ip daddr 192.0.2.5 counter packets 11 bytes 660 accept
                ip daddr 192.0.2.0/24 counter packets 0 bytes 0 drop

Adding custom rules to Access Server-generated tables (not recommended)

Although not recommended, it's possible to insert custom rules directly into tables and chains created by Access Server.

Warning

Custom rules inside Access Server-generated rulesets may be overwritten or affected by upgrades and service restarts.

Example: Add a custom rule to the Access Server FORWARD chain:

  1. Connect to the console and get root privileges.

  2. Stop Access Server services:

    systemctl stop openvpnas

  3. Recreate the table and chain:

    nft add table ip as_filter
nft add chain ip as_filter FORWARD '{ type filter hook forward priority 0; policy accept; }'

  4. Add the custom rule to allow 192.0.2.10:

    nft add rule ip as_filter FORWARD ip daddr 192.0.2.10 counter accept

  5. Verify the rule:

    nft list chain as_filter FORWARD

    • Example output:

      root@openvpnas:~# nft list chain as_filter FORWARD
table ip as_filter {
        chain FORWARD {
                type filter hook forward priority 0; policy accept;
                ip daddr 192.0.2.10 counter packets 0 bytes 0 accept
        }
}

  6. Start Access Server services:

    systemctl start openvpnas

  7. Confirm rules after restart:

    nft list chain as_filter FORWARD

    Tip

    Ensure that both your custom rule and the Access Server-generated rules are present.

    • Example output:

      root@openvpnas:~# nft list chain as_filter FORWARD
table ip as_filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                ip daddr 192.0.2.10 counter packets 0 bytes 0 accept
                counter packets 3663 bytes 1369591 ct state established,related jump AS_ACCEPT
                counter packets 206 bytes 86602 meta mark & 0x02000000 == 0x02000000 jump AS_IN_PRE
                counter packets 0 bytes 0 oifname "as0t*" jump AS_OUT_S2C
        }
}

Summary

  • Access Server uses nftables hooks and priorities to control rule evaluation.

  • Creating custom tables and chains is the safest and recommended approach.

  • Direct modification of Access Server-generated rulesets should be avoided unless absolutely necessary.

  • Always verify rule behavior carefully, especially when mixing accept and drop rules across priorities.

In this section: