I have this scenario with 2 fortigate 80E A and B at sites 1 and 2. They both connects to the same ISP with eBGP and of course a link exists between the two sites. I'm advertising network x.x.x.x in site 1 using FG-A and network y.y.y.y at site 2 using FG-B. Both networks exists in the routing table as blackholed routes and are only only usable when a system is Natted to the ips. I want to achieve the following.
1. Make Site-1 the preferred network path for inbound traffic to network x.x.x.x and Site-2 the preferred for path for incoming traffic to network y.y.y.y
2. Be able to Nat a device that exists in site 2 to an IP in network x.x.x.x and have the traffic utilize link in site 2 for outbound and inbound, even though that network originally belongs to site 1.
Ive attached a small sketch. Any help will be appreciated.
Not from my first-hand experiences but I heard it's depending on ISP's BGP setting if you want to use MED to influence their routing toward you (See Cisco Learning Network discussion below). You should contact your ISP first.
The MUTLI_EXIT_DISC (MED) is an optional non-transitive attribute that provides a mechanism for the network administrator to convey to adjacent autonomous systems to optimal entry point in the local AS
In real world since the address is two different ipv4, we would use a FQDN device like a GTM and wide-ip and set the priority for site Y and fallback to site X. So traffic wil always go to site Y and in the event site is 100% down or the server probes die off, you change the DNS TTL and repoint it to site X.
If i understand clearly, there's no way to provide full auto failover to a public web-server across two DCs on separate subnet, when the translation is done on a FG (even when both sites are in the same AS), without manual modification of dns record.
I was looking for solution to ensures traffic gets to the same webserver on same ip address irrespective of the resident DC. That way, i wont have to modify dns record whenever i switch DCs.
I used Ecessa PowerLink WAN aggregator for the past 10 years. Their appliances have a number of features one being DNS SOA. We set our TTL settings for DNS records to 30 seconds, but could go lower, for faster IP address updates upon DNS cache expiration. We also setup DNS load balancing (alternating IPs), local and/or site-to-site fail-over redundancy with multiple IP addresses for the same FQDN.
With their appliances they claim BGP is no longer required due to their WAN aggregation, load balancing, link-state awareness, and DNS SOA features; now offers SD-WAN capabilities as well. Even though, I still implemented BGP multi-homing via a single ISP (iNAP formally interNap), who algorithmic-ally leveraged multiple tier 1 carriers for additional redundancy, used separate AS numbers out of their own and partner collocation data centers. In our case we used a /23 subnet split between two sites providing both DNS load balancing and site-to-site DNS redundancy. Note with the Ecessa's DNS SOA we experienced better fail-over response time than with our BGP multi-homing fail-over convergence times.
In production I had multiple appliances over the years in a HA fail-over configuration. My Initial implementation began load balancing two 3Mb circuits between with multiple ISPs, then a few years later upgraded to multiple 100Mb Internet connections, and then more recently multiple 1GB circuits. Basically, every three years had hardware and circuit upgrades.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.