After a recent visit to a hotel I was surprised to discover that they blocked access to my OpenVPN server. I often use this as a way to secure my internet traffic when I am on public wireless. Besides using only SSL based websites, or tunneling over SSH what options do I have to ensure that no one can sniff my packets while they are being broadcast in plain text through the air?
If you can arrange this ahead of time (or get someone to do it for you), you could set up an SSL proxy (e.g. via stunnel), which would in effect be creating an SSL VPN.
Not so different from tunnelling over SSH, I guess, but it is another option.
I see, you did say "besides using only SSL websites". Nevertheless for many it's not such a bad option to content yourself with the thousands of SSL sites listed in the Firefox and Chrome extension HTTPS Everywhere until you get back to an access point that supports your VPN. Limitations include that eavesdroppers would be able to see which sites you visit and that the extension does not prevent sites from incorporating unsecured resources such as Wikimedia Commons pictures into the secured pages.
Just some thoughts:
One important thing that people tend to forget: hotels are not evil, they are just careless.
Blocking outgoing traffic is not a good security practice, it's just security through obscurity at best. Which can very easily be defeated. So instead of reducing the user experience and providing fake security, tell them to change their filtering policy.
If they refuse or are too slow, add a redirection rule to redirect your traffic on port 80 to your VPN port. Or just change it's port to 80...
How to keep secure while browsing on open wifi when SSL VPN is blocked?
Actually it really depends on what you exactly want to achieve, what you really want to protect, etc. Using basic firefox plugins such as perspective/https everywhere, would provide a relatively secure browsing experience.
Since you have a VPN set up, it would be nice to use it, it's one step further and, if properly set up, can provide a fair level of anonymity and security. Refer to my previous point.
I would like to point out that if you browse "external" Web site then your packets will travel unencrypted at some point. Your VPN (or SSH or SSL proxy or whatever) only avoids that to happen in your immediate vicinity; it defeats attackers who are in the same hotel than you. But it does not defeat attackers in general. If you worry about eavesdroppers, then you should visit HTTPS sites only, regardless of WiFi, hotels and VPN.
Besides the other answers, you could also open a RDP session to a server on which you have an account. If you took care to set the server on port 443, then most firewalls will let that pass (RDP uses a specific transport layer which is distinct from a SSL/TLS connection, but few firewalls inspect data with enough attention to notice that). RDP 5.2 encapsulates a TLS session, so that's as secure as you can get. Web browsing through an exported desktop session can be a frustrating experience, but it is tolerable for text-based sites like, e.g., security.stackexchange.com (I am doing it right now).
You mentioned OpenVPN specifically. I am surprised this answer hasn't been done yet.
This situation happens to me all the time and I fixed it by running a second OpenVPN server on port 443 (TCP). I run PiVPN and it was easy to setup: https://github.com/pivpn/pivpn/issues/178#issuecomment-269882913
Basically copy the OpenVPN config that PiVPN creates to a second config. Change it to use TCP on port 443.
Edit your iptables by adding a
-A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE (With a unique subnet then the default that is there).
Restart the service
service openvpn restart.
Allow incoming connections on 443 into your home router to your OpenVPN server like you did for the default port.
Lastly copy the client configs and change them to TCP port 443. The two instances use the same keys and your clients have two configs depending on which one you choose to connect to.
The default UDP has better performance but is often blocked by moronic public WiFi. The TCP over 443 is a little bit less performant but not so bad and works even if moronic public WiFi tries to bugger your VPN usage normally.