neevek
Tunnel UDP
Is UDP over QUIC available? Any way to tunnel wireguard on this setup?
client -> server1 omni client -> server2 omni and wg server
Currently UDP tunneling is not supported, I am working on something related to that though. I am curious about your use case, can you elaborate on that a little bit?
Wireguard directly is blocked and it uses UDP. I use server1 as a middle local server which listens on UDP from client wireguard and sends it as QUIC to abroad server2. udp2raw does it but it's not QUIC.
Wireguard directly is blocked and it uses UDP. I use
server1as a middle local server which listens on UDP from client wireguard and sends it as QUIC to abroadserver2. udp2raw does it but it's not QUIC.
Well this will be supported soon, as the UDP over QUIC part is already implemented in the rstun project, which omnip depends on to support all the over-QUIC tunneling.
Does that mean I can use rstun right now for UDP? I thought it only handles TCP. This part of the readme is why I made this issue:
Does that mean I can use rstun right now for UDP? I thought it only handles TCP. This part of the readme is why I made this issue:
The code that implements UDP tunneling is not merged into master branch yet, the README is also not updated. Anyway I just released a beta version that includes the feature, check it out here and give it a try, it will be great if you can report back later.
It seems like QUIC is blocked on my "internet". These can affect it:
- set fingerprint, for example chrome, firefox or google apps.
- set SNI
If this is in your interest, I can try again with different fingerprint and SNI. It could also be wireguard MTU. What MTU should I set? Currently it's 1420. Here is the log, tunnel is created but packets drop on strict internet.
It seems like QUIC is blocked on my "internet". These can affect it:
- set fingerprint, for example chrome, firefox or google apps.
- set SNI
If this is in your interest, I can try again with different fingerprint and SNI. It could also be wireguard MTU. What MTU should I set? Currently it's 1420. Here is the log, tunnel is created but packets drop on strict internet.
I think it is most probably related to MTU, try setting it to 1200.
The lowest MTU wg accepts is 1280, same log happened with 1280. Also tried shadowsocks TCP with the previous version and the same things happens.
Awesome, it works on 1420 MTU and with great speed. I'm going to put 40 clients on it and see if it gets detected and blocked by DPI.
There are some warnings but I don't know if its a problem.
2024-10-14 00:39:28.228 [rstunc] [rstun::udp::udp_tunnel:145] [W] failed to read for udp, err: unexpected end of file
2024-10-14 04:21:13.228 [rstund] [rstun::udp::udp_tunnel:274] [W] failed to read from udp packet from tunnel, err: unexpected end of file
As a side note, it would be great if dns was moved to options like --dns 9.9.9.9 or --dns https://dns.quad9.net/dns-query. This is too opinionated:
Awesome, it works on 1420 MTU and with great speed. I'm going to put 40 clients on it and see if it gets detected and blocked by DPI.
Good to hear that. By the way, what kind of DPI system you are testing against?
As a side note, it would be great if dns was moved to options like
--dns 9.9.9.9or--dns https://dns.quad9.net/dns-query. This is too opinionated:
Sure, I will fix that in later release.
Government censorships (Iran), but I believe it's the same as China if not worse.
I tried many tunnels such as chisel (ssh), wstunnel (websocket), pingtunnel (icmp) and they all get blocked within days. Some xray/v2ray stuff and udp2raw work but bad performance. Let's see how this one goes 😊
Well, I don't think this one would be that different compared to those you tried in terms of security, many of those use TLS with known cipher suites. It's like normal HTTP 3.
Yes it went out. It was worth trying. It had the highest speed I've seen while it lasted.