In late 2002, a company I've been workng with moved offices in San Francisco. Unfortunately the T1 circuit at the new office wasn't quite ready when we moved, so we had to improvise. It ended up being pretty complicated but it worked. Hopefully by sharing the details of how it got working, you the reader might be enabled to pull goofy TCP/IP stunts like this in the future to the benefit of mankind. Or something.

Okay, here's what it looked like before we moved:

Simple enough.

We only needed connectivity for a few days while the T1 was being installed. Fortunately one of our neighbors in the office building was kind enough to let us string a really long Ethernet cable down the hall, so we could use their business DSL connection for a while. Unfortunately, either their DSL modem or their business DSL provider was acting as a firewall, blocking all incoming TCP/IP connections. So, we could surf out, but mail and VPN traffic couldn't get in. That's bad, since we host our own mail server. I added a Linux-based firewall which I named "Slinky" (since I couldn't be sure of what their firewall was blocking overall, I added Slinky just to be certain that all the safeguards I wanted were in place). The result was this:

After a bit of inquiry it was pretty clear that our neighbors didn't really know how their setup worked or how to change it... and it's quite an audacious thing to ask someone if you can leech bandwidth and then to complain that it isn't good enough and ask if you can just change their firewall rules a bit... so I decided not to try and mess with their firewall. Who knows, it might have even been run by the ISP, who would be even less cooperative considering we weren't actually the customer. So, the firewall was basically something we were stuck with.

So, the main problem was, how do I get mail from the internet into this network if I can't connect in? The answer was to use Secure Shell (SSH)'s Reverse Port Forwarding feature, and my own internet-accessible mail server at home. Secure shell is a highly respected solution in the security community for connecting from one internet host to another securely. It's basically one of the only things that most computer security weenies trust, and of course they don't trust it 100%... it's just the least insecure thing they have on hand.

Anyway, SSH is mainly for interactive command-line sessions, but it has a cool feature called Port Forwarding that lets you run other TCP/IP connections over the encrypted SSH connection. There's also Reverse Port Forwarding that goes in the opposite direction. That means that the SSH server will listen on a port on the same server for connections, and when one is made, the ssh client on the other end will make a connection from that host to wherever you tell it!

Fortunately I have a Linux server at home that could be used to set something like this up.

So, I set up an SSH connection like this...

...and set up Reverse Port Forwarding like this:

(Note that I also needed to set up redir because SSH reverse port forwarding wouldn't listen on a specific IP address on the remote host.)

We had to set up DNS so that the mail exchangers for thiscompany.com were mail.thiscompany.com (at its old address, 63.122.127.220), and ns.white-mountain.org. I set up my mail server on ns.white-mountain.org so it knew it was supposed to be a relay for thiscompany.com email (otherwise the anti-spam no relaying rules would have caused the email to bounce). Finally, I added the IP address 63.122.127.220 to ns.white-mountain.org's second ethernet card (the one that faces my internal network, so it doesn't have a firewall blocking port 25).

What this all adds up to is a working configuration for inbound mail. Here's how it works:

1. A remote mail server gets an email message addressed to jamie@thiscompany.com
2. The remote mail server looks up the list of mail exchangers for thiscompany.com
3. The DNS server at UUNet (where thiscompany.com's DNS info is served) responds with mail.thiscompany.com (preference 10), and ns.white-mountain.org (preference 20).
4. The remote mail server looks up the IP address of mail.thiscompany.com and gets 63.122.137.220 (which is what it was at the old office).
5. The remote mail server tries to connect to port 25 (the one for SMTP e-mail delivery) and fails because the mail server isn't there anymore (it's in the new office).
6. The remote mail server tries to connect to port 25 of ns.white-mountain.org and succeeds.
7. The remote mail server says it has a message for jamie@thiscompany.com and ns.white-mountain.org says that's OK
8. The remote mail server delivers the message and closes the connection.
9. ns.white-mountain.org tries to deliver the message since it knows it's just a relay. That means it tries to connect to port 25 on 63.122.137.220. Since that IP address happens to be bound to one of the ethernet cards in the very same server, it succeeds.
10. Redir notices the connection from 63.122.137.220 port 25 and makes a connection to localhost port 2525, where the SSH reverse port forwarding connection is listening.
11. SSH notices the connection from redir and tells the other end to connect.
12. The SSH client on Slinky makes a connection from Slinky to mail.thiscompany.com, which is not blocked by the firewall since both servers are behind that firewall. Ta daa, now there is a connection from ns.white-mountain.org all the way across a hostile firewall to mail.thiscompany.com!
13. ns.white-mountain.org delivers the message to mail.thiscompany.com.

After a few days the T1 circuit was installed and I set up the T1 router to be the firewall again (all the rules had to be updated with the new IP addresses that came with the T1). That involved some troubleshooting too since the T1 wiring inside the building was wrong and I had to sacrifice an Ethernet cable to make it work, but That Is Another Story.

I hope this helps! If you have any questions email me: jamie@white-mountain.org