Transit on-premises network traffic to Azure through OCI using the OCI-Azure Interconnect

In 2019, Oracle and Microsoft announced the partnership to enhance cloud interoperability by connecting Oracle Cloud Infrastructure (OCI) and Microsoft Azure clouds through a private, secure, low-latency, and high-throughput network. The OCI-Azure interconnect enables enterprises with on-premises, mission-critical applications that utilize both Oracle and Microsoft technologies to easily migrate to public clouds. This one-of-a-kind connected-cloud alliance built for our mutual customers and complementary cloud services opens the door to swift migration of on-premises applications. Customers can then use a broader range of tools, while integrating their implementations into a single unified enterprise cloud solution.

Our customers tell us that they want the option to choose different public clouds for different workloads, such as Azure for Microsoft-centric workloads and Oracle Cloud for Oracle workloads. However, enterprises face certain technical challenges to connect between their on-premises data center to OCI and transit the network to Azure privately and securely. This blog addresses such technical challenges and shows you how to overcome them using the OCI-Azure interconnect.

Solution summary

This solution architecture describes the various security components deployed on OCI and Azure cloud with the steps to facilitate the transit of network traffic from on-premises data center to Azure cloud transit through OCI and the interconnections configured between Oracle cloud and Azure cloud. This solution doesn’t include the steps to configure the interconnection between Oracle cloud and Azure cloud. You can refer to Oracle blog or documentation to configure interconnection between Oracle cloud and Azure cloud.

The following architecture illustrates the network connectivity between an on-premises data center and OCI using either OCI FastConnect, an IPSec VPN, or both. It also shows other network connectivity that you can configure between OCI and Azure.

We can use a single OCI dynamic routing gateway (DRG) on OCI and attach multiple virtual cloud networks (VCNs) to it. One FastConnect circuit connects to your on-premises data center and another FastConnect circuit connects to Azure cloud. These FastConnect circuits can then be attached to the single DRG. We also deploy a pair of FortiGate Next Generation firewalls and configure them to create IPSec tunnel between on-premises VPN devices and the network on Azure. Network traffic can then transit from on-premises to Azure vNet through the IPSec tunnel privately.

The following diagram illustrates the architecture of the solution.

Consider the following key features for this solution architecture:

• Availability: Dynamic routing protocol, such as border gateway protocol (BGP), is configured to achieve high availability.

• Scalability: Network traffic is distributed across the virtual instances to achieve scalability.

• Performance: Performance can be achieved by selecting the appropriate size of compute and network for the virtual instances.

We used a FortiGate firewall in this solution, but you can use other firewall options as needed.

Configure the private tunnel between on-premises to Azure through OCI

The scope of this article is confined to the steps for creating an OCI landing zone and FortiGate Next Generation firewall configuration both in OCI and Azure. Refer to this blog for the end-to-end interconnect configuration between Oracle Cloud Infrastructure and Microsoft Azure.

Create a VCN on OCI or use an existing VCN

1. Create a VCN on OCI or use your existing VCN. Create one public subnet and one private subnet on the VCN.

2. Create a VCN attachment in the existing DRG being used for OCI-Azure Interconnect for each OCI VCN.

3. Create the required subnets, route tables, and security list in the newly created VCN. Attach the route table and security list to the subnet.

The following screenshots show the attachment of VCNs with a DRG in OCI.

Deploy FortiGate instance on OCI using the Marketplace image

1. Log in to the OCI Console. Create an instance.

2. Select the partner image and choose FortiGate Next Generation firewall. Choose an appropriate size of the virtual machine (VM) shape, depending on network throughput requirement.

3. Create primary and secondary FortiGate Next Generation firewall instances. For detailed instructions, refer to the Fortinet installation guide and this article.

4. Configure the Fortinet firewall on OCI.

5. Create three route-based IPSec VPN tunnels using both the primary and secondary Fortinet firewalls. One tunnel connects to on-premises and two tunnels connect to Azure Fortinet firewall. In this example, we used on-premises CPEs configured in a high-availability cluster. We recommend that you create two IPSec tunnels for the connection to on-premises if the CPEs aren’t configured as a cluster and are not highly available.

The following screenshot shows the IPSec tunnels created on primary Fortinet firewall on OCI:

In this example, the IPSec tunnel created with the public IP address 20.106.177.101 is connected to an on-premises CPE, and the other two IPSec tunnels created with private IP address are connected to Azure Fortinet firewall. To set up hub and spoke IPSec tunnels on OCI, see the Fortinet configuration guide.

The following screenshot shows the IPSec tunnels created on secondary Fortinet firewall on OCI:

6. Assign IP addresses to the tunnel interfaces of both the primary and secondary Fortinet firewalls on OCI, as shown. The following screenshot shows the assigned IP addresses for the tunnel interface of the Fortinet firewalls on OCI:

