search

ultrahorizon / UH-VPN-Docs

Documentation, bug tracker and feature request system for UH VPN
https://docs.uh-vpn.com
8 stars 1 forks source link

FEATURE: DPI Evasion #7

Closed x0r2d2 closed 4 years ago

x0r2d2 commented 4 years ago

Gents, Good day! Thanks for the awesome VPN platform. Super easy! If connection to uh-vpn.com is blocked (censored), I am not able to connect to the server but server ip is accessible. What we can do in such situation? Can client (Android or iOS) connect directly to the server?

ISP 1 - uh-vpn.com is accessible - I am able to establish VPN connection with my server. ISP 2 - uh-vpn.com is censored (blocked) - I am unable to establish VPN connection with my server.

Server IP address is accessible from both ISPs.

Thanks.

UPDATE:

jwsi commented 4 years ago

Hey there,

Glad to hear you're enjoying UH VPN!

So in order to assert whether a connection is possible, it is first important to outline the connection process within UH VPN.

Connection Process

  1. Client (iOS/macOS/Android etc.) attempts to initiate authentication with a chosen UH VPN server (one you've deployed either on-premise or in the cloud). The target IP here is the one set on https://uh-vpn.com within the server settings page.

  2. If the UH VPN client is able to reach this server, the server initiates an authentication procedure. This procedure involves querying the UH VPN API to determine if the client connecting is a valid member of your UH VPN group. Based on the response here, the client is either accepted or rejected.

If either of the above steps fail, a connection cannot be established

Your Situation

The clients on either ISP should be able to connect to both VPN servers if and only if both servers are able to contact uh-vpn.com. If one of the servers cannot contact uh-vpn.com, it will be unable to perform the authentication process defined in step 2.

Can you confirm whether both servers have access to https://uh-vpn.com? If they can, it should be possible to connect and we can look into the setup in more detail (give suggestions on avoiding DPI detection).

x0r2d2 commented 4 years ago

@jwsi Thanks for the detailed explanation of the connection process.

I have one server and I can confirm that server is accessible from both ISPs (mobile and broadband).

But!

UH VPN API is accessible only from broadband ISP, it is not accessible (censored) from mobile ISP.

So the solution is (just thinking that it will work):

Store clients database on the own server, do not query it through UH VPN API.

P.S.: avoiding DPI would be a very good feature. In many countries now, Openvpn is easily detected, even with tls-crypt.

jwsi commented 4 years ago

@hybtoy no problem.

The custom database aspect isn't possible as the entire authentication structure is built around our UH VPN API and the group, person, device hierachy. However, porting an auth database won't work as the server isn't the problem here, from what you've described it's the client -> server connection on the mobile ISP that's blocking the VPN connection.

Can you try changing the server settings to use TCP on port 443 please (you'll have to wait a minute for the change to get pushed to the UH VPN server you own) - you can check /var/log/uh-vpn-server/daemon.log to confirm when updates are pushed.

If TCP 443 fails, it would be good to do some digging on the server side:

This confirms the server will be able to perform auth requests, if you see this, then it's definitely the mobile ISP causing issues and the problem will only be solved by altering transport protocols and ports. Here is a list to try:

UDP 443 (emulates QUIC) TCP 443 (emulates HTTPS) TCP 22 (emultates SSH) TCP 80 (dodgy HTTP) TCP/UDP 3000 (undefined)

If a UDP option works, it's best to use that to avoid unnecessary re-transmissions within the tunnel. However, many countries (e.g. UAE) block UDP so TCP is often the only option. Quite a few people find it helpful to make two servers (UDP & TCP) to allow clients to easily switch between them :)

Furthermore, if there are issues with the client you can find the logs in /var/log/uh-vpn-server/<server_token>.log. By default UH VPN uses tls-crypt.

If the above protocol/port combos don't work let me know.

x0r2d2 commented 4 years ago

it's the client -> server connection on the mobile ISP that's blocking the VPN connection.

No. Client -> server connection is OK, but client -> uh vpn api is unavailable.

As I told, server ip (not uh-vpn server) is reachable from both ISPs but UH VPN api (UH VPN site) is reachable only from broadband (home) connection.

The problem is that uh-vpn.com is censored on my mobile connection. Is there any way to bypass it?

jwsi commented 4 years ago

So from the authentication steps you will see that the client does not contact the UH VPN API, therefore censorship of the UH VPN API client side is not an issue in the connection process.

This is why I believe the issue is the client->server connection, so have you managed to try the suggested ports?

Steps

AnthonyWharton commented 4 years ago

Just to add, the only client communication with uh-vpn.com is to sync profiles. So if you have successfully synced a profile to your app, from there everything is talking directly to the server!

If you haven’t managed to sync profiles then unfortunately this communication is baked into the app and there’s no way to sync profiles directly from the server.. for now you will have to find a network that can connect to uh-vpn.com unfortunately.

We’re discussing options to improve UH VPN for censored networks internally as this has come up in a few issues! Thanks :)

x0r2d2 commented 4 years ago

So from the authentication steps you will see that the client does not contact the UH VPN API, therefore censorship of the UH VPN API client side is not an issue in the connection process.

Thanks, just got it now. I forgot that mobile ISP few days back started to block all OpenVPN connections, no matter what protocol or port is. They can recognize it and client do not even able to pass to authentication process.

So I will look for another solution for now.

Thanks.

jwsi commented 4 years ago

I would try the protocol/port numbers suggested at as it's very likely that with tls-crypt used on those combinations you'd find a way through. Especially given that you have your own tls-crypt key that's unique to you (provided by UH VPN).

We've had lots of success in combating censored networks this way.

Have you attempted the above steps?

x0r2d2 commented 4 years ago

@jwsi Trying it now.

jwsi commented 4 years ago

@hybtoy ok great.

For every new server you create you'll need to add the corresponding token into /etc/uh-vpn-server/tokens then the UH VPN Server daemon will pick it up and process requests for the server created on the website.

x0r2d2 commented 4 years ago

@hybtoy ok great.

For every new server you create you'll need to add the corresponding token into /etc/uh-vpn-server/tokens then the UH VPN Server daemon will pick it up and process requests for the server created on the website.

Thu May 28 17:45:25 2020 Listening for incoming TCP connection on [AF_INET][undef]:80
Thu May 28 17:45:25 2020 TCPv4_SERVER link local (bound): [AF_INET][undef]:80
Thu May 28 17:45:25 2020 TCPv4_SERVER link remote: [AF_UNSPEC]
Thu May 28 17:45:25 2020 Initialization Sequence Completed
Thu May 28 17:46:19 2020 TCP connection established with [AF_INET]XXX:40669
Thu May 28 17:46:24 2020 TCP connection established with [AF_INET]XXX:40670
Thu May 28 17:47:19 2020 XXX:40669 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu May 28 17:47:19 2020 XXX:40669 TLS Error: TLS handshake failed
Thu May 28 17:47:19 2020 XXX:40669 Fatal TLS error (check_tls_errors_co), restarting
Thu May 28 17:47:24 2020 XXX:40670 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu May 28 17:47:24 2020 XXX:40670 TLS Error: TLS handshake failed
Thu May 28 17:47:24 2020 XXX:40670 Fatal TLS error (check_tls_errors_co), restarting

All of them like that on mobile internet connection :)

