System iNetwork

September 2008

September 1, 2008 4:06 PM

Sharing Internet for Redundancy

Dear Doctor,
A neighboring company with a high-speed Internet connection similar to ours, but from a different provider, has proposed that we pool our resources so that one company's connection can support the other company should it lose Internet access. A Cat-5 cable already interconnects our two data centers. I've found a number of firewalls that support dual-WAN configuration, so we bought a pair and paid for a fiber optic cable between our buildings. Alas, I can't figure out how to interconnect the two firewalls so that they fail over correctly. Each has its own WAN IP address, and connecting the four WAN ports in a common switch (one at each location) results in "IP address spoof" error messages, and failover doesn't work. How can we disable these errors in our firewalls and get them to fail over correctly?

Gentle User,
Don't touch those firewalls! They're only doing their job. Disabling "spoof" messages without addressing the cause of the message is like disabling a beeping smoke detector without looking for actual smoke. The firewalls are telling you that there is a problem, and in this case it's a simple one: You can't securely mix traffic from two different IP subnets on the same Layer-2 Ethernet domain.

The fix is easy: Replace the low-end switches you installed at each location with more modern, full-managed Ethernet switches that have Virtual LAN (VLAN) capabilities. Then create two VLANs, one for each firewall WAN IP subnet, and trunk the VLANs between buildings. You can now plug the two firewall WAN ports (primary and failover) on each site in to the two VLANs. Spoofing errors will cease, and failover will work like a charm.

Posted by mbeckman on September 1, 2008 at 4:06 PM | Comments (0)

Missing Incoming Email

Dear Doctor,
We've recently seen a sudden increase in reports of lost email — email our users send that recipients never receive. Last month we moved our System i email server to a collocation facility, which entailed changing the server's IP address. Everything seemed to be working fine, but now this problem has cropped up. The colo facility manager sees no connectivity or traffic problems, and we're receiving no bounce or other error messages. What would cause only certain messages to be dropped?

Gentle User,
Dr. I Doctor wishes you had provided more detailed information about the kind of messages being dropped. Are all messages to particular destinations dropped? Or only those mailed from certain originators? Is there any kind of pattern? Alas, you are not here to answer these queries, so Dr. I Doctor will have to use the shotgun approach.

But first the answer to your last question: What would cause only certain messages to be dropped? The unhappy answer is that not all mail servers apply the same rules when accepting inbound mail. Some will take mail from anybody, others conduct various tests to try to reject potential spam and malicious emails before they gain a foothold on user computers. Dr. I Doctor suspects your mail server is being misidentified as harmful. Common practice dictates that harmful messages be dropped with no warnings, which might give interlopers insight into a destination mail server's filter process.

The first check to conduct is an easy one: see whether your mail server is listed on any email blacklists. You can do this easily at senderbase.org, a site that will match your mail server's IP address and domain name against dozens of potential blacklists. If you're on a blacklist, SenderBase will direct you to instructions for remediation. Addressing whatever caused your server's blacklisting in the first place will likely solve your problems.

If you're not blacklisted, the second most common problem is incorrect DNS information for your mail server's IP address, a plausible concern given you just changed that address. A reverse-DNS lookup on the IP address must return a name, and a DNS lookup on that name, in turn, must return the original IP address. A failure of either test means your mail server looks a lot like a spoofing source, one from which many reputable mail servers will refuse to accept mail.

The third most common problem is server misconfiguration. Often you simply have a spelling error in the server's official name in the mail configuration file. For example, if your server is named "postmaster.acme.com" and you inadvertently have "toastmaster.acme.com," the greeting message your server gives to other servers might not be universally accepted, causing outbound mail dropping.

A fourth issue is an incorrect Sender Provider Framework (SPF) DNS record value. Although not required, when an SPF record exists, it must accurately list the mail servers authorized to transmit mail for your domain. Given the recent move of your mail server, if you have an SPF (always a good idea) and forgot to update it with your mail server's new IP address, recipients that check the SPF record would drop your transmissions.

Posted by mbeckman on September 1, 2008 at 4:04 PM | Comments (0)