Can you tunnel via SSH to access Gmail via IMAP in Outlook when the ports are blocked?
August 7, 2008 9:47 AM   Subscribe

I like to think of myself as somewhat of a power user when it comes to mail servers, SSH, Gmail, and Outlook, but this one has me stumped! I use Outlook for both work and personal e-mail, but while on the network at work our ports are pretty locked down. How might I access my Gmail account via IMAP in Outlook while on a locked-down network? Ports 25, 110, 143, 587, 993, etc., are all blocked. In order to access personal e-mail, I connect via SSH (PuTTY) to my DreamHost mail server and tunnel POP/SMTP (ports 110 and 25) traffic over that SSH session. Is there any way I could use that SSH connection to tunnel to Gmail's servers for IMAP access as well? If not using that tunnel, is there another way? I can access Gmail through a web browser, but my objective is to be able to collect all my e-mail in Outlook as well. Thanks!
posted by izicwe to Computers & Internet (16 answers total) 4 users marked this as a favorite
Best answer: You can forward a local port to a remote host on the remote side; that is, you would connect to port 993 on your own computer, and the far side of the tunnel would connect to This feature can be disabled on the server, but if it's enabled, it should solve your problem. From the command-line, it would be:

ssh -L

Within PuTTY, SSH/Tunnels, you would add a port forward with "Source port" 993, "Destination", and select the "Local" radio button.
posted by pocams at 10:13 AM on August 7, 2008

Sure - what you want is "dynamic port forwarding," where you'd set up PuTTY with a fixed source port (say, 666), and a dynamic destination port. Then you'd set up Outlook to use localhost:666 as a SOCKS proxy; it will forward SMTP, IMAP, POP3, or whatever else you want to go through the tunnel out to the Dreamhost server.

The only thing I'm not certain about is whether you can set Outlook up to use the proxy for your external mail but ignore it for your work server (presumably an Exchange server internal to your work network and inaccessible from Dreamhost).

On preview: or what pocams said, but the advantage of setting it up dynamically is that you wouldn't need to configure an individual tunnel for each pop/imap/smtp tunnel separately.
posted by whir at 10:18 AM on August 7, 2008