jwsi commented 4 years ago

@hybtoy I see, that's classic errors from DPI interference. If you've tried TCP with all of the port options above and not just 80, then at present there's not an awful lot I can suggest unfortunately. I would have thought TCP 443, TCP 22 or TCP 3000 would have worked, but it seems that this mobile ISP is employing protocol/port independent DPI.

It is worth noting that we are actively developing an addition to the UH VPN suite called FTE (format transforming encryption) which will be used to mask UH VPN traffic as pure unencrypted HTTP, but unfortunately this is not going to be released for quite a few months yet as we're still in the early stages of development.

x0r2d2 commented 4 years ago

@jwsi Hello. Just wanted to tell you about Tunnelblick's xor patch for openvpn. It gives ability to bypass Firewall and DPI. I am using it now and I am able to bypass DPI.

https://tunnelblick.net/cOpenvpn_xorpatch.html

https://github.com/Tunnelblick/Tunnelblick

jwsi commented 4 years ago

Hey @hybtoy,

Thanks for sharing those links! We'll have a chat internally about this because we were planning on implementing FTE, but if simpler mechanims like these can be introduced then it may well save us a lot of development time and speed up the release of DPI evasion features to users.

I'll discuss with our team and revert back 👍

x0r2d2 commented 4 years ago

Hey @hybtoy,

Thanks for sharing those links! We'll have a chat internally about this because we were planning on implementing FTE, but if simpler mechanims like these can be introduced then it may well save us a lot of development time and speed up the release of DPI evasion features to users.

I'll discuss with our team and revert back 👍

One more thing. It would be great if we will have Management panel on our own server. If main Management panel server (uh-vpn.com) will get blocked, client will no be able to pull config.

