Support obfuscation to work-around ISP blocking

[kim0]

Is your feature request related to a problem? Please describe. Certain countries like Egypt block WG. Would be great to have pluggable obfuscation layers that are integrated without needing to run external complex tunnels

[thedemonium]

A much needed feature in the current realities! I would be very happy (and I think that many will) of such a feature.

[mlsmaycon]

@kim0 @thedemonium can you share a bit more details about the obfuscation layers?

[thedemonium]

can you share a bit more details about the obfuscation layers?

From recent events. We realized that the Wireguard protocol is quite easy to detect. Alternatively, at the same time, when blocking at the provider level, solutions using ShadowSocks continue to work. For example Outline.

It would be very cool. Be able to set a special flag at the level of node-peer settings. If a special flag assigned to it, peer-to-peer connections by passing traffic through the shadowsocks tunnel.

[kim0]

In my mind a great obfuscation layer would

• Be pluggable. We should be able to use any number of plugins to obfuscate. This is bec this is mainly a cat & mouse game.
• Possibly, consider trying using Tor pluggable obfuscation tools (obfs4proxy, meek ...etc)
• Maybe use generic preObfs and postObfs commands to start and stop obfuscation layers (eg start and stop shadowsocks). Ideally, those are tools that can be written in any language (eg external binaries) which get passed some info like what port to listen on ..etc.
• Possibly netbird can use an internal quality monitor to measure if a particular is still working or not, if not, it could try a different one. Also if it's no longer needed, it would switch to the lower overhead of a direct WG connection. This is kind of subtle, but in Egypt they only block the initial WG handshake. So I would typically pass the handshake through shadowsocks, then almost immediately switch the endpoint wg set endpoint to the regular WG server with ss and it would continue working. But we can also imagine a case where obfs1 was working, a user switches wifi networks and the new wifi does not need obfs1 and can use a direct WG connection, or the new network needs obfs2. So I'm suggesting continuous quality monitors across multiple channels (direct, obfs1, obfs2...etc) with overhead information and selecting the best channel that works.

[thedemonium]

In my mind a great obfuscation layer would

• Be pluggable. We should be able to use any number of plugins to obfuscate. This is bec this is mainly a cat & mouse game.
• Possibly, consider trying using Tor pluggable obfuscation tools (obfs4proxy, meek ...etc)
• Maybe use generic preObfs and postObfs commands to start and stop obfuscation layers (eg start and stop shadowsocks). Ideally, those are tools that can be written in any language (eg external binaries) which get passed some info like what port to listen on ..etc.
• Possibly netbird can use an internal quality monitor to measure if a particular is still working or not, if not, it could try a different one. Also if it's no longer needed, it would switch to the lower overhead of a direct WG connection. This is kind of subtle, but in Egypt they only block the initial WG handshake. So I would typically pass the handshake through shadowsocks, then almost immediately switch the endpoint wg set endpoint to the regular WG server with ss and it would continue working. But we can also imagine a case where obfs1 was working, a user switches wifi networks and the new wifi does not need obfs1 and can use a direct WG connection, or the new network needs obfs2. So I'm suggesting continuous quality monitors across multiple channels (direct, obfs1, obfs2...etc) with overhead information and selecting the best channel that works.

This is what I had in mind when I wrote the answer above.

[mlsmaycon]

Great, thanks for the feedback @kim0 and @thedemonium we will review it internally and provide you a feedback soon.

I have another question. We are working on an HTTP (with TLS) relay. Still, I would like to learn more about your experience using Wireguard encapsulated with a similar protocol approach, like this or our current approach with TURN (with TLS)?

That will help us consider this with the current development.

[13653216371]

This is a good idea. WG traffic in China is easily detected and blocked, and supporting confusion would be a good job！

[thedemonium]

Please! Pay attention to this project: https://github.com/amnezia-vpn/amnezia-wg Perhaps your dear developers will be able to use these developments in their project

[thedemonium]

Perhaps this project will help add a function to netbird:

https://github.com/el3xyz/wireguard-linux-compat notWG - obfuscated secure tunnel for Linux 3.10 - 5.14, based on WireGuard

There are several ways DPI can detect WireGurad traffic The handshake initiation, response and cookie message have fixed sizes All messages have 4 byte tag where the first byte indicates message type [1-4] and remaining three bytes are zeroes. Handshake packet header contains sender and receiver indexes which are sent unencrypted and can be tracked. Packet is obfuscated using two techniques Random junk bytes are appended to handshake and cookie packets Packet header is encrypted with blake2s hash of interface public key and random nonce.

[umutzd]

How does placing an option to choose the custom proxy settings/virtual tun ethernet device sound? People can install a tun0 virtual interface that proxies traffic to their own censorship evasion proxy servers to handle it in a very flexible way with constantly changing needs of this field. They can co-locate their servers with their peers too. This way the proxy protocol can be changed easily and is transparent to users/apps. This would allow separation of concerns too, best tools would be used in their respective places. Netbird does what it does best and catching up with censorship evasion at the same time is another huge work. Tor allows you to configure a proxy before reaching internet