bug in Eastpect 2.6.2 when a Linux tunnel interface is selected as the protected interface in NFQ Routed Mode

Hello Zenarmor team,

I found what appears to be a reproducible bug in Eastpect 2.6.2 when a Linux tunnel interface is selected as the protected interface in NFQ Routed Mode.

Environment:

OpenWrt: 25.12.5
Environment: unprivileged Incus/LXC container
Host kernel exposed to container: 6.12.101+deb13-amd64
Zenarmor: 2.6.2
Zenarmor Agent: 2.6.1
Deployment mode: Linux NFQ / Routed Mode
Architecture: x86_64

The problematic interface is a WireGuard/AmneziaWG-style L3 tunnel interface:

in_test: <POINTOPOINT,NOARP,UP,LOWER_UP>
mtu 1420
link/none
inet 10.250.90.254/24

When I select in_test as the protected interface, Zenarmor correctly generates the worker configuration:

0, 1, nfq@in_test, nfq@in_test^, 0, 1, 4343, nfq;routedmode;guest

and creates NFQUEUE firewall rules such as:

-A INPUT -i in_test -m mark ! --mark 0x9ed \
    -j NFQUEUE --queue-num 0 --queue-bypass

-A FORWARD -i in_test -m mark ! --mark 0x9ed \
    -j NFQUEUE --queue-num 0 --queue-bypass

However, the Eastpect worker consistently crashes while initializing the NFQ interface.

The last relevant worker log entry is:

INFO [EastpectInstance::initialize_interface]
lan:in_test[in_test] Queue: 0, #Queues: 1, Packet Device: Netfilter Queue

It never reaches:

Created lan Interface in_test

The supervisor reports:

CRIT [EastpectWorker::WaitWorkers]
Child worker0 ... terminated with signal: 11

This repeats continuously after every worker respawn, approximately every 14 seconds.

signal 11 is SIGSEGV.

While this happens:

/proc/net/netfilter/nfnetlink_queue

has no registered queue listener, so the generated --queue-bypass rules simply fail open.

I then performed an A/B test on the exact same system.

First, I created a veth interface and selected it as the only protected interface. Eastpect initialized successfully:

INFO [EastpectInstance::initialize_interface]
Created lan Interface za_veth1

INFO [EastpectInstance::initialize_interface]
Created wan Interface za_veth1^

INFO [worker_main]
Initialized Eastpect Instance #0

Both NFQUEUE listeners were registered:

0  <worker pid> ...
1  <netlink port id> ...

I repeated the same test with a Linux dummy interface:

za_dummy: <BROADCAST,NOARP,UP,LOWER_UP>
link/ether <MAC address>

Again, Eastpect initialized successfully:

Created lan Interface za_dummy
Created wan Interface za_dummy^
Initialized Eastpect Instance #0

Both NFQUEUE queues were registered and remained stable.

I also verified that an IPv4 address is not required on the dummy interface. Eastpect still initializes successfully with only the automatically assigned IPv6 link-local address.

The most important test was the following.

I kept za_dummy as the only protected interface, so Eastpect could initialize normally, but manually sent packets from the real in_test tunnel interface into Eastpect's NFQUEUE queues:

INPUT   -i in_test -> NFQUEUE 0
FORWARD -i in_test -> NFQUEUE 0

FORWARD -o in_test -> NFQUEUE 1
OUTPUT  -o in_test -> NFQUEUE 1

This worked.

The NFQUEUE counters increased on in_test, while the za_dummy NFQUEUE rule counters remained at zero. Both queue 0 and queue 1 received traffic with zero kernel drops and zero userspace drops.

Zenarmor also successfully classified traffic originating from the tunnel clients and wrote it to conn_all, for example:

src_hostname: 10.250.90.1
app_name: Domain Name Resolution
app_category: Network Management
src_dir: EGRESS

This demonstrates that Eastpect is able to process packets originating from a WireGuard/AmneziaWG-style link/none interface once the NFQ engine has already been initialized using an Ethernet-like interface.

Therefore, the crash appears to be specific to the protected-interface initialization path, not to NFQUEUE packet processing itself.

The observed behavior is:

Protected interface = WireGuard/AmneziaWG-style link/none
    -> Eastpect initialize_interface()
    -> SIGSEGV

Protected interface = veth or dummy/link/ether
    -> Eastpect initializes normally
    -> NFQUEUE 0/1 work

Eastpect initialized on dummy
+ NFQUEUE rules matching real link/none interface
    -> traffic is processed and classified successfully

This suggests there may be an assumption in the NFQ interface initialization code that the protected interface is Ethernet-like, for example related to ARPHRD_ETHER, MAC/L2 metadata, or similar interface properties.

I cannot identify the exact failing code path because Eastpect is a closed binary and no crash dump was generated, but the A/B test isolates the issue quite narrowly.

A current workaround is:

1. Create an unused dummy Ethernet interface.
2. Select only that dummy interface as the Zenarmor protected interface.
3. Let Eastpect initialize NFQUEUE 0/1 on the dummy interface.
4. Use custom NFQUEUE rules for the real WireGuard/AmneziaWG interface.

No real traffic needs to pass through the dummy interface.

Could you please confirm whether ARPHRD_NONE / link/none tunnel interfaces are intended to be supported as protected interfaces in Linux NFQ mode, and investigate the SIGSEGV in the interface initialization path?