Thanks.

AnthonyWharton commented 4 years ago

We have had a few requests for something like this but it requires a bit of an architecture change the software engineering perspective.

It’s something we’re discussing but it is certainly a backlog item.

x0r2d2 commented 4 years ago

Hey @hybtoy,

Thanks for sharing those links! We'll have a chat internally about this because we were planning on implementing FTE, but if simpler mechanims like these can be introduced then it may well save us a lot of development time and speed up the release of DPI evasion features to users.

I'll discuss with our team and revert back 👍

@jwsi Hello!

Any update on this?

Thanks.

jwsi commented 4 years ago

Hey @hybtoy,

I'm just finishing off the MFA issue which will be implemented by end of play today, then we plan to work on this and discuss a way forward. Realistically, this timeframe for this depends on how easy it is to merge this XOR patch into our UH VPN clients which are OpenVPN 3 based and not 2.4. Once we know this we will be able to provide a concrete timeline on when this will be done.

James.

jwsi commented 4 years ago

Hi @hybtoy,

Today our development team had an internal discussion regarding the topic of DPI evasion for UH VPN. We discussed the OpenVPN XOR patch as well as other alternative options such as obfsprox4, meek and fte.

Unlike the OpenVPN XOR patch, the alternatives listed above require a certain amount of heavy lifting as they're essentially separate programs that would have to run alongside the VPN core. This would translate into considerable development effort and given that DPI evasion is an ever evolving field, there is a risk that our chosen "pluggable transport" module may be ineffective after a short period of time, leaving our prior devleopment efforts wasted. The OpenVPN XOR patch on the other hand is something quite different, and offers clear results in certain situations (as you demonstrated) with considerably less development investment.

We are starting work on integrating a variant of the OpenVPN XOR patch into UH VPN clients and servers. We expect this to be completed in around a month or so, at which point we will offer this as a beta option for our premium users. To give you an outline of our roadmap here is a short summary of the steps that must be completed:

So in summary, UH VPN is set to get a form of DPI evasion very soon!

x0r2d2 commented 4 years ago

@jwsi can't wait to test this out! Big thanks.

x0r2d2 commented 4 years ago

@jwsi one more thing is, I think you also have to hide (with different hostname packed by TLS cert) profiles synchronization with uh-vpn.com. ISP can filter DNS by special words and hosts and after that just block ip address of uh-vpn.com

jwsi commented 4 years ago

Yes you're right, we're working on having a couple of throw away domains ready to use for config synchronization. However, if one synchronises the profiles prior to travelling to a censored location then the system should still work.

x0r2d2 commented 4 years ago

@AnthonyWharton @jwsi Good day!

Gents, any update on this?

Everything is going as planned? :)

Regards.

AnthonyWharton commented 4 years ago

Hi @hybtoy,

Sorry for the radio silence, there's been a lot going on in the business as well as some urgent 'fix' tasks required.

We're still working on this at the moment; the development in integrating and validating this with UH VPN Server is underway, with the client side support to follow.

We'll update this issue in due course!

Anthony

jwsi commented 4 years ago

Hey @hybtoy,

Everything is going well. The reason for the slight delay is that I've found a couple of bugs in the XOR patch that I'd like to correct. Furthermore, there are a series of optimisations that I'd like to make to the underlying patch so that the same level of obfuscation can be achieved with very little impact to overall VPN performance.

Before we merge anything into our codebase we do a certain level of formal cryptographic verification and a few things cropped up during this analyis phase. Therefore, I've decided to re-write most of the patch in an effort to provide a greater level of efficiency whilst keeping the same obfuscation guarantees.

The only caveat to our approach is that it won't be compatibile with Tunnelblick's one or the original's. This shouldn't be an issue because the UH VPN clients will support our version.

I'll let you know when I have compiled an OpenVPN 2.4 binary, then we can perhaps get you involved in a beta test prior to final rollout to make sure that our method is working as you expected.

Once this is done @AnthonyWharton will head up the process of porting our patch to the UH VPN clients.

jwsi commented 4 years ago

Hi @hybtoy,

I've just finished the integration of the UH XOR patch into OpenVPN 2.4.9 on our public OpenVPN Debian repository which can be found here. Our initial testing seems very positive and our patch suffers from near-zero performance degredation and manages to spoof our classification engine on our Palo Alto firewall.

