ā01-21-2021 08:07 AM
Hi,
I currently have 2 Cisco FTD 2110 devices in a HA pair. Both FTD and FMC are running 6.4.0.3 code.
My primary ISP assigned a /27 public block (100.100.100.0/27 for example) being leased to me, I do not own them.
So I was able to implement some one-to-one NAT statements for my Web Servers and everything works fine with that.
BUT now
I would like to add a secondary ISP (200.200.200.0/27 for example) for redundancy only in case primary ISP ever fails.
I understand in the FMC I can implement SLA tracking for the ISP failover monitoring, and that works fine for dual ISP failover/monitoring.
So my question is how would that work with the one-to-one NAT statements, using my primary ISPs block (100.100.100.0/27) I already have, to access my web servers from outside etcā¦?
Meaning if a failover ever happens, and the FTDās fails over to the secondary ISP (200.200.200.0/27), how can I get those one-to-one primary NAT statements of (100.100.100.0/27) to carry over to secondary ISP line?
Is there a way?
Do the second ISPs usually route traffic from another ISP like that?
My ISP did respond with this , ISP A will not redistribute another providers bgp subnets smaller than a /24 (246 IPs) via bgp peering as it is a stress on the routerās memory holding all the routing tables.
Is there a solution to have that this to work, or another way to achieve same thing so the outside just needs that one unique IP to access the web servers IP etc...?
Thanks Everyone
ā01-21-2021 10:35 AM
One option would be to use a cloud-based load-balancer (application L4/L7 or DNS load-balancer). You would have to setup each application with two external 1-to-1 NATs (e.g. 100.100.100.5 & 200.200.200.5) so that each application is available via either ISP (regardless of which is primary).
Here are few options: https://geekflare.com/cloud-load-balancer/
ā07-22-2021 01:08 AM
sorry if i will have load-balancer I do not have to do nat for 2 isp?
ā07-22-2021 01:17 PM
No you would not need to do NAT for both ISPs. one NAT statement for traffic from inside to outside interface (for example) and the load-balancer would take care of forwarding traffic to the active ISP.
It would be better if you create a new post for your question as this post is quite old, and you would get focused response to your issue.
ā01-22-2021 10:43 AM
The best solution is what Georgi has already mentioned, place a loadbalancer between the ASAs and ISPs. But if this is not an option you would need to perform manual failover of the NAT statements. You would need two sets of NAT statements, one for the primary ISP which is active and a second NAT for the secondary ISP which is disabled. When a failover occurs you will need to disable the Primary NAT statement and enable the secondary NAT statement. I suppose this might be possible to script.
You will also need to consider DNS lookups (if you have URLs for accessing the servers behind the 1to1 NATs. If you have a failover situation you would need to update the IP for these domains.
ā01-25-2021 10:57 AM
Thanks all. Is there any other way besides the above?
Is it either we just need to get a /24 ?
or we just do a PAT to the new ISP for outbound only and the 1to1 NATās can not be migrated?
Thanks.
ā01-25-2021 11:36 AM
Is there any other way besides the above?
No there isn't unfortunately
Is it either we just need to get a /24 ?
I am not sure what you mean by this, If you are thinking about DNS, there is no amount of IPs that will prevent you from having to change the global DNS records, unless you have set up a different domain for the standby.
or we just do a PAT to the new ISP for outbound only and the 1to1 NATās can not be migrated?
The NAT rules can be configured at the same time but depending on how you have the NAT configured you can get unexpected behaviour. That is why the standby rules should be disabled and then manually enabled when a failover situation happens.
ā01-25-2021 05:34 PM - edited ā01-25-2021 05:37 PM
>>> Is it either we just need to get a /24 ?
Some ISP's still have sufficiently large blocks of reserved IPs, which they are willing to lease. If you are able to provide sufficient justification for /24 block of public IPs to be allocated to you, you will have one of the requirement needed to implement the design.
To be able to advertise /24 block of IPs to two IPS, you will need the following:
1. /24 or larger block of IPs
2. Register an public ASN with ARIN
3. Letter of authorization from the owner of the IP block allowing you to advertise the /24 via you ASN
4. Letter of authorization from the owner of the IP block allowing your uplink ISPs to propagate the BGP prefix (this can be combined with #3)
5. Request BGP peering with each one of your ISP providers (usually higher tier of service to support BGP)
5.1 Decide if you will be accepting full routing table, partial routing table, or just default route from each ISP
6. Setup your internet edge router(s)/firewall(s) to BGP peer with your two ISP providers
6.1. Setup BGP routing preferences for primary and backup ISP
--
Please remember to select a correct answer and rate helpful posts
ā01-25-2021 05:48 PM
>>> Is there any other way besides the above?
You either have to have /24 block of public IPs (as described above in my post) or use the cloud-based load-balancer. If your company is smaller or has smaller IT department, the cloud-based load-balancer solution is much easier to support long-term as it requires much simpler on-premise infrastructure. You will be able to change your ISP's more easily as web site users will be going to your load-balancer public IPs. The down-side is that cloud-based load-balancer will have additional cost.
--
Please remember to select a correct answer and rate helpful posts
ā01-25-2021 05:54 PM
>>> or we just do a PAT to the new ISP for outbound only and the 1to1 NATās can not be migrated?
I am not sure how this option provides a solution for high availability to your Web Servers. You will be using two ISPs and two circuits, but each ISP circuit will be used for two different use cases (i.e. outbound for office users and inbound for Web Servers) and both ISP circuits will not be providing automatic failover to each other.
--
Please remember to select a correct answer and rate helpful posts
ā01-27-2021 06:16 AM
If it's possible place a router in front of your deployment and do NAT there along with SLA and some scripting for failover, so on FTD you'll only have to deal with access policy not NAT.
ā01-27-2021 10:40 AM - edited ā01-27-2021 10:42 AM
Hey @Panos Bouras,
You bring a really good point. In networking there is always yet another way to do things. Thank you for jogging my brain.
Moving the ISP#1 and ISP#2 internet circuits to Cisco router does give us some additional flexibility and programmability with IPSLA, trackers, and EEM scripts. The configuration can get pretty complex (depending one's Cisco routing experience), but it should be possible to NAT and Default Route changes needed for failover.
The last piece would be to address the external DNS changes so that external users are accessing Web Servers via their new public IPs (NAT-ed on the router). Cisco routers support Dynamic DNS with various providers (http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/811-cisco-router-ddns.html)
In this case the FTD firewall(s) would simply be responsible for inspecting and filtering the traffic.
This is not the easiest option, by far as it requires multiple configuration pieces to all work together. Troubleshooting will also require more in depth knowledge and experience. If the OP gets this configuration working, it would be nice he can post it back here for others.
--
Please remember to select a correct answer and rate helpful posts
ā01-27-2021 11:29 PM
I'm no DNS expert, the external DNS could point to 2 IP (you can play with priority and weight of each record) one for each ISP, but I'm not sure how the client connection will work as this is an application behavior design e.g. how it would use the 2 records returned by the DNS.
From your side just make sure that your HTTPS certificate will match that DNS response in case that you'll use different FQDN, a wildcard or multi SAN certificate should work.
ā01-28-2021 05:39 AM
Additionally, if you have BGP peering with your ISPs then just change ask them to send default route and change the weight for your preferred one and let BGP handle HA for you. I assume that this is enough and more secure than trying to SLA track an IP via ICMP. Your NAT could be based on route map and I believe that his way there's no need to have EEM as you can match on source IP and destination Interface per NAT rule.
Just account that during failover you might get issues with clients already connected, as the reply could come from a different IP.
ā01-29-2021 06:30 AM
Thanks everyone for responding a great explanations! Appreciate it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide