QUIC client fails to connect and keeps retrying (Linux)

[dlotfi]

First of all, thanks for the great tools and the work you’ve put into it, really appreciated 🙏
When running the gfw-knocker client on Linux, the QUIC connection consistently fails to establish and enters a retry loop.
Client and server communication for Paqet works fine, so basic connectivity and setup seem correct.

The server reports no issues and all checks pass:

═══════════════════════════════════════════════════════════════
  HEALTH CHECK
═══════════════════════════════════════════════════════════════

  ✓ GFW-knocker scripts found
  ✓ Python dependencies OK (scapy, aioquic)
  ✓ GFK configuration found
  ✓ QUIC certificates found
  ✓ GFW-knocker is running
  ✓ VIO port 45000 INPUT blocked
  ✓ VIO port 45000 RST DROP in place
  ✓ Internet connectivity: OK
  ✓ Auto-start on boot: enabled

  All checks passed!

Client Logs

Starting GFK client...
WARNING:QuicClient:Attempting to connect to QUIC server...
INFO:QuicClient:UDP cleanup task running!
GFK running. Press Ctrl+C to stop.

INFO:VioClient:Linux mode: using L3 socket
INFO:VioClient:sniffer started
WARNING:VioClient:listen quic:30000 -> violated tcp:45000
INFO:VioClient:NEW DGRAM listen created
INFO:VioClient:<asyncio.TransportSocket fd=8, family=2, type=2, proto=17, laddr=('0.0.0.0', 30000)>
INFO:VioClient:Task QUIC to vio started
INFO:VioClient:Task vio to Quic started
INFO:QuicClient:Quic FAILED to connect
INFO:QuicClient:close all tcp
INFO:QuicClient:QUIC connection lost. exit
INFO:QuicClient:close all tcp
INFO:QuicClient:close all udp
INFO:quic:[c361f21399cd6027] Connection close sent (code 0x0, reason )
INFO:QuicClient:connectivity SystemExit:
INFO:QuicClient:Connection lost:
INFO:QuicClient:close all tcp
INFO:QuicClient:QUIC connection lost. exit
INFO:QuicClient:cancelling error: . Retrying...

[SamNet-dev]

Thanks for the detailed report! Since Paqet works but GFK fails, we can rule out basic connectivity and raw socket issues.

Debugging steps:

1. Verify port configuration matches:

   • On server: sudo paqctl info
   • Note VIO port (default 45000) - client must match exactly

2. Check server is receiving packets:

   • On server: sudo tcpdump -i any port 45000 -n
   • Try connecting from client - if packets appear, server is reachable

3. Check client is receiving response:

   • On client: sudo tcpdump -i any "src host YOUR_SERVER_IP and src port 45000" -n
   • If no packets, response isn't coming back (ISP filtering or routing)

4. Check server logs: sudo journalctl -u gfk -f

Most likely cause: Violated TCP packets reach the server, but responses aren't captured by client's sniffer (ISP filtering unusual TCP flags, or scapy on wrong interface).

Questions:

• Can you share both server and client parameters.py (redact auth code)?
• What's your client network? (Home router, corporate, VPN?)
• Which Linux distro on client?

Since Paqet works for you, you might want to stick with it - it's the recommended option for most users.

[dlotfi]

Thanks for the detailed suggestions.

The configuration matches between the server and the client. I compared both parameters.py files line by line and they are identical. Below is the configuration used on both sides (the actual server IP address and auth code are redacted):

# GFW-knocker parameters - auto-generated by paqctl
# Do not edit manually

vps_ip = "MY_SERVER_IP_ADDR"
xray_server_ip_address = "127.0.0.1"

tcp_port_mapping = {16000: 10809}
udp_port_mapping = {}

vio_tcp_server_port = 45000
vio_tcp_client_port = 40000
vio_udp_server_port = 35000
vio_udp_client_port = 30000

quic_server_port = 25000
quic_client_port = 20000
quic_local_ip = "127.0.0.1"

quic_idle_timeout = 86400
udp_timeout = 300
quic_mtu = 1420
quic_verify_cert = False
quic_max_data = 1073741824
quic_max_stream_data = 1073741824

quic_auth_code = "MY_AUTH_CODE"

quic_cert_filepath = ("/opt/paqctl/gfk/cert.pem", "/opt/paqctl/gfk/key.pem")