Before we begin integration into our client apps it would be great to ensure that this patch does indeed work for you and others. If you'd like to take part in this beta test, if you could please email engineering@ultra-horizon.com then we can provide you with a set of temporary OpenVPN profiles that can be used to trial the system. This will require a Ubuntu based operating system and you will be required to install our version of OpenVPN from our PPA (we will provide instructions for this). Then if you find any problems with the implementation (e.g. it is still blocked) then we can fix this prior to a wide rollout.

James.

x0r2d2 commented 4 years ago

Hi @hybtoy,

I've just finished the integration of the UH XOR patch into OpenVPN 2.4.9 on our public OpenVPN Debian repository which can be found here. Our initial testing seems very positive and our patch suffers from near-zero performance degredation and manages to spoof our classification engine on our Palo Alto firewall.

Before we begin integration into our client apps it would be great to ensure that this patch does indeed work for you and others. If you'd like to take part in this beta test, if you could please email engineering@ultra-horizon.com then we can provide you with a set of temporary OpenVPN profiles that can be used to trial the system. This will require a Ubuntu based operating system and you will be required to install our version of OpenVPN from our PPA (we will provide instructions for this). Then if you find any problems with the implementation (e.g. it is still blocked) then we can fix this prior to a wide rollout.

James.

Hey James.

Thanks for the update.

I will drop email now.

Regards, Hybtoy.

jwsi commented 4 years ago

We are almost there now, with all aspects now firmly beta tested.

@AnthonyWharton has now finalised this patch into our openvpn3 codebase. The only item left on the adgenda now is to update our client applications to integrate with the updated openvpn3 codebase, then we can push for a release.

x0r2d2 commented 4 years ago

We are almost there now, with all aspects now firmly beta tested.

@AnthonyWharton has now finalised this patch into our openvpn3 codebase. The only item left on the adgenda now is to update our client applications to integrate with the updated openvpn3 codebase, then we can push for a release.

Hey James.

How long it will take to update applications for xor patch?

Thanks.

AnthonyWharton commented 4 years ago

Hi @hybtoy,

This is currently my full focus, however the update that will bring this feature also comes with some back end improvements which we're just validating before release, and then we'll be subject to App review times.

Once the app is out on all platforms we'll enable the feature on the website and you'll be good to go if you update your apps and server package.

We don't like rushing updates as we want to make sure everything works from Day 1, so I appreciate your patience! Just know we're working on all this every day - including the weekends!

x0r2d2 commented 4 years ago

@AnthonyWharton @jwsi Huge Thanks to your team!

AnthonyWharton commented 4 years ago

Status update as it's been a few days:

Once all of this is done, the update will go live on the website for you to use! Until these are all done the update won't be released for compatibility reasons.

AnthonyWharton commented 4 years ago

It's been about a week so I just wanted to give an update, so edited the above post. The changes are:

So in short, getting close now!

x0r2d2 commented 4 years ago

@AnthonyWharton Thanks for the update! I hope you will release it soon, very soon. :)

AnthonyWharton commented 4 years ago

Hopefully the last update before release! Everything is now live but dormant on macOS, Android and Windows.. We encountered some issues where connections drop on iOS and I am currently investigating this. Hopefully I should have a fix and have it released in the coming days, so we should be wrapping up this issue soon!

Thanks for your continued patience.

AnthonyWharton commented 4 years ago

It's been a painful bugfix but we have a new version in app review now.

Once Apple approve the iOS build we will be rolling out DPI evasion and closing the issue!

x0r2d2 commented 4 years ago

@AnthonyWharton

Sir, any update? :)

jwsi commented 4 years ago

@hybtoy, we're currently being held up in Apple's app review queue. All of @AnthonyWharton's work is complete and the patch is ready, we're just waiting for Apple to approve the iOS app so that it can be released to the App Store. Once this is done I will immediately merge in my code into the UH VPN API to enable the DPI Evasion patch.

The review process is a little out of our hands, and they sometimes have a few points they like us to clarify which adds time to the review process. Plus their guidelines are ever changing which means it is sometimes hard to predict what they might flag up.

However, the work is done and we're ready to release as soon as we get a positive response from Apple!

James.

AnthonyWharton commented 4 years ago

Good news! We just hit the release button for iOS, it's processing and will be deployed to the App Store soon.

@jwsi will finalise the server packages and roll out DPI evasion to the web interface, you should see it in the server settings (on Premium groups) like so:

image

jwsi commented 4 years ago

This feature is now live in production! 🥇

Closing this issue. A big thanks to everyone outside of the dev team who helped with the implemenation of this feature, in particular @hybtoy for providing a fantastic testing ground! Great work!