Moving a sub interface (internet) to a separate physical interface

[Faaa]

Hi

I have two firewalls on r81.20 in an primary/secondary setup with the active firewall connected to core switch 1 and standby connected to core switch 2. 

Each interface is a trunk link which is basically carrying all our sub interfaces and I basically want to separate the eth0.0-31 internet sub interface out so it's on eth3. I want all internet traffic on eth3. 

I would appreciate it if someone could tell me the best way to do this whilst having as little downtime as possible. 

Do i remove the ip address on the secondary fw first and then move it onto eth3 and then do the same on the primary fw? I'm not sure if I would have to make the secondary fw the active fw to allow me to move the ip address on the primary firewall.  Also at what point do i move the vip?

I have site to site vpns connecting to the vip on eth 0.0-31 so would like to do it with minimal downtime as possible, Appreciate all your help. 

[israelfds95]

This can be a delicate operation, so I strongly recommend performing it during a maintenance window where downtime is acceptable, and preferably being physically on-site (if you have LOM access, even better).

I would also recommend taking a System Backup of both firewalls and documenting the installed Jumbo Hotfix (JH) and other hotfix versions. This can be useful as a last resort if you need to restore the previous configuration. Also, make sure to back up any important configuration files, such as fwkern.conf, trac_client_1.ttm, ipassignment.conf, and fw_fast_accel_export_configuration.conf, in case you need to perform a clean installation of the gateways and rebuild the cluster from scratch.

Preparation and planning (days before the migration):

I strongly recommend planning everything in advance and preparing all the necessary configuration scripts several days before the maintenance window.

I would collect the show configuration output from both cluster members and carefully map all configuration dependencies related to the current interface, such as static routes, Proxy ARP, or even dynamic routing.

Based on this analysis, I would prepare and review all the commands required to remove the existing configurations, recreate the VLAN on the new physical interface, and apply the necessary adjustments. This way, during the maintenance window, you will already have a well-defined execution plan, minimizing the risk of errors and unnecessary downtime.

Migration approach:

My approach would be to remove the VLAN being migrated and its associated configurations from both the Active and Standby members, then recreate it on the new physical interface and apply all necessary configuration adjustments, including the physical IP addresses.

On the switch side, make sure the port configurations are also updated to match the new network topology.

One important point: Make sure the changes are properly coordinated on both cluster members. Otherwise, you may run into ClusterXL issues due to interface or topology mismatches.

Also, when retrieving the updated topology in SmartConsole, inconsistent interface configurations between cluster members may result in errors during Get Topology, preventing you from saving the changes or installing the policy.

Make sure the Cluster VIP and interface topology are properly updated in SmartConsole as part of the migration plan.

Finally, validate the updated topology, ClusterXL status, routing, Internet connectivity, and Link Selection for Site-to-Site VPN tunnels before considering the migration complete.

Hope this helps!

[Faaa]

Thanks for replying, i really appreciate it. 

When you say remove the old vlan from both the firewalls, would this be carried out first then followed by adding the same ip back on the physical int eth3 to the secondary firewall first and then the primary firewall? 

so my proposed steps are:

remove vip from smartconsole
remove vlan interface on secondary fw via Gaia
remove vlan interface on primary fw via Gaia
Add ip back on physical interface eth3 on secondary fw via Gaia
Add ip back on physical interface eth3 on prmiary fw via gaia
Add vip interface back via smartconsole

Thanks again

[israelfds95 · Accepted solution]

Hi,

 I would adjust the sequence a little.

My suggested steps would be:

1. Collect the show configuration output from both cluster members and carefully review all configuration dependencies related to the current interface, such as static routes, Proxy ARP, VLANs, dynamic routing, and other related settings.

2. Prepare and review the Clish scripts in advance, including all commands required to delete the existing configurations and recreate them with the necessary adjustments for the new interface. Also, prepare rollback scripts.

3. Remove the old VLAN interface and its configuration dependencies from the Secondary firewall via clish 

4. Remove the old VLAN interface and its configuration dependencies from the Primary firewall via Clish

5. Configure the new physical interface eth3 with the corresponding IP address on the Secondary firewall via clish

6. Configure the new physical interface eth3 with the corresponding IP address on the Primary firewall via clish.

7. Make sure the switch port configurations, static routes, Proxy ARP, and any other dependencies are properly adjusted.

8. Once both members are configured, go to SmartConsole and perform a new Get Topology.