tcp_flags = "AP"

This is the tcpdump output on the server (actual IP addresses replaced with MY_CLIENT_IP_ADDR and MY_SERVER_IP_ADDR):

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
04:38:29.112303 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:29.638458 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 1:1421, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:31.647438 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
04:38:32.317448 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:33.074442 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:33.656566 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:35.668412 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
04:38:37.677612 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:39.686523 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
04:38:41.695442 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:51, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 51
04:38:42.096710 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:42.699569 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:43.500752 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:43.704459 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:45.102817 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:45.718486 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
04:38:47.729476 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:48.307686 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:49.077639 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:49.738423 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:75, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 75
04:38:51.747486 ens18 Out IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420

...

And this is the tcpdump output on the client (again, IP addresses redacted):

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
04:38:48.220325 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:48.990507 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:58.017879 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:58.221676 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:58.620607 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:38:59.421059 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:01.024067 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:04.229454 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:04.997144 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:14.017525 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:14.218992 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:14.620579 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:15.422403 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:17.023748 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:20.226658 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:20.998275 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
04:39:30.021191 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420

...

Regarding server logs: there is no unit named gfk in journalctl on my system, so journalctl -u gfk does not return anything.

Both the server and the client are running Ubuntu 24.04.

The client network is a VPS located in Iran (Asiatech). However, I also tested the client from my personal desktop outside Iran, and the behavior was the same.

Let me know if you’d like me to collect additional traces or logs.

[SamNet-dev]

Great debugging, thanks for the tcpdump output - it think revealed the root cause.

In your server tcpdump, outgoing packets show source IP 0.0.0.0:

IP 0.0.0.0.45000 > MY_CLIENT_IP_ADDR.40000

The VIO server was constructing raw TCP packets with IP() (no source IP), so they went out as 0.0.0.0 and got dropped by routers. That's why your client tcpdump shows zero incoming packets.

Fix pushed: IP() → IP(src=vps_ip) in vio_server.py.

Please update or reinstall and keep me posted if it resolves the issue:

sudo paqctl update

or fresh install:

curl -fsSL https://raw.githubusercontent.com/SamNet-dev/paqctl/main/paqctl.sh | sudo bash

[dlotfi]

I updated the server (and the client), and now the tcpdump output on the server looks like this (no more 0.0.0.0). However, the tcpdump output on the client hasn’t changed and the problem still exists.

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
06:59:43.441036 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 1:1421, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:45.450463 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
06:59:46.123394 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 1:1421, ack 4294967295, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:46.324861 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 1:1421, ack 4294967295, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:47.461880 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:49.474433 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:75, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 75
06:59:51.484470 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:52.331283 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 1:1421, ack 4294967295, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:53.106337 ens18 In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 1:1421, ack 4294967295, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:53.495472 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:74, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 74
06:59:55.506453 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:49, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 49
06:59:57.516548 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
06:59:59.526462 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:69, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 69
07:00:01.539416 ens18 Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420

...

[SamNet-dev]

Pushed another fix - added NOTRACK iptables rules for the GFK VIO port.

Paqet uses NOTRACK (bypasses conntrack) but GFK didn't. Without NOTRACK, conntrack tracks the crafted TCP packets, which can cause them to be dropped by the hypervisor's bridge netfilter (common on Proxmox/KVM hosts).

Please update and test again:

sudo paqctl update

After updating, verify the NOTRACK rules are in place:

sudo iptables -t raw -L -n -v | grep 45000

You should see NOTRACK entries for port 45000 in both PREROUTING and OUTPUT chains.

[dlotfi]

I’ve updated both the server and the client, and the NOTRACK rules are in place on the server:

$ sudo iptables -t raw -L -n -v --line-numbers
Chain PREROUTING (policy ACCEPT 1539M packets, 1214G bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      247  298K CT         6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:45000 /* paqctl */ NOTRACK

Chain OUTPUT (policy ACCEPT 1593K packets, 337M bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 CT         6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:45000 /* paqctl */ NOTRACK

Unfortunately, the issue still reproduces.

I also added additional debug logging to the relevant code paths (quic_server.py, quic_client.py, vio_server.py, and vio_client.py) and attached the logs here for reference:

gfk_client.log
gfk_server.log

[SamNet-dev]

Thanks for the detailed logs, I looked over them..

Core Problem: VIO response packets never leave the server

The server log shows it receives your packets and sends responses:

sniff tcp in src=CLIENT:40000 → SERVER:45000 ← client→server WORKS ✓
quic->vio bytes=1420 dst=CLIENT:40000 flags=AP seq=1 ack=0 ← server sends response

But the client log shows zero incoming packets (no "sniff tcp in" lines exist at all):

quic->vio bytes=1420 dst=SERVER:45000 ← sending ✓
(NO "sniff tcp in" lines anywhere) ← receiving ✗

Your client-side tcpdump confirms this only outgoing packets, zero incoming.

From your iptables output:

Chain OUTPUT
1 0 0 CT tcp spt:45000 NOTRACK
↑
0 packets matched!

The OUTPUT NOTRACK rule matched zero packets. This means the VIO server's outgoing crafted TCP packets are bypassing iptables entirely scapy sends via L2 socket (PF_PACKET), which goes directly to the NIC driver and skips netfilter completely.

So why don't the packets arrive?

The packets leave the VM (tcpdump shows "Out"), but the server's hypervisor is dropping them before they reach the internet. Most likely the br_netfilter kernel module is active on the host — when packets cross the bridge from VM to physical NIC, the HOST's conntrack evaluates them. Since VIO packets are crafted TCP (AP flags, no prior SYN handshake), the host's conntrack marks them as INVALID and drops them.

The NOTRACK rules inside your VM only affect the VM's own conntrack, not the hypervisor host's conntrack.

This is why the behavior is identical from both Iran and outside Iran, so the problem is on the server side, not the client side.

Please run these commands on your server and share the output:

lsmod | grep br_netfilter
cat /proc/sys/net/bridge/bridge-nf-call-iptables 2>/dev/null || echo "not found"
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null || echo "not found"

If bridge-nf-call-iptables returns 1, try disabling it:

sudo sysctl -w net.bridge.bridge-nf-call-iptables=0

Then restart paqctl and test again.

Also:

• What hosting provider is your server on? (Hetzner, OVH, DigitalOcean, etc.)
• Is it a VPS or dedicated server?
• Does Paqet still work? If yes, Paqet likely constructs its fake TCP packets in a way that satisfies the hypervisor's conntrack, while VIO's crafted packets (AP flags with no SYN) get flagged as invalid.

This is not a paqctl bu, it's the server's hypervisor/hosting infrastructure filtering outbound crafted raw TCP packets.

[dlotfi]

Appreciate you taking the time to dig into this.

My original VPS is Doprax ProVM. I also tested on two other providers: Contabo and OVH.
All three are VPS instances (not dedicated servers).

Paqet still works on Doprax ProVM VPS (I didn't test it on two other providers).

Other Providers behavior

• Contabo VPS → Same behavior as Doprax.
• OVH VPS → Different behavior: packets are actually visible on the client side, but it still does not work.

Server tcpdump (OVH)

08:53:31.237442 ens3  In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.305685 ens3  Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:1422, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.308165 ens3  Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:77, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 75
08:53:31.414656 ens3  In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.418569 ens3  In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:328, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 328
08:53:31.435794 ens3  Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:232, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 230
08:53:31.797546 ens3  Out IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:31, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 29
08:53:31.911900 ens3  In  IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:33, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 33

Client tcpdump (Iran)

08:53:31.190845 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.352610 eth0  In  IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:1422, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.354963 eth0  In  IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:77, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 75
08:53:31.369381 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:1420, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 1420
08:53:31.372972 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:328, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 328
08:53:31.487896 eth0  In  IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:232, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 230
08:53:31.501299 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:33, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 33
08:53:31.842288 eth0  In  IP MY_SERVER_IP_ADDR.45000 > MY_CLIENT_IP_ADDR.40000: Flags [P.], seq 2:31, ack 0, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 29
08:53:31.866543 eth0  Out IP MY_CLIENT_IP_ADDR.40000 > MY_SERVER_IP_ADDR.45000: Flags [P.], seq 0:33, ack 1, win 8192, options [mss 1280,wscale 8,sackOK,eol], length 33

Server Log (OVH)

Feb 07 08:51:55 vps-9dcf2e10 systemd[1]: Starting paqctl.service - GFW-knocker Proxy Service...
Feb 07 08:51:55 vps-9dcf2e10 systemd[1]: Started paqctl.service - GFW-knocker Proxy Service.
Feb 07 08:51:56 vps-9dcf2e10 paqctl[3608661]: WARNING:QuicServer:Server listening for QUIC on port 25000
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: INFO:VioServer:sniffer started
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: WARNING:VioServer:violated tcp:45000 -> quic 127.0.0.1:25000 ->
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: INFO:VioServer:NEW DGRAM socket created
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: INFO:VioServer:<asyncio.TransportSocket fd=8, family=2, type=2, proto=17, laddr=('127.0.0.1', 35000), raddr=('127.0.0.1', 25000)>
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: INFO:VioServer:Task QUIC to vio started
Feb 07 08:51:58 vps-9dcf2e10 paqctl[3608672]: INFO:VioServer:Task vio to Quic started
Feb 07 08:53:31 vps-9dcf2e10 paqctl[3608661]: INFO:quic:[5b077008d59ee4b2] Negotiated protocol version 0x00000001 (VERSION_1)
Feb 07 08:53:31 vps-9dcf2e10 paqctl[3608661]: INFO:QuicServer:UDP cleanup task running!
Feb 07 08:53:31 vps-9dcf2e10 paqctl[3608661]: INFO:quic:[5b077008d59ee4b2] ALPN negotiated protocol None

Client Log (Iran)

Feb 07 08:53:26 free.online systemd[1]: Starting paqctl.service - GFW-knocker Proxy Service...
Feb 07 08:53:27 free.online systemd[1]: Started paqctl.service - GFW-knocker Proxy Service.
Feb 07 08:53:28 free.online paqctl[28898]: WARNING:QuicClient:Attempting to connect to QUIC server...
Feb 07 08:53:28 free.online paqctl[28898]: INFO:QuicClient:UDP cleanup task running!
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:Linux mode: using L3 socket
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:sniffer started
Feb 07 08:53:30 free.online paqctl[28903]: WARNING:VioClient:listen quic:30000 -> violated tcp:45000
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:NEW DGRAM listen created
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:<asyncio.TransportSocket fd=8, family=2, type=2, proto=17, laddr=('0.0.0.0', 30000)>
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:Task QUIC to vio started
Feb 07 08:53:30 free.online paqctl[28903]: INFO:VioClient:Task vio to Quic started
Feb 07 08:53:31 free.online paqctl[28898]: INFO:quic:[5b077008d59ee4b2] Negotiated protocol version 0x00000001 (VERSION_1)
Feb 07 08:53:31 free.online paqctl[28898]: INFO:quic:[5b077008d59ee4b2] ALPN negotiated protocol None
Feb 07 08:53:31 free.online paqctl[28898]: WARNING:QuicClient:client listen tcp:16000 -> to server tcp:10809
Feb 07 08:53:35 free.online paqctl[28898]: INFO:QuicClient:Quic Established!
Feb 07 08:54:10 free.online paqctl[28895]: client[4] 127.0.0.1: connected to httpbin.org:443

br_netfilter / conntrack checks

Doprax ProVM

$ lsmod | grep br_netfilter
$ cat /proc/sys/net/bridge/bridge-nf-call-iptables 2>/dev/null || echo "not found"
not found
$ cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null || echo "not found"
8192

Contabo & OVH

$ lsmod | grep br_netfilter
$ cat /proc/sys/net/bridge/bridge-nf-call-iptables 2>/dev/null || echo "not found"
not found
$ cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null || echo "not found"
262144

[SamNet-dev]

Thanks for testing across three providers and sharing all the logs this is very helpful for narrowing things down.

Correction: br_netfilter theory was wrong. It's not loaded on any of your providers, so that's not the cause. Appreciate you running those checks.

Doprax & Contabo — hosting infrastructure filtering

The packets leave your server VM (tcpdump shows "Out") but never arrive at the client. Since br_netfilter isn't in play inside the VM, the filtering is happening at the hypervisor/SDN layer — invisible from inside the guest. Many VPS providers use virtual switches (OVS) or host-level conntrack that drops outbound TCP packets that don't belong to an established connection (AP flags with no SYN handshake). This is why Paqet works on these providers — it uses a different underlying network approach that satisfies their infrastructure's stateful tracking.

This is a hosting provider limitation, not a paqctl bug. Unfortunately there's nothing we can configure inside the VM to bypass it.

OVH — this actually looks like it's working?

Looking at your OVH client log, the QUIC handshake completed, the tunnel established, and an application-level connection was proxied to httpbin.org:443. The tcpdump also confirms bidirectional packet flow.

Can you clarify what specifically isn't working on OVH? Did you actually test browsing/traffic through the proxy (e.g., configure your browser to use the SOCKS5 proxy at 127.0.0.1:16000 and try loading a page)? The logs suggest it should be functional.

Recommendations:

• For Doprax/Contabo: Use Paqet instead — it works on these providers and is the recommended backend for most users
• For OVH: GFK appears to work — please verify by actually routing traffic through the proxy and let me know if there's a specific failure

[dlotfi]

When using the OVH server, the GFK SOCKS5 proxy run on the client on port 1090 does not appear to be functioning correctly.

When I test it with curl against YouTube, I get a SOCKS5 connection failure:

$ curl --proxy socks5h://127.0.0.1:1090 -I https://www.youtube.com -v
*   Trying 127.0.0.1:1090...
* Connected to 127.0.0.1 (127.0.0.1) port 1090
* SOCKS5 connect to www.youtube.com:443 (remotely resolved)
* Can't complete SOCKS5 connection to www.youtube.com. (4)
* Closing connection
curl: (97) Can't complete SOCKS5 connection to www.youtube.com. (4)

Additionally, when checking the public IP via:
curl --proxy socks5h://127.0.0.1:1090 https://httpbin.org/ip
it returns my client IP address instead of the server’s IP, which suggests traffic is not being tunneled through the proxy.

I also monitored traffic with tcpdump on both the client and the server while running these curl commands, and no packets were sent or received related to the proxied connections.

For reference, these are the current listening sockets on the client (ss -tunlp):

Netid         State          Recv-Q         Send-Q                 Local Address:Port                    Peer Address:Port         Process                                        
udp           UNCONN         0              0                            0.0.0.0:30000                        0.0.0.0:*             users:(("python",pid=41428,fd=9))             
udp           UNCONN         0              0                                  *:20000                              *:*             users:(("python",pid=41425,fd=9))             
tcp           LISTEN         0              100                          0.0.0.0:16000                        0.0.0.0:*             users:(("python",pid=41425,fd=10))            
tcp           LISTEN         0              4096                       127.0.0.1:1090                         0.0.0.0:*             users:(("microsocks",pid=41401,fd=3))         
tcp           LISTEN         0              4096                               *:22                                 *:*             users:(("sshd",pid=983,fd=3),("systemd",pid=1,fd=161))

For comparison, using paqet on port 1080 works as expected:

• YouTube returns HTTP 200
• httpbin.org/ip returns the server’s IP

[SamNet-dev]

This might be the root cause the SOCKS5 proxy on port 1090 (microsocks) bypasses the GFK tunnel entirely.

microsocks is a standalone SOCKS5 proxy that routes traffic directly to the internet with zero awareness of the QUIC tunnel. That explains all the symptoms:

• httpbin.org/ip returns your client IP — microsocks connects directly, not through the tunnel
• YouTube returns SOCKS5 error 4 — microsocks tries to reach YouTube directly from Iran, gets blocked
• No tcpdump traffic on VIO ports during curl tests — the tunnel is never used

Your OVH logs actually show the tunnel works:

INFO:QuicClient:Quic Established!
client listen tcp:16000 -> to server tcp:10809

The correct SOCKS5 port should be 16000 (your VIO port from tcp_port_mapping), not 1090. Port 16000 tunnels through QUIC to xray's SOCKS5 inbound on port 10809 on the server.

Can you test this on your OVH setup:

curl --proxy socks5h://127.0.0.1:16000 https://httpbin.org/ip

This should return the server's IP.

A fix has been pushed — the client wrapper no longer starts microsocks, and all displays now show the correct tunnel port. To pick it up:

sudo paqctl update

After updating, sudo paqctl info and sudo paqctl health will show port 16000 as your SOCKS5 proxy.

Regarding Doprax/Contabo: those providers' infrastructure drops the VIO packets before they leave the hypervisor (confirmed by your tcpdumps showing zero inbound packets on the client). That's a hosting limitation — use Paqet on those providers.

[dlotfi]

Thank you so much for sticking with this and putting in the effort to help me troubleshoot. I really appreciate it. It’s finally working! 🎉️

Now both Paqet and GFK work, although Paqet seems faster and more stable on my VPS in Iran.