1

Current:

  • Primary ISP - fiber
  • Backup ISP - DSL

We have various apps/services like VPN, email, etc. that come in on various external IPs on the primary ISP.

Is there a way without BGP peering to have a way to allow failover of incoming services like the above?

For email I can't use secondary MX records, as we use a cloud service for email scrubbing and then email is sent to an external host record from them.

I don't think there's a way to create multiple Host A records with varying metrics, but that would be the logic I'm looking for. Something that says "vpn.domain.com resolves to 1.1.1.1 but that isn't responding so fail back to 2.2.2.2". Obviously, the complication is how does the app/service really know that 1.1.1.1 isn't responding.

Anyone figure out solutions to failover incoming apps/services between ISPs?

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • This answer is semi-relevant: http://serverfault.com/a/304266 Letting the DNS round robin might work, if the services are always functional on the backup address? Or, are you able to have to have a proxy somewhere else handling the failover logic? – Shane Madden May 25 '12 at 15:34
  • @Shane - My thought was to let the firewall stack policies. So the "top" policy would be incoming on the primary circuit, the next policy would be the backup circuit. Again, this is all theory at this point. – TheCleaner May 25 '12 at 16:01

2 Answers2

2

There's no easy way to do this in a generic sense. DNS allows for prioritisation of MX records, but if you configure multiple IP addresses for your other services, clients will simply select one of the addresses at random; something you don't want if your fibre service is appreciably faster than your DSL.

It comes down to the configuration of the client software. For your email, I would expect any 3rd party scrubbing service to allow for two or more prioritised hosts for onward email. (I'd regard it as a significant failing if that facility wasn't available.)

If you're using OpenVPN, for instance, you can configure multiple remote lines and the client will try them in the order given, which works as a reasonable failover. For others, you could configure clients with a separate, backup connection, but that's a bit manual and requires a certain amount of user training.

When it comes down to it, you have to consider what it's worth to have proper resilience in place and either splash out on an additional, equal-quality path with BGP, or make managment aware of the limitations of the existing solution.

Note: The priority/weighting mechanism you've described is covered by SRV records (used extensively in AD DNS records), but there's no standard describing how they should work for internet services. (Though it has been suggested)

Community
  • 1
SmallClanger
  • 8,947
  • 1
  • 31
  • 45
  • Thanks. So it seems like my concept of "vpn1.domain.com" and "vpn2.domain.com" as VPN connection settings for clients along with user training of "use VPN1 unless it isn't working, then try VPN2" is my only failback at the moment, unless, as you say, management is willing to put proper resilience in place. – TheCleaner May 25 '12 at 16:17
  • Yep. Unless the VPN client has a built in failover mechanism, then the manual route is the only choice. – SmallClanger May 25 '12 at 17:01
0

The way I do it is set the TTL for the relevant entry in DNS to be very low (let's say 1 minute). Then, if the primary line is down, I'll manually change it to point to the secondary IP. It's not automatic, but it works.

Bigbio2002
  • 2,763
  • 11
  • 34
  • 51
  • And fails for clients that have DNS resolvers that retain records longer than the TTL, unfortunately. – mfinni May 25 '12 at 17:40