Did The Work Firewall Nazis Strike Back?
June 2, 2006 7:54 AM   Subscribe

Warning: Networking Geekery Ahead Once upon a time I was able to use VNC viewer (the binary executable, not the java viewer) on my work Windows XP PC to connect to VNC server on my home Windows XP PC via Port 443. This allowed me to view and control my home desktop in a window on my work PC and thereby do an end run around the restrictive web filter/firewall at work. It was slow, but it was still useable and reliable.

I stopped using it for a couple of weeks when I lost my USB key. I recently found it and tried my VNC connection again from work. It doesn't work now.

Specifically, once I click on "OK" for it to connect, it takes about 2 minutes and then comes back with a dialog box that says:

"read: Connection reset by peer (10054) Do you wish to attempt to reconnect to WW.XXX.YYY.Z:443? Yes/No""

I can still connect to https://www.example.com sites, so obviously port 443 isn't completely disabled at work's firewall. Is it possible that the work firewall is actually inspecting packets on 443? Any ideas on how to get around it if they are? Any other tests I can try to pinpoint the problem?

Here's the current setup:

Home -

Desktop Windows XP PC running RealVNC Enterprise Server in user mode (not service mode) on Port 443, encryption on, password required to connect. Java server is disabled. The VNC Server IP access filter is currently set to simply "+", which allows connections from anywhere. Windows XP Firewall is disabled. IP address is 192.168.1.100

Linksys WRT54GS Router/Firewall with Port 443 forwarded to Home PC's LAN IP. Local IP is 192.168.1.1, external IP is WW.XXX.YYY.Z (not going to give the actual IP for obvious reasons).

Home ISP is a big cable company which blocks common server ports 80 (http), 21(ftp) and 25 (smtp), but not 443.

Work -

Windows XP PC running VNC viewer executable from USB drive.

Networking through corporate LAN/Firewall with a several routers/network segments between work PC and firewall.

Troubleshooting steps I took this morning -

Verified VNC Server IP Filter is set to "+", which allows connections from anywhere.

Connected to VNC server on my home LAN using a laptop which connects to the WRT54GS wirelessly. On the laptop VNC viewer I connected to "192.168.1.100:443". I was prompted for a password and then was able to view/control my desktop desktop just fine.

Back on the desktop I used firefox to connect to a web-based port scanner. It reported my external IP as WW.XXX.YYY.Z, as expected. I closed the VNC server and then requested the web port scanner to connect to port 443 on my desktop. It couldn't connect.

I then restarted VNC server and asked the port scanner to connect again. It then reported port 443 as open and active. Looking good.

I haven't tried to connect from an external internet host other than work yet; that will be the next step.
posted by de void to Computers & Internet (15 answers total)
 
You dont need to mess with a port scanner. Find an external host and do

telnet x.x.x.x 443

You should see something like "RFB 003.006"

If you can see that you have established a connection and VNC is working. If 443 isnt working for you then set your home machine to use a higher port number like 9000 or something. 443 is https and if your ISP is blocking ports perhaps they just added that one to the blacklist.
posted by skallas at 8:47 AM on June 2, 2006


My guess is they could have started blocking everything under 1024 - the common post range for services.
posted by jimmy0x52 at 8:59 AM on June 2, 2006


From what you said about https:// sites, it's doubtful that they're blocking 443 outright (and it would be a BAD thing if they were.)

I would try to get on another AP with your laptop's wireless - stop by a starbucks on the way home or something - and see if you can hit it there. Make sure you use the VNC client on your USB key and NOT the one on your laptop, because that leads me to my next point - you might have messed something up on the VNC client you installed on your USB key.
posted by cebailey at 9:06 AM on June 2, 2006


Skallas, I have to use 443 because the work firewall blocks almost everything except 80 and 443. My home ISP blocks 80 outbound.

Cebailey, when I connected with my laptop I ran the VNC client from the same USB key that I later took to work.
posted by de void at 9:25 AM on June 2, 2006


If work is outbound block for everything but 80 and 443 you can try to do an https tunnel to your machine. It may be that your work is dropping unencrypted 443 traffic. There's one here.
posted by skallas at 9:29 AM on June 2, 2006


You asked, "is is possible that they are inspecting packets on 443" and the answer is definitely yes, it is most certainly possible, and that is probably what they're doing. VNC traffic does not look anything like SSL traffic, so it would be pretty easy to distinguish and block with a DPI (deep packet inspection) firewall. The https tunnel solution that skallas mentioned should work well.

Incidently, the VNC protocol itself is very weak, even if you enable encryption. This is a known design limitation, and the developers have no intention of changing it. Therefore, running "naked" VNC over public networks is not a good idea at all, it should be tunneled (e.g. SSH) anyway, so figure that they're doing you a favor here.
posted by Rhomboid at 9:51 AM on June 2, 2006


Skallas, thanks. I'm considering setting up a linux machine at home for tunnelling purposes.

The VNC server is supposed to be using encryption though. When I succesfully connect for the first time with the VNC client on a new machine, it takes a few seconds to generate keys before establishing the VNC session.
posted by de void at 9:51 AM on June 2, 2006


Point taken Rhomboid. Looks like the Linux server tunnel is the best answer in the long run.
posted by de void at 9:52 AM on June 2, 2006


apology for the slight derail...

... but, you may find a cleaner solution in using OpenSSH with PortaPutty / Portable Firefox on your USB key. It may actually be faster since you dont have to update graphics in the VNC viewer.

Versatility is also enhanced since you could also use, for instance, WinSCP to securely transfer files to and from your home pc.

In any case, there is a pretty good tutorial available if you want to give it a whirl.

Feel free to email me if you have problems setting it up.
posted by whatisish at 10:05 AM on June 2, 2006


on preview, you wouldn't have have to set up linux machine for this. OpenSSH is available for Windows.
posted by whatisish at 10:11 AM on June 2, 2006


Thanks for that whatisish, I'll give you a yell over email.

Even thought it is slow, I prefer VNC because I know I'm not leaving any history/graphics/cookies/registry settings (aside from those made by the VNC client) on my work machine due to my activity. Plus I can keep my home PC's awesome cable download pipe pumping during the day.

You're probably right in that I don't need a seperate Linux server for this, but I've been looking for an excuse to set one up anyway.
posted by de void at 10:25 AM on June 2, 2006


The ssh solution requires outbound port 22, which he says he can't have. Only 80 and 443. You should be able to run ssh off off 443 if you like by editing /etc/ssh/sshd_config.
posted by skallas at 10:33 AM on June 2, 2006


Yep Skallas, that was already in my mind. Thanks!
posted by de void at 10:35 AM on June 2, 2006


on preview, you wouldn't have have to set up linux machine for this. OpenSSH is available for Windows.

Or you could run one of the freebie bios replacements on a Linksys WRT router. I use tunnelier to connect to mine (which is running Alchemy v1.0) and its built-in redirection for remote desktop. Works like a charm.
posted by phearlez at 12:57 PM on June 2, 2006


You should SSH all your traffic anyway. It's just another small step, but Putty + VNC viewer is nothing on a USB key. Fairly easy to setup. And you would only need to open the SSH port on your home firewall.
posted by i_am_a_Jedi at 5:20 PM on June 2, 2006


« Older I am in NYC for the first time...   |  Elegant design of ~500 multipl... Newer »
This thread is closed to new comments.