I'm having a hard time finding much, if any, documentation on this scenario. I've tried a couple ways of doing it and they work, but I'm trying to figure out what the best way to do it while being as redundant as possible.
What I like the best so far is to have the portal and a gateway up on a floating IP so it can bounce from one firewall to the other as needed. However, doing that adds a route to the virtual router on both firewalls for the tunnel (client) addresses. If a client connects and gets terminated to the tunnel interface on firewall 1, accesses a service, and then return traffic comes back into firewall 2, it dies because it thinks the client is on that tunnel interface, when it isn't. Does that make sense? If there was a way to have the tunnel interface also follow the floating IP that would be great. This would only install the route on the firewall that needs it.
Another way I thought of doing it is a portal and gateway on firewall 1, and a portal and a gateway on firewall 2. Then in my DNS, the portal DNS record (vpn.domain.com) answers with both portals and the gateway DNS record (gw.domain.com) answers with both gateways. That doubles the configuration that has to be made, but solves the route being installed on both firewalls when clients are only connected to one firewall.
Is there a proper way to do this?
Solved! Go to Solution.
can you not just have different ip pools/subnets for each gateway.
not sure about dual DNS entries as DNS will not offer both addresses, it will round robin between the two.
if gateway 2 goes down then the DNS may still offer GW2.
Yes, the DNS will round robin, but the expectation is that if a gateway/portal had gone offline users would still be able to get to the remaining one. There might be a delay as the connection times out and DNS gets hit again, Just a thought, but configuring a double of everything is a big pain.
So here's what I ended up doing.
One portal. It's on a floating IP that floats from firewall to firewall as needed.
Two gateways, one for each firewall. IP is on the interface itself, not floating. Each gateway has its own block of IPs for VPN terminations. Portal is configured to have both gateways with equal priority (let the client decide where to connect).
So far this is the cleanest and removes the routing problem. The only issue is that failover is not clean for users that are currently connected as the client has to terminate one tunnel and reconnect to the other gateway, but it does work.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!