- This topic has 55 replies, 3 voices, and was last updated 2 years, 10 months ago by
.
-
Posts
-
First of all thank you for your efforts, I am trying to use wiresock vpn client but I ran into a problem.
Wireguard handshakes are blocked into my country and I used to use another vpn protocol that is not blocked to start the wireguard connection and initiate the first handshake and it works after that.
I can NOT do the same while using wiresock vpn client, it keeps changing the default interface and resetting the tunnel, so is there a way to do the same using wiresock client and start the connection and handshake over the other vpn protocol and drop it after that and keep using wiresock (wireguard) tunnel?Hmm, sounds interesting, however, could you provide some more details about your configuration? I’m not sure I understand how it works… For example, if first handshake packet is discarded by DPI then why the subsequent handshakes (sent every two minutes) are not? Or all outgoing handshakes are dropped, but once tunnel is established the subsequent handshakes sent by the remote peer while DPI does not expect this behavior?
Although, if it works, I think it is a matter of time before the DPI starts dropping handshakes in both directions. And maybe we could come up with a better way to avoid blocking…
I’m using Warp+ (cloudflare’s wireguard) and using wstunnel(websocket) for first handshake and receiving the response then disconnect it.
For some reason the DPI drops the first handshake response only (and even tried same config on my mobile and same thing happened) but after that since connection has been established the handshakes sent and received without problems.Maybe the first handshake goes outside the tunnel but once tunnel established the handshake response goes through the tunnel or first handshake has different response(signature)!! Just guessing and I could be wrong.
Since Wiresock client is implemented very similar to Windows version of Warp then I think it should be feasible. But I need a better understanding on what is going on. Could you post a link to the wstunnel you have used? There are at least two different wstunnel projects on github…
Thank you for your time.
I’m sorry if I didn’t explain it better (my English is not that good), but I am using warp+ *config* on the official wireguard client for windows (v0.5.2) not Warp app by cloudflare.
As for wstunnel it comes as part of vpn client (windscribe vpn) so I can’t determine exactly which version it is (it could be erebe’s implementation).
Sorry again for the confusion.Is there any chance to have a parameter that can be passed to wiresock so that it filter specific interface (ex: WiFi) and not change automatically to the tap/tun interface created by other vpn client (ex: windscribe) ?
It is possible to bind to a specific network adapter, but in this case it will not be enough, because wiresock depends on handshake and response intercepted at the NDIS layer, and this will not happen if they are sent over a different network interface. I will think if I can change the design to avoid this dependency.
If I understand correctly, you have no server side control as it is a Warp server and therefore cannot use traffic obfuscation like https://github.com/dndx/phantun?
P.S. Just an idea and I’m not sure if it will work out of the box. But what if we configure another server/service to forward obfuscated handshake/response packets between wiresock and Warp+? This is what your secondary VPN service does…
It would be great if we can pass the interface to be filtered and wiresock keep working on top of the secondary vpn for moments without dropping the connection and starting all over again, since wireguard (protocol) design do this as far as I can understand, it is not affected by connection changes (ex: switching between WiFi and mobile data on mobile phone) and wiresock should do this also and continue working.
So that the following scenario should work:
1- (First handshake/response go through secondary vpn)
wiresock <-> wstunnel <-> warp server
2- (Continue normal operation without disconnecting and reconnecting)
wiresock <-> warp serverUnfortunately, I don’t have server side control.
Secondary vpn (windsribe’s wstunnel) adds a default route so it can route all traffic (including warp+ traffic, so that’s why I don’t keep wstunnel connected) through wstunnel and deletes it after disconnecting. I am not sure if I can route handshake/response packets only using the current setup (Wireguard 0.5.2 + windscribe)
But what if we try to get rid of windscribe at all and replace it with simple obfuscation service?
For example, I could add another parameter to wiresock config file:
HandshakeFwd = test.sshvpn.me:52220
If this parameter is present in the config file then:
1. Wiresock client instead of sending handshake packet to Warp server will obfuscate it (add random size header for example) and send to test.sshvpn.me:52220 instead Warp server.
2. Service listening test.sshvpn.me:52220 extracts original handshake and forwards it to Warp+ server. Here we have two options, if DPI blocks only handshake packets we can preserve source IP address and UDP port of the packet so that Warp+ server will send the handshake response directly to the wiresock skipping step 3.
3. If DPI also blocks handshake responses then service forwards handshake from its IP address, receives handshake response from Warp, obfuscates it and forwards to wiresock.
4. Wiresock receives handshake response, optionally de-obfuscates it and sets the tunnel up.
Building such a service application and extending wiresock to use it is not that difficult. If you’re interested, we can try this approach.
It is a really good idea, but that does it mean we have to have control over the handshake obfuscator (ex: test.sshvpn.me:52220) or it can be as simple as socks5 server without obfuscation? As far as I understand that means we have to deploy the new service (obfuscator) on some sort of server.
I’m ready to help you and test this approach.
An interesting idea, probably it would really be possible to use a SOCKS5 proxy (e.g. Dante which supports UDP) for this purpose.
I will try to make some tests or even working demo over the weekend.
Also there is shadowsocks since it has obfuscation plugin, but if I remember correctly it doesn’t work with UDP so that don’t know if it would be possible or not but good to mention.
OK, I will wait for it and test it whenever it is ready.
Thanks in advance.
PS: I would be nice if there is an option to make it only fallback to proxy server after X failed handshakes and log when handshake response received.I am grateful for your patience, regretfully the last few weeks were quite busy. However, I’m also interested in this feature, and I hope I will have time to work on this during the weekend.
FYI, I have finally created the client version which sends the handshake (and receives handshake response) through the configured SOCKS5 proxy server. Meanwhile, it does not support SOCKS5 authentication methods and I have tested it only with local Dante proxy, but it looks promising. I’m going to test it first with external SOCKS5 proxy and if it goes fine, we can check how it works for your environment.
- You must be logged in to reply to this topic.