Hello all, wondering if anyone can provide a possible solution to my issue. Running an OpenVPN server on Windows Server 2022 with TLS V1.3 and attempting to essentially VPN from my School network through to my Home to access resources that are local to my home network. I have the VPN configured and it works flawlessly everywhere else than my School network. I have verified that 443 TCP is open but the enterprise-grade network is resetting the connection with (10060) and (10600) codes. I am really using the only open port on the network but don’t quite know how to go about solving this issue.
Probably not TLS/SSL inspection going on, your school would require installing their root certificate which is difficult to do on a lot of mobile devices. Usually something you only see on company-owned computers on a Windows domain.
I know OpenVPN uses some non-standard protocols for the client hello packets that a firewall can be configured to drop. Another common feature of firewalls not doing full on TLS interception/inspection is to attempt an HTTPS connection to the destination URL and inspect the certificate. If none is returned or one that is not trusted (such as your OpenVPN cert signed by your own CA), the connection gets blocked. You can get around this by putting your vpn server behind a reverse proxy and serve up some kind of default web page with a trusted cert that responds to an SNI header. Lots of guides online for doing this with haproxy, overall not the easiest thing to set up (I run this myself).
Since you’re running Windows server, probably the easiest setup would be to run an SSTP server with a trusted cert from let’s encrypt (or a paid one). I’ve found SSTP to be the closest to looking like normal HTTPS traffic, and the default setup runs IIS that will serve up the certificate to any normal web request. The only thing that could still block it would be DNS filtering. Good luck!
They might do deep packet inspection(DPI) which is an intentional man-in-the-middle(MITM) attack that strips away the SSL cert so they can inspect it then resign it and send it on its way
try port 995 TCP as it is used for POP3 over TLS which it often does not have DPI on it, web ports are often run through DPI and some DNS sinkhole to filter internet results
As others have said, bypassing network security features is almost always grounds for getting kicked off (or fired if a work setting).
But, OpenVPN on port 443 usually causes more problems than it fixes. Most next-gen firewalls will expect HTTP traffic on 443, and when it sees signatures that don’t look like HTTP it will quietly log and drop it. If you really want to get around that you could either just use the default 1194 or try UDP on 53. Again tho, NGFW solutions are REALLY good at inspecting packets for this exact thing, and the few times it gets missed, it resulted in the end-user having an awkward meeting with the admins.
1194 is the default port for OpenVPN, so if the FW isn’t explicitly blocking it, would let it pass without inspection. Almost all school networks i’ve seen forbid any VPN traffic on the student side, because what possible reason would a student need a VPN…
They might have a TLS proxy that is stopping you. There’s no way for them to actually tell that your VPN traffic is any different from any other TLS traffic.
There’s a lot of misinformation about how TLS works in this thread. If you could tell what kind of traffic was being carried inside of TLS it would defeat the entire point of TLS. TLS 1.3 makes this even more difficult because there’s even less information in the clear during the handshake.
Like if I connect to netflix someone doing a packet trace would see what cipher suite I’m using and that the SNI is “netflix.com” and that the port is 443… but they have no way to tell what kind of traffic is going over that port. Could be HTTP, Database, etc.
The part about this that I find weird is that my friend used a PIVPN server at his house and it works flawlessly at school for him. We’re pretty much using the same stuff.
That’s not possible with TLS (esp 1.3). It’s more likely they have a TLS proxy.
DPI can not decrypt TLS 1.3 (or TLS 1.2 with PFS) traffic without the ephermal keys generated for each session. Even if he was using non PFS ciphers in TLS 1.2 (or TLS 1.1) they’d still need to have the private key from his server to decrypt the traffic.
They can see things like the certificate subject, etc…but I highly doubt they are blocking based on that - they’d need a pretty advanced setup
Reddit is a crazy place - I’ve literally been doing packet analysis professionally for 20 years and kids who googled something once are arguing with me. LOL
Again - if you want to decrypt and inspect TLS traffic you have ether have a way of getting the key or use a TLS proxy (which of course also would give you the key):
There’s no way to tell what protocol is carried inside of TLS without decrypting it (which they certainly can not do). There are no “signatures” that look like HTTP to detect when using TLS.
Things like the certificate subject, expiration, cipher-suite in use, etc are in the clear, but there’s no way to tell what kind of traffic is being carried.
you could either just use the default 1194 or try UDP on 53.
good in theory but most schools and some workplaces block things like port 1194 or will just have a default block rule and only allow things like 80/443 and if you are lucky some other port is used for a service that they use. also some times they will have NAT rules that will force all port 53/853 traffic to go to their DNS servers so it will look like it is successful but it’s really their DNS servers responding
Now DNS over TLS which uses port 853 will likely just fail as the cert would not be valid which is why many mobile applications and some browsers will use DNS over HTTPS which just uses port 443 for DNS
something like shadow socks or someway to disguise VPN traffic as HTTPS traffic would be a good idea, I know that some free VPN’s use it namely sky VPN it can be found on the google play store and the apple app store and bypasses most firewalls
You should read more about how deep packet inspection works and how much data is actually in clear text, TLS isn’t a silver bullet and a lot of information can be gleaned from headers and other details that would give away what is going on inside the flow. Just because it’s TLS 1.3, doesn’t mean the host network can’t gather some details about it.
Not saying these technologies can see what the traffic is, just that the patterns and fingerprints do not match what typical HTTP traffic would look like. Here is a good writeup from PaloAlto giving some examples of how they detect these subtle differences.
Yea it would definitely be a long shot, any admin worth their salt would have it locked down in a way that these bypasses wouldn’t work. Either they use a port that hopefully sneaks around the inspection or they figure out a way to make the traffic look legit enough to not get blocked. Most of the time doing things like this will get the traffic noticed on a short list of “odd” connections since most students aren’t getting their activities blocked.
Years ago, I used to “work around” a block like this by using VMware horizon to remote into a desktop and do my browsing from there.
I’ve been in technical sales for packet analysis solutions for 20 years. I don’t need to to any reading at all - this is literally what I do for a living.
I have a state of the art enterprise class real time packet analysis (much more advanced than DPI - our solution will actually reassemble and track the state of every connection, parses over 70 protocols and even has a programmable real time API for custom data extraction) solution sniffing all the traffic on my home network and I can tell you exactly what can be extracted for any version of TLS.
There is no way to tell (other than doing ML on the request/response patterns and even then it’s just a slightly educated guess) what protocol is being carried inside of TLS. That would defeat the entire point of TLS. TLS 1.3 makes it even harder because there is less information available in the envelope.
I mean you can look yourself - just take a wireshark trace - it’s all right there.
There’s no way to sit passively on the network and decrypt TLS traffic unless you have the key (and you actually need the ephermal key for every connection in TLS 1.2 with PFS and TLS 1.3)
Yeah if you don’t have a real cert that’s a giveaway of course. But for a TLS connection with a real valid cert there’s no way to tell.
I will say that whoever wrote that isn’t very technical… this statement:
“The above figure shows that the traffic on port 443 sent by Thunder VPN was misidentified as SSL in Wireshark. Thunder VPN mimics SSL traffic by utilizing the same port and handshake”
is totally incorrect and honestly doesn’t make sense. It is in fact using SSL traffic and it’s certainly not misidentified. There’s no requirement to carry HTTP in TLS on 443 - it’s just the typical configuration.
Most organizations allow outbound TLS on 443 (some do proxy it though) so people will often run all kinds of things on 443 when they are attempting to evade controls. This is a very common exploitation (and C&C) tactic used by adversaries in the security world
personally, I used port 995 TCP as its often used for email and it can always look weird and to my knowledge non the tech staff have found it yet I did at one point also find a way to just boot my own USB on the school laptops but then one of the students found out and reported the problem, there were no consequences for me, but they added a password to the BIOS so now I cant just use legacy mode and boot a different drive.
on my personal network, I do something similar as to block all ports and then just allow the ones I know are needed so 80/443 there is a NAT rule for 53/853 so there is no DNS bypass and DNS over HTTPS is blocked, this is the perfect environment for me to find weaknesses and then test them live and patch them on my system.
I mean, that writeup was intended for a lay audience i think but the point is still valid, OpenVPN has some nuances that a DPI can definitely pick up on. Here is a scientific paper written about it and here is Wiresharks writeup on their breakdown of the OpenVPN protocol.
What they meant by “Misidentified as SSL” was Wireshark saw TCP 443 and thought “this must be HTTPS”. You can easily tell Wireshark to ignore that for this session and TCP 443 is actually OpenVPN, and it would decode the packets correctly.
The point is moot tho, it’s a well-known fact that DPI on modern firewalls can easily detect VPNs and block them at-will. The Great Firewall has been doing it for years. No MiTM required.
Yea, I think a lot of it comes down to the admin running it. If they don’t bother to check the block list or look for suspicious activity to tweak the filtering then the DPI will snare most of it and a few will get thru. It’s basically a game of whack-a-mole where the mole keeps popping up on a different port/protocol lol