udp2raw has stopped working, all the faketcp, icmp, udp have stopped working

[osiaso]

Recently my ISP has filtered all the udp2raw modes,
From today on I tried following configurations and all of them have failed.
It seems the censorship FW has managed to detect and block all the transport methods when the client is going to establish a connection to the server.

Kindly let me know if there is any fix for the issues.

I have tried following configurations and all have failed,
Faketcp,
-s
-l 0.0.0.0:5337
-r 127.0.0.1:5336
-k ********
--raw-mode faketcp
-a
--cipher-mode xor

ICMP

-s
-l 0.0.0.0:4337
-r 127.0.0.1:4336
-k ********
--raw-mode udp
-a
--cipher-mode xor

UDP

-s
-l 0.0.0.0:3337
-r 127.0.0.1:3336
-k *************
--raw-mode icmp
-a
--cipher-mode xor

For each of the modes (ICMP,UDP,FakeTCP) there is a wireguard docker container with corresponding exposed port to
handle the connection between any client and the server based on their preferred connection method (Three WG docker containers).

Having that said all the modes used to work well until few hours ago, once I have restart the server the clients tried to reconnect.
For the UDP,FakeTCP modes and all of them have failed to complete the second handshake and none made a client_ready.

For the ICMP mode made the client_ready connection was establisehd but after few seconds it gets dropped with the following error/warning
state back to client_idle from client_ready bc of server-->client direction timeout

As a result the wireguard interface is unable to instantiate with the server remoted docker container and the VPN fails to work.

I have tried following configurations with different modes and all of them failed.

Changing the MTU of the Wireguard interface to 1332,1280,1200,1342 ----> All of them failed
Changing the --seq-mode for both client and server side of the udp2raw to value 2 (--seq-mode 2) for all modes (FakeTCP,UDP,ICMP) ---> all of them have failed

trying --fix-gro on both server/client sides for all the modes ---> didn't work

I am wondering if there is any configuration that I could try in order to make this tunnel to work properly.
There are some suggestions that the AI of the GFW could detect the connection pattern and block it, therefore it might need some
modifications with the packets such as padding I am wondering if any could recommend any solution to this blockage issue?

[wangyu-]

I don't think it's the "censorship FW" detecting udp2raw.

The traffic is already obfuscated with AES or XOR, with AES the traffic looks like random bits from outside. If you suspect the obfuscation is detected, you can try different --cipher-mode and --auth-mode . But I don't think that's really the case

If fakeTCP is detected by censorship, it's possible since anyway it's not real TCP. But in your case UDP also stops working. udp2raw's UDP mode is not fakeUDP, it's completely legit UDP traffic. Which makes me believe "censorship FW" is not the case even more.

If all the 3 modes stop working together, it's very likely some bigger problem that's not limited to udp2raw, it's possible your environment's problem. I would suggest you troubleshoot your enviroment, e.g. try if other tunnels works on your environment.

[wangyu-]

By the way, I realized your account is registed less than 1 hour before you post the issue...
Could you use your main account if you have one?

[osiaso]

@wangyu-
I have checked my server VPS setup from two places,
Let's call my first VPS udp2raw server that used to work fine as udp2raw-server-vps-old

In my first attempt I setup another VPS server abroad which comes with not-filtered internet, let's name this VPS instance udp2raw-client-vps-new.

That said, I was able to connect from udp2raw-client-vps-new to udp2raw-server-vps-old without any issues (I got server_ready log on the server side and client_ready on the client side) using both udp and icmp modes.
Both modes worked fine with no issue.

So, I confirmed that my udp2raw-server-vps-old server is a functioning server.

In the second scenario I tried to connect my router device that I have setup as my wg+udp2raw client to an unrestricted internet via WAN interface, my router worked fine and connected to udp2raw-server-vps-old for both modes icmp and udp with no issue.

So, I confirmed that my router setup and configuration is working fine too.

I was only suspected to the my ISP-Filternet which has upgraded its restriction rules and has managed to interfere/block/drop my router connections to the udp2raw-server-vps-old server.

In addition I checked whether the VPS provider of the udp2raw-server-vps-old might have blocked connections from my public ISP-Filternet but I was able to ssh and connect to my udp2raw-server-vps-old server directly from the ISP-Filternet.

In addition I have tried another ISP-Filternet with different public ip and the result were the same.

Furthermore I made another VPS server to work as another udp2raw-server-vps-old server but with different public IP offered from VPS provider since I was suspecting that the VPS provider has blacklisted my_ISP-Filternet_ public ip to connect to my udp2raw-server-vps-old public ip address but even the new instance of the udp2raw-server did not worked.

I am almost certain that the blockage is from the ISP-Filternet side.

I got into conclusion that the censor-FW has managed to interrupt and block udp2raw.

following you could read the logs for the udp mode (on the router when WAN is connected to the ISP-Filternet),
(re)sent handshake1
auto added iptables rules
source_addr is now 10.13.13.3
using port 24640
state changed from client_idle to client_pre_handshake
(re)sent handshake1
(re)sent handshake1
(re)sent handshake1
new packet from 127.0.0.1:51820,conv_id=4f9ab6f1
(re)sent handshake1
(re)sent handshake1
state back to client_idle from client_handshake1
source_addr is now 10.13.13.3
using port 18553
state changed from client_idle to client_pre_handshake
(re)sent handshake1
(re)sent handshake1
(re)sent handshake1
(re)sent handshake1

By the way I have tried your recommendation and done following on the server side,
-s
-l 0.0.0.0:4337
-r 127.0.0.1:4336
-k *******************
--raw-mode udp
-a
--fix-gro
--cipher-mode aes128cbc
--auth-mode hmac_sha1

And I get following logs on the server side, (repeats again and again every five seconds)

created new conn,state: server_handshake1,my_id is 59b35775
changed state to server_handshake1,my_id is 59b35775
received handshake oppsite_id:5b9f06de my_id:59b35775
oppsite const_id:4c900267
grabbed a connection
got packet from a new ip
created new conn,state: server_handshake1,my_id is c6ff12f2
changed state to server_handshake1,my_id is c6ff12f2
received handshake oppsite_id:556f8467 my_id:c6ff12f2
oppsite const_id:4c900267
grabbed a connection
inactive conn cleared

I would like to hear about any suggestion that could solve this issue.
I am wondering if there could be any solution available for this Filternet censorship.