Temporarily re-direct traffic to another site

[lammbo]

(WHAT I WOULDN'T GIVE FOR F5 BOXES INSTEAD OF ASKING THIS QUESTION)

SCS = R65 (HA)
Old ATL Gateways = R60 HFA_04 (New mode ClusterXL HA)
New ATL Gateways = R65 (New mode ClusterXL HA)

VPN is traditional mode with pre-shared secrets


We are currently in a position where we will be moving our Hosting services site to a new CO-LO in ATL. I already stood up new firewalls at the new site. The new site will have non-overlapping internal subnets and new external address ranges. Most of the traffic from clients is 80/443. The move will be completed in phases with as little down time as possible.

Needless to say, when we move web servers, there will be a very large DNS mess.

In an effort to make the transition as smooth as possible, is there a way to redirect traffic arriving at the old site to the new site using the firewalls so we can proceed more cautiously than an all-at-once deal?

[dantro]

I'd recommend using NAT.

[lammbo]

Anyone out there have experience with ConnectControl?

I'm being told that this is basically a scaled down version of what F-5 can do, but I see no mention of different sites being involved. Also, I was told R65 was OK as well, but the supported platforms on the list stop at R62 on the website.

All I can find regarding documentation is the 2 page data sheet. If anyone knows where the documentation is, please provide a link so I can do my homework.

[dsb.nepo]

Needless to say, when we move web servers, there will be a very large DNS mess.

If you have full access to the dns zones or you are the primary dns then there are some ways to minimise problems (SOA records).

In an effort to make the transition as smooth as possible, is there a way to redirect traffic arriving at the old site to the new site using the firewalls so we can proceed more cautiously than an all-at-once deal?

I don't know the volume, but maybe it is possible to work with mapped service to minimise the effect
old site: ip1 -> http_mapped_ip1 (80,new_ip(via vpn),80)

also I can think about a dedicated balancer behind the old FW that do the redirect (OpenBSD comes in my mind very intuitive and fast to setup)

[mcnallym]

Is buried in the Firewall and SMARTDefense guide, if want the manual for Connect Control. As you already realise is no way near an F5 but may be enough for you.

Isn't cheap though, as is $8000 on price list per gateway, and isn't part of the standard VPN-1 license.

I had a customer ask about it recently which I had to refresh for.

[lammbo]

Thanks for all the info guys!

Management has finally abandoned the re-direct notion. The plan is now to move the BGP advertisements to the new data center while we are down during the move (both Data Centers are onboard with this). Of course, this now adds a different challenge (or if my assumption is correct, no impact).

More topology info:
All gateways managed by same SCS (R65 HFA_02)
Each site has it's own Policy - set to install only to it's appropriate gateway cluster
SiteA (old) (R60 HFA_04)
SiteB (new) (R65 HFA_02)
SPLAT gateways using Auto-NAT
OldHost@SiteA has x.x.x.x as NAT - Only set to NAT at SiteA (not ANY)
NewHost@SiteB has x.x.y.x as NAT - Only set to NAT at SiteB (not ANY)


When I started this, I stood up the new firewalls with new subnets. I cloned every host object (we'll call this OldHost@SiteA) from the old site. When I did this, I renamed the cloned host (we'll call this NewHost@SiteB); I changed private IP octets 2 and 3 to match the new site's topology and changed the Public IP for the exposed servers to match what was going to be, in the original plan, the new Public IP range (only the 3rd octet changed).

With this new development, I will have to go back to these NewHost@SiteB hosts and change back the 3rd octet on the Public IP.

Given this information and the fact that BGP will not be advertising at SiteB until we go down for the move, is it possible for me to pre-change NewHost@SiteB back to the original NAT from Site A x.x.x.x, as opposed to x.x.y.x, and still be able to push policy without breaking the NAT at SiteA.

My thoughts on this are that I should be able to do so because the NAT is set to install only to a specific gateway. Therefore, when I push policy to SiteA, it will not try to auto-NAT using SiteB private IPs since the NAT is not installed on that cluster for cross-site hosts.

NewHost@SiteB will now have the same Public IP as OldHost@SiteA in the rulebase/NAT table, but SiteA should continue to function even though SiteB is ready for the hosts as soon as BGP adverts start at SiteB.

Is this a correct assumption? Otherwise, the fallback plan is that I change everything in the rulebase now and can't push policy until SiteA is down @ 3AM on Sunday.

[lammbo]

My support team confirmed this should not be an issue.

I just tested using a host that I could break without customer impact and everything works as I suspected on my live systems.

Policy can be pushed when 2 hosts have the same static IP as long as you set the NAT to install on just it's own gateway and not ALL gateways.

So once my BGP adverts move to the new site, all of the hosts are already setup using the same static/hide NAT they used at the same site.

Hope this write-up helps someone else in the future.

(Hey, this is my 100th post! Senior Member, woo hoo!)