7. Configure BGP and assign the local autonomous system (AS) number, router ID, and remote AS numbers for neighbors (on-premises and Azure). The following screenshot shows the BGP configuration and the AS numbers assigned for primary Fortinet firewall on OCI:

The following screenshot shows the BGP configuration and the AS numbers assigned for secondary Fortinet firewall on OCI:

Deploy and configure the Fortinet firewall on Azure

Connect to the Azure portal and deploy two Fortinet firewalls (primary and secondary) on Azure. You can choose to use the Azure Marketplace image for the Fortinet firewall. Choose the right size of the Compute shape to deploy Fortinet firewall on Azure. Follow the steps for the OCI Fortinet firewall configuration and then perform the following steps.

1. Create two route-based IPSec VPN tunnels on each of the primary and secondary Fortinet firewall running on Azure. Connect both the IPSec tunnels with OCI Fortinet firewalls.

2. Assign tunnel IP addresses both on primary and secondary Fortinet firewalls running on Azure.

3. Configure BGP and assign local AS number, router ID and remote AS numbers on both primary and secondary Fortinet firewalls running on Azure.

Configure a conditional path on Azure Fortinet Firewall

Configure a conditional AS path prepend and local preference metrics to redistribute network traffic within Azure Fortinet firewalls. The following architecture diagram illustrates the conditional path configured on Azure Fortinet firewalls to forward the network traffic.

With these metrics configured, the traffic gets distributed across FortiGate firewalls.

Network C (172.17.0.0/24) takes the following path to reach network A (10.100.1.0/24):

• Primary route: FW3 (AS 65303), FW1 (AS 65301), on-premises (AS 65515)

• Secondary route: FW3 (AS 65304), FW2 (AS 65302), on-premises (AS 65515)

Network D (172.17.2.0/24) takes the following path to reach network A (10.100.1.0):

• Primary route: FW4 (AS 65304), FW2 (AS 65302), on-premises (AS 65515)

• Secondary route: FW4 (AS 65304), FW1 (AS 65301), on-premises (AS 65515)

BGP metrics configuration details

Azure primary firewall (FW3)

In this example, the neighbor Fortinet firewalls deployed on OCI are 2.2.2.1 (FW1) and 3.3.3.1 (FW2).

Neighbor 2.2.2.1 (FW1) has a filter to only accept network A (10.100.0.0/24) as incoming, where the local preference is set to 200. So, 2.2.2.1 is the preferred neighbor to reach network A.

Log in to firewall and run the following commands:

# config router prefix-list
    edit "Onprem_NW_10.100.0.0”
        # config rule
            edit 1
                set prefix 10.100.0.0 255.255.0.0
                unset ge 
                unset le 
            next 
        end 
    next 
end

# config router route-map 
    edit "Onprem_NW_10.100.0.0” 
        # config rule 
            edit 1 
                set match-ip-address "Onprem_NW_10.100.0.0"

 

set set-local-preference 200 next end next end

# config neighbor 
        edit "2.2.2.1" 
            set soft-reconfiguration enable 
            set remote-as 65301 
            set route-map-out "Onprem_NW_10.100.0.0" 
        next 
    end

For neighbor 3.3.3.1 (FW2), set a conditional AS path prepend where the networks are advertised only when routes are not learned from neighbor 2.2.2.1. This configuration avoids the loop in BGP.

Log in to the firewall and run the following commands:

config router prefix-list 
    edit "Net_172.17.0.0_24” 
        config rule 
            edit 1 
                set prefix 172.17.0.0 255.255.255.0 
                unset ge 
                unset le 
            next 
    edit "Net_172.17.2.0_24" 
        config rule 
            edit 1 
                set prefix 172.17.2.0 255.255.255.0 
                unset ge 
                unset le 
            next 
        end 
    next 
end

config router aspath-list 
    edit "MATCH-65301" 
        config rule 
            edit 1 
                set action permit 
                set regexp "^65301_"    
            next 
        end 
    next 
end

Regexp “^65301_” means it was learned from AS 65301.

config router route-map 
    edit “Secondary_Link"    
        config rule 
            edit 1 
                set match-as-path "MATCH-65301" 
                set match-ip-address "Net_10.100.0.0_16"   
            next 
        end 
    next 
    edit "Azure_Nw_172.17.0.0" 
        config rule 
            edit 1 
                set match-ip-address "Net_172.17.0.0_24” 
            next

 

edit 2 set match-ip-address "Net_172.17.2.0_24"

 

set set-aspath “65303 65303” next end next end

# config neighbor 
        edit "3.3.3.1" 
            set soft-reconfiguration enable 
            set remote-as 65302 
            config conditional-advertise

                 Edit “Azure_Nw_172.17.0.0”

                          Set condition-routemap “Secondary_Link”

                           Set condition-type non-exist 
        next 
    end

