Posted: Sun Jan 21, 2024 23:40 Post subject: WireGuard obfuscation on Windows client ideas
Obfuscation is very interesting feature within WireGuard, what would allow to use of WireGuard from some countries using Deep Packet Inspection.
Over last few days I have been trying to find a way how to run it on a client Windows machine.
The idea was to use Shadowsocks as a proxy: Windows Wg Client <-> Shadowsocks (on Windows) <-> DDWRT WG server. However there are some ambiguities.
1. DDWRT obfuscation documentation says it is using ChaCha6 in one place and ChaCha8 in the other one. While source code mentions ChaCha20.
2. Shadowsocks only has "chacha20-ietf-poly1305" option so this will not work as these are two different things - it is different from ChaCha20.
3. Additionally I am not sure if DDWRT and Shadowsocks use same key length.
Obfuscation is really interesting concept and has a great use case, with probably thousands (if not much more) of potential users.
However difficult to set up on Windows clients.
Please reflect on my ambiguities and share your ideas how to set it up.
Let's make it work for others.
Thanks for the suggestion with travel router. That will work but I am looking for "self-contained" solution. Having read https://github.com/infinet/xt_wgobfs documentation I decided to go check the relay option.
Unfortunately it is not working, but that could be some Linux configuration issue, where I am not capable to fix it.
Sorry for the long description. I try to be precise and specific to get efficient support.
Hope this will lead to creating an instruction for others how to benefit from dd wrt obfuscation.
Herewith what I have done in detail.
1. I test the solution from home using "Client test network" which I have created with a spare DDWRT router TP-Link WDR4300 in Station Mode, wirelessly connected to smartphone for WAN access. The test client network is of course not connected in any way to my main home one. It works great, stable with good speed.
The "Remote network" (home) is set up on Netgear R6400v2. Both routers are running r55003.
See "OBFS sites setup" for network schema. I have partially hidden Remote Network public IP.
2. Activating a tunnel from Windows Client 192.168.1.86 directly (no relay) to Remote network works great at this moment - no obfuscation.
See screenshots "1 DDWRT tunnel router config" and "1 Client config".
3. Turning on obfuscation through Linux relay.
a. I turn on obfuscation on DDWRT in Remote Network and set the key (no screenshot).
b. Windows client 192.168.1.86 got some changes in WG config - see "2 Client config" - basically traffic destination is Linux Relay rather than real WG server.
c. Relay - I have installed Debian 12 as Hyper-V on Windows Client (with LAN IP address) as per the guide https://github.com/infinet/xt_wgobfs documentation.
All went smoothly, iptables added and set as default - tested with blocking some public IP and subsequent ping not working to that address.
Iptables OBFS extension successfully build and installed.
Debian has Internet access, can ping the host (which is Windows Client), host can ping Debian, Debian and Windows Client can ping Remote Network public IP (once enabled of course, as DDWRT blocks it by default).
Added succesfully, no error messages. Remote DDDWRT has the same key configured.
All these 4 iptabels rules are not saved permanently, so every Debian reboot I add them again.
e. Activating a tunnel from Windows Client 192.168.1.86 to Remote network through Debian realy does not work. WG Cleint shows some data sent, but no data received.
4. How to debug it?
I have no experience with Linux, I have spent the last few days on installation, configuration and learning but have reached my limits.
Here are a few ideas / questions / observations:
a. What is RELAY_WAN_IP in iptables rule? Is this Debian WAN 192.168.1.92 in my case?
b. Shall Debian relay use same 51812 port as destination real WG server?
c. Are ipttales well customised to my case?
d. I have tried to add the server rules on Remote DDWRT as described in the guide but that makes no change. I would expect this as GUI probably add these rules during obfuscation configuration for WG.
Bottom line - how can I diagnose it further to find which element is misconfigured?
Last edited by Megrez7 on Fri Jan 26, 2024 11:33; edited 2 times in total