9. Update the Cluster VIP to the new interface and review the Link Selection configuration for your Site-to-Site VPNs.

10. Install the security policy.

11. Validate ClusterXL status, routing, Internet connectivity, and Site-to-Site VPN tunnels.

[Faaa]

Thanks again for getting back.

At what point should i deal with the existing vip on eth 0.0-31 interface?  Should i remove this first via smart console? I'm just wary that once i remove the vip and then push policy everything is going to be down for quite a while after this whilst i configure eth3 with the same interfaces and then add the vip back to eth3. 
Also my proxy arp commands are referencing the ip address of my eth0.0-31 for th active primary firewall. I don't know if/how this would cause an issue.

Thanks

[israelfds95]

You should update the VIP through SmartConsole, under Gateways & Servers, but only after you have properly configured the network settings in Gaia, either through Clish CLI or the WebUI.

Keep in mind that everything starts with configuring the firewall in Gaia. Once SIC communication with the SMS has been established through SmartConsole, navigate to Gateways & Servers, edit the cluster object whose network configuration you modified, go to Network Management, and click Get Topology.

Since this is a significant network change affecting both cluster members, I strongly recommend running Get Topology rather than simply editing the interfaces manually.

At this point, you should manually configure the VIP for the new interface. Remember that VIP configuration is managed through SmartConsole, and the changes will only take effect after you update the configuration and perform a new Install Policy.

Please follow the steps I provided earlier.

Since you still have some questions about this procedure, I also strongly recommend building a lab before making any changes in production. You can use EVE-NG or a similar platform to replicate your current environment and simulate the migration. This will help you clearly understand the entire process.

I also encourage you to study the CCSA and CCSE training materials and look for technical tutorials on YouTube. It's very important to strengthen your understanding of these fundamental Check Point concepts before performing such changes in a production environment.

As mentioned earlier, I've already provided the recommended sequence of steps.

Finally, if you have support through a Check Point partner, I recommend opening a support case and requesting technical assistance and guidance throughout the procedure.

[Faaa]

Thanks for all your help. 

[Bob_Zimmerman]

You can do this with no downtime at all. I wrote my team's process for moving traffic from one interface to another a while ago. It still works beautifully.

Separately, I highly recommend using a bond instead of using interfaces directly. This makes it a lot easier to replace hardware (e.g, to move from 1g to 2.5g or 10g) later.

[JozkoMrkvicka]

He wants to move trunk VLAN 31 from physical interface eth0 to access VLAN on eth3.

I am not sure your approach will work here, as we are working with 2 independent interfaces. You will not get modified cluster member in Standby state ready for failover, as it will have more required interfaces than the active node. It is also important if VLAN 31 is highest or lowest configured VLAN on the firewall due to CCP checks.

[Bob_Zimmerman]

It works fine. The entire point of the process is that the cluster doesn’t care which physical interfaces make up a given cluster interface. Untagged to tagged, tagged to untagged, one VLAN to a different VLAN, physical interface to bond are all fine. I've done all of those several times.

[Faaa]

Hi thanks for getting back

I thought any interface changes had to be done via clish or gaia? I can remember making a change to a vlan number on an interface on the smart console and i then couldnt see that change in clish or Gaia. 

[Bob_Zimmerman]

This sort of change always involves changes in both SmartConsole and clish. Check Point firewalls are just Linux servers running a weird application. The member configuration (setting up a bond, changing the member IPs, etc.) is done at the OS level. The cluster configuration (setting the cluster VIP, changing which member interfaces back a given cluster interface, etc.) is done at the application level, in SmartConsole.

You update the OS-level configuration on the first member (in a normal HA cluster, start with the standby), update the cluster configuration and push policy, fail over the cluster, update the OS-level configuration on the next member, update the cluster configuration and push policy again, potentially repeat the process for any additional members (it's rare to have more than two in a normal cluster), then you're done.

As you can see, it's not something a lot of people do very often. I recommend trying it a few times in a lab (remember, Check Point's OS runs just fine in VMs) to build up memory of where everything is. The cluster might not go to Active/Standby when you 'clusterXL_admin up' the first member, but as long as the members can talk to each other over the interface you're moving, there shouldn't be any outage when you force the second member down.

[Faaa]

Thanks for all your help. I'm mainly a cisco asa engineer and we only have a single checkpoint left so I haven't bothered brushing up on my skills as I should. We're moving to a Palo setup for all our sites.