Traffic obfuscation

[ghost]

Hello! Interested to see if it's possible to add some sort of obfuscation. My ISP DPI detects Glorytun every few days and throttles it down to 1kb/s, I have to swap AES-GCM and chacha20 every few days to get it back working. I've seen openVPN and unofficial wireguard preshared key implementation, not to mention the famous Shadowsocks v2ray. I'm posting this as feature request or discussion, I may come up with a PR as well.

[angt]

Hi!

This is very interesting! Thank you for taking the time to write this issue.

Obfuscation was never on the TODO list. But if with a little change we can prevent this kind of bad behavior then we can look at it. I find it surprising that a change of cipher solves the problem... Maybe the origin is somewhere else? We need to dig a little more maybe.

We can also imagine that your ISP detects too long UDP sessions. In this case, maybe it's enough to change the source port from time to time on the client side.

[ghost]

I've never thought of a timed session per port, thank you I'm going to investigate more and post my findings here once the internet is back (down due to the recent bombing).

[angt]

Yes, I heard that! I hope the situation will improve very quickly...

[ghost]

Hi!

This is very interesting! Thank you for taking the time to write this issue.

Obfuscation was never on the TODO list. But if with a little change we can prevent this kind of bad behavior then we can look at it. I find it surprising that a change of cipher solves the problem... Maybe the origin is somewhere else? We need to dig a little more maybe.

We can also imagine that your ISP detects too long UDP sessions. In this case, maybe it's enough to change the source port from time to time on the client side.

You were right! it appears that the ADSL provider has a timed session only on UDP, happens at 1:45AM exactly, and doesn't work unless I reboot the modem or change port. Wireless broadband (microwave) detects it as "anonymizer" (got that from calling them) and blocks it within few seconds (edit: on AES not chacha). Using the old Glorytun TCP (443) branch in conjunction with UDP worked best and fixed the issue with insignificant bandwidth loss, much better than OpenVPN. I confirmed the same behavior with Speedify. I may also try port 53 to see if it's possible to bypass the microwave ISP DPI.

Edit2: FakeTCP works very poor behind double NAT, in my case the ADSL ISP, I was surprised to see low bufferbloat with Glorytun TCP compared to OVPN. Edit3: You can close it if it isn't feasible. (de-clutter and low priority plus it's a universal UDP VPN issue) I've made a simple script that cycles path: Path 1 -> Path 1 + Path new (2 rand port) -> Path 1 delete; with the port feature that is currently in PR.

[angt]

That's a nice solution in fact! I'll make sure it works with the coming 0.4 release!