Routing a backup email server through a VPN tunnel

Our network has two DSL circuits - a primary business line from SBC, and a backup residential circuit - and we've found a way to get our inbound email even when the primary circuit is down. This Tech Tip details our strategy.

We use a Netopia R9100 ethernet-to-ethernet router between our inside network and the outside world, and it has provisions for only one default gateway: it's the blue line in the diagram:

On the rare occasions when the primary DSL circuit goes down, we manually login to the router to change the external IP address, netmask, and default gateway to use the backup circuit (shown in red).

This manual change - which takes just a few seconds - brings the inside network fully back up (albeit slower) for browsing or any other outbound activities, but for inbound traffic we come to a complete halt. This is a problem mainly for email, so we found a strategy that allows us to use a VPN to a remote site to provide immediate mail service.

VPN configurations

The Netopia router supports IPSec VPNs, and we have almost a dozen of them to customer networks. These VPNs are fully encrypted and authenticated, providing secure access to internal networks - this has worked really well for a long time: Netopia has excellent VPN support.

All of our outbound VPNs have NAT -- Network Address Translation -- applied to the tunnels, which means that we can get to the customer network, but they can't get back to us. Otherwise one customer could get to not only our network, but to other, unrelated, customers. This seems like a bad idea.

We use the Netopia "Server List" facility to create a "pinhole" that opens a port on the tunnel: any inbound traffic to the designated port is routed to a particular server inside our network. We do this for SSH and SMTP, and it's the latter that allows for VPN-based backup MX.

Mailserver configuration

One customer's mail server is designated as our backup MX server. Typically, a backup mailserver receives email and sends it right back out to the IP address of the primary mailserver. But since the IP address is obtained from the DNS, this is an external address, and this would do us no good if our main DSL circuit were dead.

Fortunately, we use the excellent Postfix mail server, which makes this problem easy to fix.

The first step is to add our domain name ("unixwiz.net") to the "relays" file, which tells postfix that it's allowed to relay mail for that domain: all others are refused. This restriction is designed to prevent mailserver hijack by spammers.

The next step is specific to the VPN tunnel: we add an entry to the "transport" file that directs where mail for the domain should be routed. This overrides any data obtained from DNS and lets us send mail through the tunnel:

/etc/postfix/relays

	unixwiz.net  OK

/etc/postfix/transport

	unixwiz.net  smtp:[192.168.7.254]:25

Here, 192.168.7.254 is the IP address of the VPN tunnel as seen from the remote customer, and :25 is the TCP port number for the SMTP protocol.

Once the associated DB files are rebuilt (see this Tech Tip for information on using "make" to automate this), inbound email for unixwiz.net is routed to our mailserver via the VPN tunnel.

In the event of a primary DSL circuit failure, we manually update the router with the backup IP parameters, and the router automatically re-establishes the connection with the remote customer(s). From the customer network's point of view, all that's happened is that the tunnel was down for a short time.

When the main DSL circuit comes back, we revert the router to the original configuration and the tunnel rebuilds itself again.

Other notes

It's clearly possible to put a backup mail server on the outside network with the secondary IP address information and perform the same routing, but the solution we've come to involves no extra hardware not otherwise required. This may not be sufficient for really high volume sites.
We suspect that that IP address changes in the router could be done automatically via SNMP when a monitoring server inside our network finds the main DSL has died, but we've found it so reliable that we haven't seen the need to automate it.
It's possible to effect this change by updating DNS, but this involves a time lag we don't care for, plus it's simply another step. This VPN solution requires nothing other than the router IP change, and the email starts working "for free".

Navigate: More Tech Tips