Approaches to replacing any marketplace firewall with native OCI firewall

There are several approaches to migrating a firewall, including:

1. Phased migration: This approach involves gradually migrating the firewall rules to OCI firewall in stages, testing each stage before moving on to the next. This approach is less disruptive to the network and allows for more testing and validation of the new firewall rules.
2. Big-Bang migration: This approach involves quickly migrating all firewall rules to OCI firewall in one go. This approach could be more disruptive to the network and requires more planning and testing in advance to ensure a smooth transition.
3. Hybrid migration: This approach involves a combination of phased and cutover migration, depending on the specific requirements of the network and the complexity of the firewall rules.

Regardless of the migration approach chosen, it is important to have a comprehensive plan in place and to test the new firewall rules thoroughly before deploying them to the production network.

Phased migration could be a long process, whereas Big-Bang could be too risky. A hybrid approach gives you best of both worlds.

Let’s break down this approach in phases:

PLANNING: This phase involves creating a detailed plan for the migration, including identifying the scope of the migration, the timeline, and the resources required. It also includes identifying any potential risks or challenges that may arise during the migration.

DISCOVERY: This phase involves identifying the current firewall configuration, including the firewall rules, access control lists, and security policies. This information is used to create a baseline for the new firewall configuration.

TESTING: This phase involves testing the new firewall configuration in a lab or staging environment to ensure that it is working correctly and that it meets the requirements of the network.

PILOT: This phase involves deploying the new firewall configuration to a small section of the network to test it in a production-like environment. Any issues that arise during the pilot phase can be addressed before the migration is completed.

DEPLOYMENT: This phase involves deploying the new firewall configuration to the entire network. This is typically done in stages, starting with non-critical areas of the network and working towards critical areas.

MONITOR: This phase involves monitoring the new firewall configuration to ensure that it is working correctly and that it meets the requirements of the network. This phase also includes maintaining the firewall, including applying software updates and security patches.

These steps mentioned above are just a general guide and the actual steps will depend on the specifics of the migration project.

An Example Migration:

Let me run you through a recent firewall migration project that I handled for a customer.

Requirement : Checkpoint firewall deployed in OCI had to be migrated to OCI Network Firewall.

(P)lanning Phase:

In this phase — we identified current firewall & network architecture, traffic flows that are being inspected, Changes required for the migration, potential challenges and a risk mitigation plan.

1. Firewall Architecture Summary:

• It was an Active-Standby cluster, that was deployed with 2x VNICs in Public & Private subnet each.
• There were up to 8 additional Private IPs (associated with reserved public IP addresses), added to the VNIC in the public subnet. These public IPs had a static NAT configured to their internal applications.
• A Checkpoint Management Server was deployed in the private subnet. The firewall inspected traffic in all four directions (North-South & East-West).
• Firewall NAT, Security Policy, IPS/Threat prevention scanning blades were used.

Image Courtesy : Checkpoint Cloudguard R80.20 documentation

2. Network Architecture summary:

• Hub & Spoke topology, with firewalls deployed in the Hub VCN.
• 4 spoke VCNs, segregated as Prod, Pre-Prod, Management, Sandbox.
• On-prem connections over IPsec VPN, Remote OCI regions connecting with RPC.
• Inter-VCN, cross-region, Internet bound, incoming access from the Internet all being inspected by a single firewall cluster.
• All Spokes connected to Hub VCN over LPG (Local Peering Gateway).

Image Courtesy : OCI — Checkpoint Cloudgard

3. Target Architecture Design summary:

There are multiple options for deploying OCI firewall. Refer to this link for more info.

Two most common deployment models are: 1) Distributed firewall model. 2) Transit firewall model.

• Distributed model means you deploy OCI firewall in every VCN. In Transit Firewall mode, firewalls deployed in Hub VCN can be leveraged to inspect traffic of all spoke VCNs. Typically, the customer’s “Security & compliance, Cost, Ease of Management” drives these design decisions.

