QBelt clients connect successfully but have no network connectivity because QVPN does not populate the VPNNAT chain

English Networking
1

My Environment

  • NAS: QNAP TS453

  • QTS: 5.2.9.3499

  • QVPN Service: 3.3.1552

  • VPN Protocol: QBelt

  • Android QVPN Client: 1.8.11.0206

  • Android 15

  • Also reproduced on Android 8

Problem description

QBelt clients connect successfully and authentication completes without errors.

The client receives a valid VPN address from the configured pool (10.6.0.2), but no traffic passes through the VPN tunnel.

Symptoms include:

  • Unable to reach the NAS by its LAN IP address.

  • Unable to reach any other LAN device.

  • Unable to reach the Internet.

  • DNS lookups fail because no IP connectivity exists.

  • The QVPN client nevertheless reports “Connected successfully”.

The problem is identical on two different Android devices and Android versions.

Investigation performed

The following was verified on the NAS:

QBelt interface exists

qtun
10.6.0.1/24
UP

Client receives correct address

10.6.0.2

Routing table

The routing table correctly contains:

10.6.0.0/24 dev qtun
default via 192.168.1.1 dev eth0

Therefore:

  • Tunnel creation works.

  • Authentication works.

  • Address assignment works.

  • Routing exists.

iptables

The FORWARD chain contains no rules involving qtun.

More importantly:

iptables -t nat -L

shows:

Chain VPNNAT (1 references)

but no rules at all inside the chain.

Temporary workaround

Executing the following command immediately restores full VPN functionality:

iptables -t nat -A VPNNAT -s 10.6.0.0/24 -o eth0 -j MASQUERADE

Immediately after adding this rule:

  • LAN access works.

  • Internet access works.

  • DNS works.

  • QBelt operates normally.

This strongly suggests that QVPN Service fails to populate the VPNNAT chain automatically.

Expected behaviour

When QBelt starts, QVPN Service should automatically install the required NAT/MASQUERADE rule(s) for the configured VPN subnet.

Actual behaviour

The VPN tunnel is established correctly, but the VPNNAT chain remains empty, preventing any traffic from leaving the VPN interface.

Questions

  1. Is this a known issue in QVPN Service 3.3.1552?

  2. Under what conditions does QVPN fail to populate the VPNNAT chain?

  3. Is there an official fix or workaround?

  4. Is this corrected in a newer release?

I would appreciate confirmation from other users whether they can inspect their systems and verify whether the VPNNAT chain is populated correctly when QBelt is enabled. On a working system, I would expect at least one MASQUERADE rule for the QBelt subnet.