search

wangyu- / udp2raw

A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment)
MIT License
7.28k stars 1.17k forks source link

how to configure for wireguard? #466

Open lootoos opened 1 year ago

lootoos commented 1 year ago

WG client: [Interface] PrivateKey = key Address = 192.168.168.10/24 MTU = 1420

DNS = 1.1.1.1

[Peer] PublicKey = key AllowedIPs = 0.0.0.0/0 Endpoint = 193.164.16.243:51820 PersistentKeepalive = 25

WG server: [Interface] PrivateKey = key ListenPort = 51820 Address = 192.168.168.9/24 MTU = 1420

[Peer] PublicKey = key AllowedIPs = 192.168.168.10/24 PersistentKeepalive = 25

How to make udp2raw hide wireguard traffic? How to make "Wireguard over TCP using udp2raw"?

CluelessTechnologist commented 1 year ago

It's pretty easy: https://gist.github.com/hamid-rostami/5ed34fe1948f40685f7035de36be7035

o-alquimista commented 1 year ago

Here's my experience setting up udp2raw to circumvent wireguard blocking:

Notes:

jpmvferreira commented 1 year ago

ping would work, but ssh would hang and fail. This only happens when running udp2raw. I tracked this down to MTU, and got it working by setting MTU to 1332 in the client wireguard configuration.

Interesting, exactly the same thing happened to me, and setting a different value of MTU also solved it. Could you provide some insight as you what is taking place in the backstage that is causing this issue?

Also, seems that we're on board when it comes to overcoming an exclusively restricted campus firewall, abraço!

wangyu- commented 1 year ago

Could you provide some insight as you what is taking place in the backstage that is causing this issue?

the reason is just simply MTU.

udp2raw introduces it's own header for encryption, anti-replay and multiplex. As a result you have to decrease the MTU at upper level to "make room" for the extra overhead. This is not only for udp2raw, this happens for almost all tunnels.

If you need larger MTU, there is indeed an efficient way:

https://github.com/wangyu-/udp2raw/wiki/bypass-mtu-limitation

jpmvferreira commented 9 months ago

Well, actually, let me come back to this and say that this wasn't solved entirely. With an MTU of 1200, SSH works, but it is very unresponsive. It seems like its fine, but then it starts taking quite a while to update, some packets go missing (ping also reports this) and there's a periodic lag that takes place.

Here's the client configuration for Wireguard

[Interface]
Address = 10.1.1.7/32
PrivateKey = <client private key>
ListenPort = 51900
MTU = 1200

[Peer]
PublicKey = <server public key>
AllowedIPs = 10.1.1.0/24
Endpoint = 127.0.0.1:3333
PersistentKeepalive = 15

And here's the client configuration for udp2raw

-c
-a
-l 127.0.0.1:3333
-r <server ip>:443
--raw-mode faketcp
-k <password>
--cipher-mode aes128cbc
--auth-mode md5
--log-level 4

In the udp2raw logs I can see the following output on loop

Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]received syn,sent syn ack back
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]got packet from a new ip
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]created new conn,state: server_handshake1,my_id is 3ed1dcee
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]changed state to server_handshake1,my_id is 3ed1dcee
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]received handshake oppsite_id:96edccf5  my_id:3ed1dcee
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]oppsite const_id:3889e190
Feb 10 15:05:05 icebox udp2raw[103529]: [2024-02-10 15:05:05][INFO][193.137.168.198:10793]grabbed a connection
Feb 10 15:05:17 icebox udp2raw[103529]: [2024-02-10 15:05:17][INFO][193.137.168.198:10793]inactive conn cleared

which seems to suggest that the connection is consistently dropping and resuming, now my question is, why?

I've tried setting PersistentKeepalive = 5, but it didn't do anything. This connection drop only takes place when one of the machines is behind this specific firewall, not when I'm using my mobile data or using my home connection, for example. Should I try to play around with the cipher mode and auth mode? What do you suggest?