- 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 188.8.131.52 but that isn't responding so fail back to 184.108.40.206". Obviously, the complication is how does the app/service really know that 220.127.116.11 isn't responding.
Anyone figure out solutions to failover incoming apps/services between ISPs?
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)
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.