“Secondary_Link” and “Azure_Nw_172.17.0.0” route maps are called in the conditional AS_Path Prepend configuration. These routes are only used when the primary Azure firewall (FW3) stops the learning path of network A from FW1. It then advertises to FW2.

The following screenshot shows an example of a BGP neighbor configuration:

The following example shows the route map, prefix list, and AS path configuration:

Azure secondary firewall (FW4)

In this example, neighbor Fortinet firewalls deployed on OCI are 6.6.6.1 (FW1) and 5.5.5.1 (FW2).

For neighbor 6.6.6.1 (FW1), configure to set a conditional AS Path prepend, where the networks are advertised only when routes are not learned from neighbor 5.5.5.1. This configuration avoids the loop in BGP.

Log in to the firewall and run the following commands:

>config router prefix-list 
    edit "Net_172.17.0.0_24” 
        config rule 
            edit 1 
                set prefix 172.17.0.0 255.255.255.0 
                unset ge 
                unset le 
            next 
    edit "Net_172.17.2.0_24" 
        config rule 
            edit 1 
                set prefix 172.17.2.0 255.255.255.0 
                unset ge 
                unset le 
            next 
        end 
    next 
end

config router aspath-list 
    edit "MATCH-65302" 
        config rule 
            edit 1 
                set action permit 
                set regexp "^65302_"    
            next 
        end 
    next 
end

Regexp “^65302_” means learned from AS 65302.

config router route-map 
    edit “Secondary_Link"    
        config rule 
            edit 1 
                set match-as-path "MATCH-65302" 
                set match-ip-address "Net_10.100.0.0_16"   
            next 
        end 
    next 
    edit "Azure_Nw_172.17.0.0" 
        config rule 
            edit 1 
                set match-ip-address "Net_172.17.0.0_24”

                set set-aspath “65304 65304” 
            next

            edit 2 
                set match-ip-address "Net_172.17.2.0_24"

 

next end next end

# config neighbor 
        edit "6.6.6.1" 
            set soft-reconfiguration enable 
            set remote-as 65301 
            config conditional-advertise

                  Edit “Azure_Nw_172.17.0.0”

                           Set condition-routemap “Secondary_Link”

                           Set condition-type non-exist 
        next 
    end

“Secondary_Link” and “Azure_Nw_172.17.0.0” route maps are called in the conditional AS_Path Prepend configured earlier. Only when the Azure Secondary firewall (FW4) stops learning the path of network A from the OCI secondary firewall (FW2) does it advertise to OCI Primary firewall (FW1).

Neighbor 5.5.5.1 (FW2) has a filter to only accept network A (10.100.0.0/24) on-premises network as incoming, where the local preference is set to 200. So, 5.5.5.1 is the preferred neighbor to reach network A.

Log in to the firewall and run the following commands:

># config router prefix-list 
    edit "Onprem_NW_10.100.0.0” 
        # config rule 
            edit 1 
                set prefix 10.100.0.0 255.255.0.0 
                unset ge 
                unset le 
            next 
        end 
    next 
end

># config router route-map 
    edit "Onprem_NW_10.100.0.0” 
        # config rule 
            edit 1 
                set match-ip-address "Onprem_NW_10.100.0.0"

                set set-local-preference 200 
            next 
        end 
    next 
end

># config neighbor 
        edit "5.5.5.1" 
            set soft-reconfiguration enable 
            set remote-as 65302 
            set route-map-out "Onprem_NW_10.100.0.0" 
        next 
    end

The following screenshot is an example of a BGP neighbor configuration:

The following screenshot shows an example of the route map, prefix list, and AS path configuration:

Conclusion

This solution illustrates how you can move the network traffic privately and securely from on-premises data centers to Azure through Oracle Cloud Infrastructure by using the interconnect between OCI and Azure. The setup takes advantage of an OCI DRG advanced feature that allows multiple VCNs to be associated to a single DRG and be routed to peered Azure vNETS on the other end. This solution also reduces the management overhead by simplifying network connectivity between Oracle Cloud Infrastructure and Azure, especially where you need to connect different networks to form a multicloud solution.

Want to continue to explore? To learn more about this strategic offering from Oracle and Microsoft, check out the following resources:

• Oracle Cloud expands with launch of San Jose region

• Oracle and Microsoft accelerate enterprise cloud adoption

• The Oracle and Microsoft cloud partnership Accenture report

• Learn about disaster recovery in Oracle Cloud Infrastructure

• Meet cloud’s new power couple: Oracle Cloud Infrastructure and Microsoft Azure

• Oracle Cloud Infrastructure and Azure interconnect solution playbook

• Oracle Cloud Infrastructure blog