• Based on further discussions with the customer, we decided to move ahead with the above topology.
• The Checkpoint Cluster will be replaced by OCI Firewall services.

Advantages:

• Scaling, version management, availability, patching of firewalls are Oracle’s responsibility. Refer to the SLA for more details.
• Configuration & access-fine tuning will be managed by customers.

4. Challenges & Risk Mitigation plans:

• OCI Firewall is lean in its function, it will not work as NAT, VPN, Router, or integrate with other user-identity solutions. This checkpoint in discussion was doing NAT, Access-Control, and Threat-Prevention.
• So NAT configuration were replaced with Public LBaaS (Load Balancer As a Service). The public IP of LBaaS will receive traffic, and route via the firewall, to the backends (Destination Servers).
• Change of Public IP address means change of DNS records. Fortunately, all critical applications were behind OCI Edge WAF. New IP address had to be replaced only in the WAF-Origin configurations, which made it simple!
• For applications where change of Public IP-Address was not a choice, scheduled downtime was required to remove IP address from Checkpoint. Then reconfigure it on LBaaS.
• Similarly, a few vendors had whitelisted the public IP-address of the customer. So either vendors needed to whitelist an additional IP, that will be assigned to our NAT gateway, (or) migrate those applications (networks) at the last phase with a scheduled downtime.
• During the downtime, the public IP used by the networks for egress access were moved to OCI NAT gateway.

(D)iscovery Phase:

1. Gathered / Reviewed checkpoint access policies.

This could be a time-consuming step, so I wrote a Python script that uses JSON files generated by Checkpoint’s Web-Visualization tool and converts them to OCI Network Firewall-JSON files. I have explained the script and how to use it in another blog. You will find it in my other published stories here.

Once the rules are moved to OCI firewall, the customer had to rewrite/modify their NAT rules as they were not valid anymore. Similarly, enabled “Intrusion detection” in rules that needed IPS scanning. Enabled logging for the firewall so the Intrusion actions get logged first. It’s always recommended to route the traffic to the firewall first, and review the intrusion logs before switching to “Intrusion Prevention” mode.

2. Gathered the Workload details, point of contact of these workloads (example-Application team, DB Team, Customer Network/Security teams) as we had to coordinate with them during every phase of migration.

3. Prioritized the workloads/Networks, from Low Risk to Critical. Low-risk networks (Management & Non-Prod) were moved behind the new firewall first, during Testing & Pilot phases. Prioritization was validated with the customer.

4. Listed dependencies/prerequisites-customer agreed to track & close them. (for example: Customer had to co-ordinate with their vendors for whitelisting our new public IP used by NAT gateways)

By the end of these Plan & Discovery phase, we must at least have Current & Target Architecture diagrams. These were used to validate network flows, required route entries, and other security list modification/creation requirements.

(T)esting Phase:

Customer wanted to see a PoC (Proof Of Concept) for the firewall migration. So we set up a test-environment similar to that of production (in terms of networking at least!) and created network firewall, replicated policies of production.

Moved test workloads and tested inter-VCN, ingress, egress internet access. Captured the test cases & results and compared the network performance with Checkpoint.

Once the customer was happy, we moved on to Pilot testing.

(P)ilot Phase:

This test environment was then used to set up some management workloads such as Bastion, and involved users to access their production services via this bastion service. Through this, we were able to determine the user experience and identified resolved potential production issues.

For example: The hub VCN had a DNS listener & forwarding services enabled, this was integrated with on-prem DNS & Other OCI Region DNS services. But this flow was overlooked/not brought up during the discovery phase. Through this pilot testing, we could discover & fix it (i.e) moved the service to management VCN.

These learnings were immensely helpful!

(D)eployment Phase:

Finally, the deployment was done in two phases:

Phase 1- Non-Prod & Mgmt VCNs were migrated.

Phase 2- Prod-VCN & Sandbox VCNs were migrated.

a.) Architecture Diagram — Before Migration:

Below is the current “Network-Architecture” diagram:

Current Architecture Diagram

• All Spoke network VCNs have a default route, pointing to their Local Peering Gateway (LPG). (Refer to the route tables, colored blue.)
• The Hub VCN has four route tables: one for the private subnet carrying the Checkpoint Trust VNIC, one for the public subnet with the Checkpoint’s Untrust-VNIC, and two transit route tables — one for the Dynamic Routing Gateway (DRG) and one for the LPG. (Refer to the route tables, colored red.)
• The DRG (Dynamic Routing Gateway) has two Route Tables (RTs). RT 1 is associated with the IPsec and Remote Peering Connections (RPC) attachments, and RT 2 is associated with the Hub VCN attachment. (Refer to the route tables, colored orange.)

b.) Target Architecture

At the end of Phase-1 the architecture changed as below:

Architecture-Diagram-Phase-1

Change Summary in Phase 1:

To simplify routing and make it future-proof, we migrated to the Dynamic Routing Gateway (DRG) version 2 from the Local Peering Gateway (LPG). The LPG will not support more than 10 connectivities per VCN.

We created a new Hub-VCN named it DMZ-VCN. This includes:

• Creating Firewall-Subnet (Private) & LBaaS-Subnet (Public), NAT Gateway, Internet Gateway, Service gateway.
• Creating required Security-List & Network Security Group (NSG) similar to the Hub-VCN.
• Deploying OCI-Network firewall in the Firewall subnet.

Creating the following DMZ-VCN Route tables:

• DMZ-VCN-Firewall-Subnet-RT — associated with the Private Subnet.
• DMZ-VCN-Public-Subnet-RT — associated with the Public Subnet.
• DMZ-VCN-Transit-RT — associated with the DRG Attachment as Transit route-table.
• DMZ-VCN-SGW-NATGW-transit-RT — associated with NAT Gateway and Service Gateway.

We created additional DRG route tables (RT3 & RT4) for the DMZ-VCN and Spoke Attachments. We changed the Spoke VCN route entries of Non-Prod-VCN & Mgmt-VCN as shown in the diagram above. We also changed/moved the public IP addresses NATed for Mgmt & Non-Prod workloads behind the Load Balancer as a Service (LBaaS) deployed in the public subnet.

Note: Compare network diagrams named “Current Architecture Diagram” & “Architecture-Diagram-Phase-1” for the changes in route entries.

With these above changes, both Management & Non-Prod VCN traffic were completely migrated behind the OCI firewall. Only the traffic towards Prod & Sandbox VCNs continued to flow through the Checkpoint firewall.

Similarly, the other two VCNs were also migrated behind the OCI firewall. The final architecture after migration looked like this.

Checkpoint and its Hub-VCN is completely removed from the network architecture in a phased manner.

(M)onitor Phase:

The Test->Deploy->Monitor process is cyclic for all phases. To monitor the migration effectively, we need to first prepare an activities list (or) Work Break Schedule. This will help us determine:

1. Pre-migration Activities: Tasks that will not have an impact and can be done without scheduled downtime. If there is a Change Board, follow due process.
2. Test-cases that were created by users, application owners- with desired outcomes. These will help us in determining if there are any issues with migration.
3. Migration Activities: Tasks that need scheduled downtime must be determined and communicated with Service Owners & Users. If there is a Change Board, follow due process.
4. Monitor firewall logs, for access or threat prevention logs if Intrusion Prevention is enabled. Review denied access logs to make sure there are no missing policies that could impact any services.
5. Create a RACI matrix that lists all pre-migration, during migration, pre & post-migration testing, monitor activities. I use the template below to track all of them.

If you managed to read through this long post patiently, I hope you found it really helpful. Good luck with your migrations!

Oracle Developers and Oracle OCI Free Tier

Join our Oracle Developers channel on Slack to discuss this and other topics!

Build, test, and deploy your applications on Oracle Cloud — for free! Get access to OCI Cloud Free Tier!