Light experiment worked in blockage

[alizxamax]

I tested light experiment, and the packet reached my VPS
I'm using shatel fibr

[GFW-knocker]

i confirm that it work in iran january-2026 blockage

follow method1 instruction carefully to setup

1. you need root access on both client and server
2. violation port on vps must be blocked by ufw
3. read parameters.py carefully and set your vps ip in there
4. use tmux to run script in background

after running it create tunnel like that:
tcp 14000 --> 443
which mean
client listen on 14000 and every packet goes to client:14000 , reached at server:443

so if your xray config was
vless://uuid@vps_ip:443&.....
you change it to
vless://uuid@127.0.0.1:14000&.....
which 127.0.0.1 is your pc ip that client.py run on it

[alizxamax]

damn this method (میتود) worked 🎉🎉
befor changing the vio_server.py :

I successfully managed to establish a connection using this project on a highly restricted network where almost all other methods (SSH, Ping, Reverse Tunnels) were completely blocked. However, I found two critical bugs in the vio_server.py logic that prevent the sniffer from capturing packets on most VPS environments.

1. Fixed: IP Destination Check (NAT Issue)

In the original code, the sniffer checks for packet[IP].dst == vps_ip.
Problem: Most VPS providers use NAT, meaning the public IP is not directly assigned to the network interface. The packet arrives at the interface with a local/private IP destination, causing the check to fail even if the packet reaches the server.
Solution: Removed the strict IP destination check and relied on the port filter in AsyncSniffer.
2. Fixed: Strict TCP Flag Matching

The code was checking for packet[TCP].flags == 'AP'.
Problem: Depending on the OS and the network path, flags might be ordered differently or contain additional bits.
Solution: Changed the logic to check if both 'P' (Push) and 'A' (Ack) flags are present in the packet, regardless of order.

Updated Logic in vio_server.py:
code Python

def process_packet(packet):
if packet.haslayer(TCP) and packet[TCP].dport == vio_tcp_server_port:
flags = packet.sprintf('%TCP.flags%')
if 'P' in flags and 'A' in flags:
data1 = packet[TCP].load
client_ip = packet[IP].src
client_port = packet[TCP].sport
qu1.put_nowait((data1, client_ip, client_port))

Ongoing Issue: Connection drops after ~30 seconds

Even though the tunnel is now working and data is flowing, the connection consistently drops/terminates after approximately 30 seconds of activity. I am looking for a way to keep the QUIC session or the violated TCP state alive longer. If anyone has insights on adjusting the idle timeouts or keep-alive intervals in parameters.py to fix this, please let me know.

Context & Environment:

ISP: Shatel Fiber (FTTH) - Iran.

Network Status: Extremely restricted. Without a VPN, I had zero connectivity to my server.

    No SSH access.

    No Ping response.

    Reverse tunnels were completely blocked.

Result: This TCP Violation method is the only thing that managed to drill through the firewall and establish a connection to the server.

after fixing vio_server.py: (gemini suggested that)

https://www.speedtest.net/result/18755237793

WARNING:QuicClient:Attempting to connect to QUIC server...
INFO:QuicClient:UDP cleanup task running!
INFO:quic:[0db9640a0c4c3161] Negotiated protocol version 0x00000001 (VERSION_1)
INFO:quic:[0db9640a0c4c3161] ALPN negotiated protocol None
WARNING:QuicClient:client listen tcp:14000 -> to server tcp:443
WARNING:QuicClient:client listen tcp:15000 -> to server tcp:2096
WARNING:QuicClient:client listen tcp:16000 -> to server tcp:10809
WARNING:QuicClient:client listen udp:17000 -> to server udp:945
WARNING:QuicClient:client listen udp:18000 -> to server udp:1014
INFO:QuicClient:NEW DGRAM listen created
INFO:QuicClient:<asyncio.TransportSocket fd=504, family=2, type=2, proto=17, laddr=('0.0.0.0', 17000)>
INFO:QuicClient:NEW DGRAM listen created
INFO:QuicClient:<asyncio.TransportSocket fd=508, family=2, type=2, proto=17, laddr=('0.0.0.0', 18000)>
INFO:QuicClient:creating udp task ....
INFO:QuicClient:Task UDP to Quic started
INFO:QuicClient:creating udp task ....
INFO:QuicClient:Task UDP to Quic started
INFO:QuicClient:Task TCP to QUIC started
INFO:QuicClient:Quic Established!
INFO:QuicClient:Task TCP to QUIC started
INFO:QuicClient:Error forwarding TCP to QUIC: [WinError 64] The specified network name is no longer available
INFO:QuicClient:Task TCP to QUIC Ended
INFO:QuicClient:FIN to stream=4 sent
INFO:QuicClient:Stream=4 closed by server.
INFO:QuicClient:FIN to stream=4 sent
INFO:QuicClient:Error closing stream at client: cannot call write() after FIN
INFO:QuicClient:Task TCP to QUIC started
INFO:QuicClient:Error forwarding TCP to QUIC: [WinError 64] The specified network name is no longer available
INFO:QuicClient:Task TCP to QUIC Ended

[GFW-knocker]

@alizxamax

Quic Established!

special thanks for your feedback.
i add your modified version.
also i'm trying to make it executable or rewriting it with go

do you have npcap or wireshark in your windows?
i wonder if its working on normal windows or need npcap lib

[alizxamax]

@GFW-knocker
Yes, I have npcap and Wireshark.

I also tested the lite experiment on my servers:
Iran → Turkey
and
Turkey → Iran
but it didn’t work.

