- This topic has 11 replies, 3 voices, and was last updated 1 year, 4 months ago by
.
-
Posts
-
From the main page at wiresock.net:
“SOCKS5 for WireGuard handshake. The easiest way to block WireGuard VPN is based on identifying handshake and handshake response packets (both fixed length and known format). This feature allows these packets to be passed through a SOCKS5 proxy, making identification more difficult. Note that only the handshake and handshake response packets go through the SOCKS5 proxy, all other tunnel packets are sent directly.”What kind of SOCKS5 proxy setup would you recommend for this? Do you just mean adding a normal proxy layer such as mitmproxy in SOCKS5 mode, or do you mean actively intercepting and modifying the handshake packets?
Wiresock VPN Client implements this feature via additional parameters:
- Socks5Proxy – specifies SOCKS5 proxy endpoint, e.g. Socks5Proxy = socks5.sshvpn.me:1080 or Socks5Proxy = 13.134.12.31:1080
- Socks5ProxyUsername – specifies SOCKS5 username (optional)
- Socks5ProxyPassword – specifies SOCKS5 password (optional)
Wiresock operates by establishing a connection to the indicated SOCKS5 proxy. This involves associating a UDP endpoint and transmitting handshake packets through the SOCKS5 UDP tunnel. The handshake response emerges from the same tunnel. However, all subsequent data traffic is routed directly to the intended WireGuard endpoint.
Although the methodology is quite straightforward, it adds a layer of complexity to the WireGuard handshake and response process, making it more challenging to detect and subsequently block the tunnel.
I understand, my question was more regarding which SOCKS5 proxy to use for this, that WireSock would connect to. If it’s specific or any SOCKS5 proxy would be efficient, such as https://mitmproxy.org
Also, correct me if I’m wrong but in this case you are saying the SOCKS5 proxy should be remote (possibly under the same machine of the VPN server), not local correct? Otherwise if it was local you would be sending handshakes via your own internet connection?
Yes, you’re absolutely correct. The SOCKS5 proxy should indeed be remote, preferably residing on the same machine as the VPN server. This configuration ensures it is beyond the DPI (Deep Packet Inspection), thus facilitating pass-through.
Thank you!
Last question about that. Does this help at an end-to-end level? Such as at the client and at/after the server? Or would the DPI done here happen hop-to-hop, and the advantage would be to avoid like firewalls before the wireguard server?
I’m not entirely sure if I have accurately comprehended your question. The premise seems to be that when tunneling the Wireguard handshake via SOCKS5, Deep Packet Inspection (DPI) will observe the handshake and handshake response packets with an additional SOCKS5 header appended. This extra layer increases the complexity of accurately identifying the nature of these packets.
I suppose my question was where does this protection against DPI occur. Does it help against Wireguard detection at the sender, the receiver, or only in between them (such as for passing through the GFW)?
The purpose of this DPI protection is to mask the WireGuard handshake from the DPI system that sits between the WireGuard peers.
Sorry to bother, but does SOCKS5 proxy server actually requires to be on the same server where WireGuard is?
I’m trying to connect to WireGuard VPN server through Wiresock using proxified handshake on another server.
The connection establishes, but then Wiresock says[TUN]: keep_alive_thread: Tunnel seems to be down., trying to reestablish the connection over and over again. And there’s no actual connection.
If I use direct handshake without proxy, the connection works just fine.Sorry to bother, but does SOCKS5 proxy server actually requires to be on the same server where WireGuard is?
No, it’s not mandatory for the SOCKS5 server and the WireGuard (WG) server to operate on the same machine; they can indeed function on separate systems. In fact, I currently have such configurations in operation. However, it’s vital to underline that the SOCKS5 server MUST support UDP ASSOCIATE. Unfortunately, most ‘free’ SOCKS5 servers do not enable this feature.
- You must be logged in to reply to this topic.