[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1166
  • Last Modified:

Migrating to a new ISP

We will be moving to a new ISP and want to get some advice on the smoothest transition.  We currently have a class C public network block from Verizon.  We really only use about 40 of those IP for inbound mail servers, web servers, FTP and such.    We want to move to the new ISP for greater bandwidth, but do want to keep the old ISP as a backup (more on that later).  

We currently have a checkpoint NGX firewall with 3 interfaces (room for more).  DMZ, Private, Public.  We do not host our own DNS, our zone file is with Verizon with our domain.  We don't have control panel access to modify ttl and such.. we have to call it in.  My concerns are below.  Please comment on each point as well as a chronological plan to achieve the least amount of downtime.

1.  SSL enabled websites?  How will those be affected if I just change the IP?
2.  Checkpoint Firewall NAT rules? Any order/advice on how/when to change these or whether to create seperate objects and different rules in parrallel?
3.  Mail MX records.  When to change them.  trying to not lose any mail in between switchover.
4.  Best/least cost way to setup the secondary ISP as a backup?   We'd like to be able to revert back to the old ISP (and obviously the IP block they have assigned us) when an outage occurs.  I know there are the expensive F5 networks that provide some type of load balancing/ip change, but those are about 50K.   Any creative ways to achieve switch over within 2-4 hours without expensive hardware/software?
0
rdelrosario
Asked:
rdelrosario
  • 2
2 Solutions
 
deimarkCommented:
Hiya

I will answer inline


1.  SSL enabled websites?  How will those be affected if I just change the IP?

No effect, the SSL cert is bound to a hostname, nowt an IP, ie ssl.company.com ratehr than the resolved IP.


2.  Checkpoint Firewall NAT rules? Any order/advice on how/when to change these or whether to create seperate objects and different rules in parrallel?

If you have created manual rules, then we will need to edit the rules manually also to reflect the new addresses.

Most of the automatic uses of NAT can be edited within the network objects themselves, ie if you have static nat on a web server, then when the ISP is changed, (which implies new external IP range) you would edit the web server object and change the NAT IP its to hide behind.

The main process for the CP firewall would be:

1.  Change interface addresses via the underlying OS (ie in SPLAT use sysconfig to change interface IP)
2.  On Check Point Dashboard, open the GW object and go to topology.
3.  Click on "get interfaces with topology"
4.  Ensure that the new interface IP etc has been detected, then click on OK
5.  Edit the relevant network objects for NAT as above
6.  Push policy


3.  Mail MX records.  When to change them.  trying to not lose any mail in between switchover.

No easy way to do this unless you have a real short TTL on the DNS records.  I will revert to another expert for this part.

4.  Best/least cost way to setup the secondary ISP as a backup?   We'd like to be able to revert back to the old ISP (and obviously the IP block they have assigned us) when an outage occurs.  I know there are the expensive F5 networks that provide some type of load balancing/ip change, but those are about 50K.   Any creative ways to achieve switch over within 2-4 hours without expensive hardware/software?

In Check Point, you can configure ISP redundancy to allow you to have 2 WAN connections, however, it will not allow you to easily modify the NAT addresses for objects.  If you tell us what version of NGX you are using, I can get some docs that will explain this a lot better.
0
 
rdelrosarioAuthor Commented:
Deimark,

We are running CheckPoint NGX R65 running SPLAT.  Can you enlighten me on how ISP redundancy works on checkpoint.   Would we just hook the other ISP router ethernet to another interface on the checkpoint box and then checkpoint handles/MONITORS a dead circuit.    I'm not quite following you on the NAT affect.  Am I to assume that we would have both ISP connections connected, but only 1 active at a time from checkpoints perspective?  ANy info on this would be appreciated.
0
 
deimarkCommented:
IN your dashboard, there is a very good help feature which will go into a lot more detail on the ISP redundancy front, which will also explain the NAT too.

If the normal help files dont cover it for you enough, let me know and I upload the R65 admion guides for firewall and smartcentre (there are decent sized PDFs, so best to try the help files first)
0
 
xcomiiiCommented:
I would strongly recommend that you move your domain into a domain provider that allows you to edit your TTL and records your self. Many migrations I've been into, stopped because the DNS provider did not do their job in time or forgot it. And most likely you will do this migration in a weekend/overnight, why pay someone to do simple task when you can do it your self?

3. For MX change, this is how I would recommend it:

A. Set down TTL as short as 1 hour.
B. Get access to a second mailserver that you can use as a backup. This should naturally NOT be one of your own mail server, most likely your DNS provider also have some backup MX service.
Add this backup mailserver as a second MX to your domain with a lower priority. Test it!
C. Do the switch of the IP adresses. You will have some downtime of course, that's why you have the second backup mailserver.

So when you switch and have downtime, all incoming email will get routed to the second backup mailserver and stored there until the switch is complete. The backup mailserver would then periodically check if your own mailserver is up and running and if it is, it will relay all stored mail into your mailserver.  It is dependent of the configuration of the backup mailserver how often it will relay the stored messages into your own mailserver, but usually it check something in between 5-30 min.

Of course, incoming mail would be delayed during the switch, but you don't loose any mail, and that is most peoples priority during network changes.

4. As for the backup on the WAN side, it is costly to provide full redunancy. You can get some semi-redudancy for basic network services, like NAT (think of clients web surfing), but not for servers and other services. If you want a full scale solution, you need to setup BGP with both your ISP's. And that is not an easy task. The reason for BGP WAN reduancy, is that if you use the low cost solution, your external IP adresses change if your primary ISP line fails. And also you would have problems with reverse DNS, as the reverse records leads to IP adresses that are not working when your primary ISP line fails. That is why you need to implement BGP on your checkpoint box.

Talk to you new ISP, they usually know the drill.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now