I’m wondering if I did something wrong.

If it’s possible to run this on a server, it would be much better, since not everyone has root access on their devices. This way, they could use an Iran-based server as an intermediate node.

I’m here and happy to help if there’s anything I can do.
Also, thanks for your method.
A Go version would be appreciated

[GFW-knocker]

@alizxamax

of course its possible to run client on VPS and make tunnel between two servers. that's the main purpose.

to test for iran-turkey :
open some port on turkey ( ufw allow 2096 )
send 'AP' packet from iran to turkey on that port
capture to see if RST packet recieved back in iran ( sudo tcpdump -i any -n -A -vv -s 0 -c 100 port 2096 )

sometimes firewalls or NAT, block port or cant forward properly
changing the port always fix such issues

[GFW-knocker]

if connection suddenly stopped :

reset all NAT state in network path by sending RST packet to server port

from scapy.all import *

# replace with your filtered vps ip
vps_ip = "1.1.1.1"

tcp_options=[
        ('MSS', 1452),  # Maximum Segment Size
        ('WScale', 8),  # Window Scale
        ('SAckOK', ''),  # Selective ACK Permitted
    ]


pkt = IP(dst=vps_ip) / TCP(sport=22345, dport=58934, seq=1 , flags="R", ack=1 , options=tcp_options) / "sample msg"

send(pkt, count=1, verbose=1)

[alizxamax]

if connection suddenly stopped :

reset all NAT state in network path by sending RST packet to server port

@GFW-knocker

Thanks it helped

Also, just so you know, my server is still inaccessible / blocked by my ISP, but it is accessible using the python code

and about running the app on servers inside and outside Iran:

I wanted to run it on both. My server outside Iran is accessible from my Iranian server and isn’t blocked, but I’m trying to test the app using a blocked server

[surbiks]

hi
i check it with 2 vps in 2 different location but not worked. i have unstable icmp and ssh connection to my vps. if i use vpn connection i can see INFO:QuicClient:Quic Established! in logs and work but without vpn not work.

my home internet is ftth

➜  method1 sudo python3 mainclient.py
INFO:VioClient:sniffer started
WARNING:VioClient:listen quic:30000 -> violated tcp:45000
INFO:VioClient:NEW DGRAM listen created
INFO:VioClient:<asyncio.TransportSocket fd=9, 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
WARNING:QuicClient:Attempting to connect to QUIC server...
INFO:QuicClient:UDP cleanup task running!
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:[bc8a05d3ad567fa3] 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...
INFO:QuicClient:close all tcp
INFO:QuicClient:QUIC connection lost. exit
INFO:QuicClient:client is dead. restarting ...
WARNING:QuicClient:Attempting to connect to QUIC server...
INFO:QuicClient:UDP cleanup task running!
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:[7ee9949b2d9fc1ec] 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...
INFO:QuicClient:close all tcp
INFO:QuicClient:QUIC connection lost. exit
INFO:QuicClient:client is dead. restarting ...
WARNING:QuicClient:Attempting to connect to QUIC server...
INFO:QuicClient:UDP cleanup task running!
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:[fc692648cbeff063] 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...

[alizxamax]

@surbiks

Port 40000 must be blocked for both inbound and outbound traffic in the Windows Firewall. "if your client is windows"

Port 45000 inbound must be blocked in the server firewall.

You can change the ports and test with other port numbers as well—just make sure to add those ports to the firewall rules too.

Make sure the service is running inside tmux, so it keeps running in the background even after closing the terminal.

First, test Lite Experiment and check whether the packets are actually reaching the server.

I’m not an expert, but I helped as much as I could based on what I know—hopefully this still points you in the right direction.

[surbiks]

The settings for the port and its blocking in the firewall are correct because if I use the same settings on a network without a filter, it works perfectly. However, if I use it on a network that has filtering, the connection does not occur.

[saonara]

This project implements these methods, and I have been using it for the past week.

hanselime/paqet

[Ahmad-2213]

@GFW-knocker Thanks for the amazing work—really appreciate what you're building.

I'm pretty new to this topic, so sorry if this is basic, but I have a question about one of the main claims: that they simply can't check every single packet in high-speed traffic (unless they spend millions on hardware).

The whole bypass relies on the idea that the GFW is 'naive' and only looks at SYN packets for IP blocks. But if this method gets integrated into something like xray-core or used by a lot of people, wouldn't it become easy to block?

They don't need to inspect every packet at all. They could just add a simple rule: the first packet of any new TCP flow must be a SYN. If it's something else (like ACK or PSH+ACK right from the start), there's no real connection yet—so just drop it immediately.

Am I missing something here? Feel free to correct me if I'm wrong!

[saonara]

@Ahmad-2213
I think tracking every connection state at the scale of a country, or even a data center, is also resource intensive and not easy to manage.

[Ahmad-2213]

@saonara
Thanks for the response.
You're right that full state tracking for every connection at national scale would be extremely resource-heavy and hard to manage.
But the rule I mentioned is much simpler and lighter:
When a new TCP flow starts (no existing state for that IP/port pair), just check one thing — does the very first packet have the SYN flag set?
If not (for example it's an ACK or PSH+ACK), drop it right away and don't create any state entry.
No need to track sequence numbers, windows, retransmissions or the full connection lifetime.
It's basically a quick "wrong starting packet" filter that firewalls already use for invalid traffic.
Very low cost, even at large scale.

So while complete per-connection tracking is impractical, this basic first-packet check is realistic and could easily block the technique if they decide to add it.