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

Follow
Konstantin Tyan

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 container is unprivileged; however, NFQUEUE itself is confirmed to work correctly in the same container. Eastpect initializes normally and registers queues 0/1 when a veth or dummy Ethernet interface is selected. The SIGSEGV is reproducible only when the link/none tunnel interface is selected as the protected interface.

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?

0

Comments

2 comments

Date Votes
  • SVN Support Team

    Hi Konstantin,

    Sorry for the late reply. Could you provide debug logs by following the instructions?

    Increase log level in Settings - Logging - Level - DEBUG4

    After the issue has occurred, zip the logs "tar czvf linux_logs.tar.gz /usr/local/zenarmor/log/active/worker*.log"

    Then please create a support ticket by clicking "Have Feedback" option in the bottom left corner of UI to get the log upload instructions.

     

    Best regards 

    0
    Comment actions Permalink
  • Konstantin Tyan

    Hi,

    I followed your instructions and reproduced the issue again with the logging level set to DEBUG4.

    The problem is still reproducible. With the AmneziaWG in_test interface selected as the protected interface, Eastpect successfully detects the interface and reaches:

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

    followed by:

    NFQ Qnum: 0

    The worker then crashes with signal 11 before Created lan Interface in_test is logged.

    I have created the requested linux_logs.tar.gz archive and also an extended debug archive with the main log and additional NFQUEUE/system context.

    I have now submitted a support ticket through Have Feedback, as requested, and mentioned this Community thread in the ticket.

    I am waiting for the log upload instructions.

    Thank you.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post
Powered by Zendesk