SD

Hi Guys,

I've 4 quick questions about our new Disaster Recovery site, which I'm visiting tomorrow to install a new Checkpoint Firewall Cluster (R60) running on a pair of Splat boxes, just like is currently setup at our HQ site. This is the infrastructure simplified:



Both firewall clusters will be managed by a management station at the HQ site, with a secondary (backup) management station at the DR site. HQ's firewalls are currently defined and licensed by their external interfaces.

Unlike the current DR site, (which is connected via a leased line which we can route any addressing over), the new DR site will only be connected to HQ via our group MPLS network, which only routes traffic in the 10.0.0.0/8 network. As I've had the new firewalls also licensed by their external (public) addresses, myunderstanding is that any management traffic from the management station at HQ to the DR firewalls will therefore have to go over the internet.

Q1. Is this understanding correct, or could I make it 'talk' to one of the other (10.0.0.0/8) interfaces, using NAT or somesuch at HQ?

Q2. My understanding is that it is safe to route the management traffic over the internet as all this management traffic is encrypted using SSL, right?

However,

Q3. Is there any benefit to having the licensing for the new DR firewalls changed so that they're licensed by their internal interfaces, thus enabling them to be managed over the Group MPLS network?

Obviously in the invocation of DR and the promoting of the DR management station, then all HQ firewall management traffic would then be sent over the internet, so,

Q4. Is there any benefit to spending the time and effort to redefining the HQ firewalls to be licensed bytheir internal interfaces? We have many VPN users (and hope to use multiple entrypoint VPN in the future) so would this change mean we'd have to redefine the sites for all our SecureClients, or would they get this update as part of their normal logon topology and policy updates?

I realise I'm asking a narrow audience with these questions, but anyone with any knowledge or experience to bring to bear on these questions, your assistance would be much appreciated as I start work at DR tomorrow..!

Many thanks,

Simon.

Kermit

Hi there,

A couple of questions,

Checkpoint offer different type of licensing depending on whether you want true HA or standby

If you want true HA you will need a fast connection between the two FW's.

Q1. Management traffic doesn't have to access the licensed address, you can use the internal address.

Q2. Never route/allow management traffic over the internet, its a major security risk (even if you tunnel/vpn/encrypt). Its just bad practise

Q3. The only reason you license to the external address is because that its the least likely to ever change (in theory). There is nothing stopping you licensing to the internal. But if you have licensed all your products correctly (two FW's on the one internet connection, and the other two FWs on the other internet connection) then there isnt any issue.

Q4. Relicensing shouldn't take too long. I am trying to think if it would affect the VPN/site topology. The topology update doesn't included the license detail - thinking off the top of my head.

Kermie.

SD

Hi Kermit,

Thanks for taking the time to answer.

Our HQ cluster is a full statesync HA cluster, and similarly our DR site will be another full statesync HA cluster, both for their respective sites and not for synchronising with each other across sites, if you see what I mean... All 4 boxes run on Splat.

'Q1'. So are you saying that when I setup the new DR firewalls on the management station at HQ, I could define their primary interface as an internal one, despite them being licensed using their external interfaces?

'Q2' I had a suspicion that this might be the case, despite our support company claiming it was fine!

'Q3' So I can leave all fws licensed to their external, but choose whether to define them by their internal as I please?

'Q4' I dunno either... Resetting up the VPN site for each remote user would be a major pain in the ar$e though!

Thanks,

Simon