Recently after configuring an OpenVPN instance to use TCP over port 443 to allow my phone to connect to home while at work over a “bring your own device” network, it suddenly stopped working. It connects fine over other networks.
From what I’ve read it seems maybe they’re possibly blocking the connection based on DPI revealing a VPN protocol? I get that they own the network and can do what they want with it but I’m curious what might stand out so much that OpenVPN was potentially detected? Or maybe they blocked my home IP if they saw incoming HTTPS traffic from a non registered IP?
Due to where I work it wouldn’t surprise me but still causes an issue where I can’t access my files or my security cameras unless I am on the cellular network. Anyone have input it would be appreciated
OpenVPN doesn’t do HTTP natively so even if it’s on port 443, any decent NGFW can still pretty easily detect it without DPI.
DPI generally requires you to import a certificate on your device which is rare for BYOD networks or personal devices in general. Technically they can do it if they’re using a certificate with certificate authority signing capabilities but those are very expensive for public certs that would already be trusted without needing to import.
This is purely informational and not really intended to help you avoid employer policies/restrictions, keep personal and business related traffic separate.
Now that you mention it, the network initially wanted employee credentials to log in and it did present a certificate. I used to just use port forwarding for services so I could get notifications for the home. The whole reason I use a VPN is that it’s a bit more secure…
It’s very easy to a router to identify non-HTTPS traffic and block it, it just needs to look at the ALPN extension in the TLS handshake for HTTP protocols.
You might be able to patch OpenVPN client and server to actually add an ALPN extension to pretend it is HTTPS traffc to convince the firewall to let it through, but there’s other restrictions the firewall could have as well (client-side certficate, full decrypting proxy requiring a local CA, etc).
There’s tools to wrap a TCP connection in a Websocket, which is HTTPS. You could potentialy do OpenVPN over Websocket. You’d need to de-encapsulate Websocket on your VPN server, or another external host.
Thank you all for the replies. After I finally had some time to troubleshoot, I found occasionally it would let me connect no problem but after about an hour or so it would disconnect and I would no longer be able to connect unless I waited for an hour or two before trying again. When I dug into router logs, I believe it is suricata flipping out and blocking the ip I try to connect from. Since I have a 1 hour timeout, it would make sense why I could connect again. As to why it is flipping out…I will have to research more.
Sorry I honestly forgot about this thread… Actually…yes it seems suricata would block the ip of the workplace I had to suppress invalid handshake alert for it to work. I don’t know if it was an OpenVPN iPhone app issue or other issue but once I told it to suppress the alert it has worked flawlessly since. When I first wrote this thread I think a bit of paranoid snuck in but in reality I think the company just blocks all but the most common web ports on the network and nothing more than that.