Bitvise Tunnelier (free!) works pretty well for quick Windows tunnels (if you can't install it locally, it will easily run from a thumb drive). I prefer it over PuTTY for port forwarding because you can save config files, rather than having to re-type the connection settings each time you want to start it up. I use it as a SOCKS5 proxy for secure connections on unsecure wireless, and SSH tunnel all my web / email traffic through it to my server.
posted by caution live frogs at 10:30 AM on August 7, 2008

Add another tunnel to your dreamhost ssh session that is port 143 instead of localhost:whatever port. That will effectively pass your traffic through that remote dreamhost server, just like youre doing with local data. You'll also need to to gmail and 25 to send mail.
posted by damn dirty ape at 10:35 AM on August 7, 2008

Try nstx - Tunnel IP over DNS yet?
posted by godisdad at 11:09 AM on August 7, 2008

I'd like to be the party pooper and suggest that you talk to your IT department, as you're seeking to circumvent their security policy, and they may slap you if they catch you.
posted by chengjih at 12:03 PM on August 7, 2008

Response by poster: Thanks to all! I've tried setting up the forwarded local port to a remote host on the remote side.

So, while my personal tunnel looks like this (and works fine):

ssh -L
ssh -L

...the new tunnel I've tried setting up does not work:

ssh -R
ssh -R

For the record, I've also tried:

ssh -L
ssh -L

For the servers in Outlook, I've used localhost:993 and localhost:587

Perhaps, as pocams said, forwarding on my DreamHost server to a remote server is not enabled? Any way I can check that?

Thanks for the helpful advice!
posted by izicwe at 12:05 PM on August 7, 2008

Running ssh with one or more verbose flags might give you some info.
ssh -v
for some debug info or
ssh -vv
for more debug info or
ssh -vvv
the most debug info.
posted by bdc34 at 1:29 PM on August 7, 2008

You definitely want -L and those last 2 lines look correct.

Seconding at least considering talking to your IT guys... just because they left some way for you to work around their security does not mean you should. The day you call them when your company mail doesn't work, and they find some IMAP account and tunneling software installed, you could end up fired.
posted by TravellingDen at 1:54 PM on August 7, 2008

Best answer: To test whether you're allowed to forward to a remote server, do a:

ssh -L

then run "telnet localhost 8765", hit a few keys and hit Enter. You should get a bunch of indignant HTML back telling you that your request was bad; if you get nothing, or if you can't connect, the forwarding isn't happening.

Just to clarify -L vs. -R: -L opens a port on your -Local machine that comes out on the far side, allowing access for you and the processes you -Love. -R opens a port on the -Remote machine that comes out on your side, allowing connections back to you from any -Random person or process.
posted by pocams at 2:54 PM on August 7, 2008

Depending on how Outlook handles the SSL certificates, you may have an issue connecting to the SSL versions of IMAP and SMTP. Basically, the host you're connecting to will be "localhost", but the certificate being presented will be "". Outlook, or perhaps your antivirus, will say, hold on, you're being attacked by a man-in-the-middle. Because that's what's happening. There may be a way to tell Outlook to ignore the SSL/hostname mismatch, but I don't know how to do it.

Note that you can string together a series of forwarding statements in the same SSH command, i.e.:

ssh -L -L ....

I'm also going to re-iterate the whole "ask your IT department first" thing. I used to keep a stick behind my desk for users like you. It was basically half of a bokken that broke during aikido practice, but it was still was a perfectly good LART.
posted by chengjih at 8:15 PM on August 7, 2008

Response by poster: Thanks again for all the insight. I do have a friend in IT that I have checked with; he said basically that they turn the other cheek. The way he put it, since we work for a technology company they have an abundance of people running SSH sessions for various reasons at various times.

I could use some clarification on where to run the commands suggested above. Any further insight? I'm on a Windows Vista machine, running PuTTY for the SSH session to the remote DreamHost server.

So when I'm adding the tunnels, I'm actually adding them in the PuTTY GUI (Change Settings > SSH > Tunnels). My current tunnels (for ports 110 and 25, to the DreamHost mail server) work fine.

To do the check like pocams recommends, do I run those lines on the DreamHost shell? (The "ssh -L" and "telnet localhost 8765" lines) I assume so, because those don't execute in my Windows command prompt.

When I run ssh -L on the DreamHost shell, I get a bunch of flag options:

[server]$ ssh -L
[-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w tunnel:tunnel] [user@]hostname [command]

When I next run "telnet localhost 8765" on the DreamHost shell, I get:

[server]$ telnet localhost 8765
telnet: Unable to connect to remote host: Connection refused

Thanks for the continued assistance!
posted by izicwe at 9:47 AM on August 8, 2008

Best answer: To do the Google test, you set it up just like your normal tunnels; there are no commands to execute on DreamHost.

In the PuTTY Tunnels pane, "Local" is ticked, "Source Port" is 8765, "Destination" is The source port isn't important - it's just an arbitrary one that's probably not in use. Once you've connected with PuTTY, you run the "telnet" command on your own machine.

Unfortunately, it looks like Vista has removed Telnet, so you can test with a Web browser instead. Connect PuTTY with that tunnel set up, then instead of running telnet, browse to http://localhost:8765. If you see a Google page, your forwarding is working properly, and your problem may be with Outlook; if you don't, the forwarding isn't working, and probably can't be made to work.
posted by pocams at 2:58 PM on August 8, 2008

Response by poster: Thanks again to all - your responses have been awesome. I think I'm getting close to figuring this out.

Pocams, the test tunnel with port 8765 and Google worked fine at both home and at work. Now for the kicker - my IMAP and SMTP tunnels to Gmail (ports 993 and 587) worked fine at home, but not at work.

So, why might my personal POP/SMTP tunnels and the Google test tunnel work but not the Gmail IMAP tunnels? I'll take a stab at answering my own question: because ports 993 and 587 are blocked altogether by my network at work...or ranges of ports are blocked. Does that sound right?

I do find it curious that my tunnels for ports 110 and 25 work, but not for 993 and 587, but what the heck.

So, I think I have to find local ports that aren't blocked and then forward them to Gmail ports 993 and 587. So my tunnels should probably look like:

ssh -L [randomport]
ssh -L [randomport]

Does that look right?

Two questions about this:

1. What's the best way to test from my Vista machine whether a port is blocked or not on my local network?
2. Is there any rhyme or reason to choosing the ports to use (so that they'll work on the widest variety of networks)?

Thanks a million!
posted by izicwe at 6:45 AM on August 11, 2008

Response by poster: Well, I've tried a number of local ports that should be unprivileged (2993, 8993, etc.), and none of them will connect my Gmail IMAP tunnels on my work network. I even tried port 8765, which I used to successfully perform the Google test earlier!

I repeatedly get this error:

Task 'Checking for new mail in subscribed folders on Gmail IMAP.' reported error (0x800CCC0E) : 'Outlook cannot check for new mail in subscribed folders for account Gmail IMAP. Error: Cannot connect to the server. If you continue to receive this message, contact your server administrator or Internet service provider (ISP).'

It has to be something in Outlook, then, right?

Any ideas on what to poke around for in Outlook settings/registry?
posted by izicwe at 7:11 AM on August 11, 2008

Response by poster: Got it! I found an unprivileged port that worked fine.

Thanks for all the help everyone!
posted by izicwe at 7:34 AM on August 11, 2008

« Older Hmmmmmmmmmmmmmmmmmmmmmmm   |   Statistics Filter: Finding the top 10% from... Newer »
This thread is closed to new comments.