Public WiFi and Open VPN being blocked.

[looney2ns]

I frequent several restaurants and such around the area that offer Wifi.
In a few of them, the OpenVPN on my or my wife's phones won't connect back home when on their Wifi.
I changed the port a few weeks ago over to 443, that helped at some of the places, but It's still blocked at one or two others.
Yes, I realize it's their right to do so. Any ideas if another port may work?

 

[tangent]

I frequent several restaurants and such around the area that offer Wifi.
In a few of them, the OpenVPN on my or my wife's phones won't connect back home when on their Wifi.
I changed the port a few weeks ago over to 443, that helped at some of the places, but It's still blocked at one or two others.
Yes, I realize it's their right to do so. Any ideas if another port may work?

Is this before or after you've agreed to the terms on a captive portal?

 

[tangent]

443 is probably your best option.

If you still can't connect after agreeing to the terms of the captive portal, I'd question if you really want to use that wifi network. At that point, I'd also be a bit concerned about other ssl/tls encrypted traffic.

 

[crw030]

Switch to LTE in those places, best case they are just setup by some provider (like hotels have) that want to spy on your traffic so they can sell you stuff, worst case they have more malicious purpose. Even worse it could be spoofed restaurant wi-fi (I see when I travel people setup "hotspots" of their own with names very similar to or believable as hotel or airport open wifi).

 

[archedraft]

I have found 443 to be the best bet, of course that is the port that hackers know and will try and exploit. I switched to a different port as my logs showed may attempts to get into my network. As soon as I switched to an obscure port the attempts went away.

I agree with the others LTE + OpenVPN is the easiest option. If it’s somewhere you spend a lot of time, you can run an open port website checker and see if there are any open ports on the network you are connected to. That’s quite a bit of effort though, unless LTE isn’t an option.

 

[looney2ns]

Is this before or after you've agreed to the terms on a captive portal?

After.

 

[cb8]

Are you using TCP or UDP for the transport layer?

 

[looney2ns]

Are you using TCP or UDP for the transport layer?

Openvpn log shows UDP at connection.

 

[cb8]

You may have more success with using TCP in cases where they are simply restricting access to TCP + port 80/443. It won't help if they intentionally want to block VPN and are employing deep packet inspection to do so, in which case you'll have to fall back to your data plan as suggested above.

 

[cb8]

For added security, enable tls-auth. With tls-auth enabled, the OpenVPN will only respond to clients that know a pre-shared secret key which is used for signing messages between server and client. That means if you're using UDP, an attacker can't even probe the server port to determine if OpenVPN is running as without a properly signed request the server won't response. When TCP is used an attackers can still figure out that something is listening on the port, but without knowing the secret key requests will be disregarded and you are better protected against vulnerabilities. In the case of heartbleed, an attacker would have to know the secret key before they could exploit the vulnerability, basically limiting the attackers to anyone who has access to your VPN. OpenVPN has a page detailing how to harden your OpenVPN setup.

 

[bp2008]

How well can they actually tell the difference between an OpenVPN connection and a standard https or secure web socket connection? I'm not familiar with how the encryption handshake looks with OpenVPN but if it is the same as HTTPS then they should have absolutely no way of knowing.

 

[tangent]

They could simply be blocking traffic to ip addresses used by local residential ISPs.

 

[JRNAn30]

OpenVPN has a signature, they block based on that. You could use OpenVPN via a SSL tunnel to obscure the traffic, but its more of faff than its worth. Fallback to LTE or vote with your wallet and eat elsewhere, let them know why!

 

[cb8]

How well can they actually tell the difference between an OpenVPN connection and a standard https or secure web socket connection? I'm not familiar with how the encryption handshake looks with OpenVPN but if it is the same as HTTPS then they should have absolutely no way of knowing.

I don't know the details of the OpenVPN protocol, but it doesn't look like HTTPS. It's using TLS, but only for the control channel. The data channel is encrypted using an OpenVPN specific protocol using an ephemeral key exchanged using the control channel. And even if the VPN traffic was wrapped inside what looks like HTTPS, a DPI based firewall could still determine that the traffic does not look like proper HTTPS traffic when the client connects to a website and you have TCP setup and HTTPs setup tunnel within the VPN connection.

 

[Whoaru99]

You may have more success with using TCP in cases where they are simply restricting access to TCP + port 80/443. It won't help if they intentionally want to block VPN and are employing deep packet inspection to do so, in which case you'll have to fall back to your data plan as suggested above.

I've not (yet) had any issues using OpenVPN UDP, but changing to TCP is as well what I'd seen as one of the first things to try if running into blocks.