FastConnect Security
Learn about using encryption with FastConnect for better network security.
Oracle Cloud Infrastructure FastConnect has two major methods to encrypt traffic between an on-premises data center and Oracle Cloud Infrastructure: IPSec over FastConnect and MACsec Encryption.
IPSec over FastConnect
IPSec over FastConnect lets you set up Site-to-Site VPN with secure IPSec tunnels on FastConnect virtual circuits, thereby providing added security to what is already a private connection. These IPSec tunnels protect network-to-network connections on Layer 3.
IPSec over FastConnect is available for all three connectivity models (partner, colocation with Oracle, and third-party provider) and supports the following capabilities:
- Several IPSec tunnels can exist over a single FastConnect virtual circuit.
- A mix of encrypted and unencrypted traffic can exist on the same virtual circuit, though you can require that all traffic is encrypted.
- IPSec tunnel endpoints can use public or private IP addresses, but if the addresses are public they're not reachable over the internet because the transport for this connectivity is a private connection and not on the internet.
- You can aggregate several IPSec tunnels between the same endpoints using ECMP.
Configuring IPSec over FastConnect
We recommend that you use BGP route-based IPSec connections for IPSec over FastConnect.
Configuring both FastConnect and Site-to-Site VPN to work as a single data connection requires setting up components in a specific order. Presuming you already have at least one VCN and DRG in a cloud tenancy, create services in the following order:
- Create a FastConnect virtual circuit, or select an existing private virtual circuit. This virtual circuit can use any of the three FastConnect connectivity models. No change is required to new or existing private virtual circuits to enable IPSec over FastConnect, but you can edit the virtual circuit to only allow traffic that uses IPSec over FastConnect. The DRG uses different route tables set up for VIRTUAL_CIRCUIT attachments and IPSEC_TUNNEL attachments, because these attachments can't share a DRG route table.
- Create a new customer premises equipment (CPE) object. This object is a virtual representation of the physical edge device of an on-premises network. The CPE object must have IPSec over FastConnect enabled at creation time, this can't be added later. After creating the CPE object, configure the physical edge device to match the CPE settings as normal for Site-to-Site VPN. The IP address used as the CPE IKE identifier can be either private or public. Of course, you can still use an existing CPE object for regular traffic that traverses the internet.
- Create a Site-to-Site VPN IPSec connection, selecting the new CPE you created. BGP routing is preferred for connections that use IPSec over FastConnect, and you must specify the FastConnect virtual circuit you plan to use.
Loopback Attachments
IPSec over FastConnect requires an upgraded DRG, which can have attachments with the following types:
- VCN
- VIRTUAL_CIRCUIT
- IPSEC_TUNNEL
- REMOTE_PEERING_CONNECTION
- LOOPBACK
A loopback attachment allows encrypted traffic to flow between a virtual circuit attachment and an IPSec tunnel attachment, by providing the Oracle side of the tunnel's private IP address to the DRG. Without the loopback attachment, traffic directly between a virtual circuit attachment and an IPSec tunnel attachment is not allowed. When traffic loops back through the IPSec tunnel attachment, it is decrypted and then sent to the DRG. Only virtual circuit attachments and IPSec tunnel attachments can route to a loopback attachment. All routing to or from a loopback attachment is managed by Oracle and can't be managed by your tenancy admins.
IPSec over FastConnect involves both a virtual circuit and an IPSec tunnel, and those connections must end on a DRG attachment with the corresponding type. As shown in the following simplified diagram for inbound traffic, with IPSec over FastConnect the IPSec tunnel originates from the CPE (Callout 1). The virtual circuit originates on an on-premises edge router (Callout 2), and ends on a VIRTUAL_CIRCUIT attachment (Callout 3). Then IPSec tunnel traffic passes to a LOOPBACK attachment (Callout 4) and ends on an IPSEC_TUNNEL attachment (Callout 5). Unencrypted traffic then passes through a VCN attachment (Callout 6) and out to the final destination IP address in the VCN. The traffic could alternatively route to a REMOTE_PEERING_CONNECTION attachment bound to another DRG in the same region or another region, but that isn't shown in the diagram.
| Callout | Function |
|---|---|
| 1 | CPE device. Terminates the IPSec connection. |
| 2 | Edge router. Terminates the virtual circuit. Note: Callout 1 and 2 can potentially be the same physical device. |
| 3 | VIRTUAL_CIRCUIT attachment. Terminates the virtual circuit. |
| 4 | LOOPBACK attachment. Forwards IPSec traffic to IPSEC_TUNNEL attachment. This is also the VPN endpoint IP. |
| 5 | IPSEC_TUNNEL attachment. Terminates the IPSec connection. |
| 6 | VCN attachment |
When using IPSec over FastConnect, the IPSec tunnel attachment (Callout 5) and the virtual circuit attachment (Callout 3) must use different DRG route tables and import route distributions.
TransportOnly Mode: Only Allowing Encrypted Traffic on a Virtual Circuit
IPSec over FastConnect lets a FastConnect virtual circuit act as a transport medium for encrypted traffic on a private IPSec tunnel, allowing connectivity from an on-premises network into the VCN for both secured and unsecured traffic.
If you want a strict security posture that only allows encrypted traffic over your
virtual circuits, set the transportOnly mode flag on your virtual
circuit and the virtual circuit's DRG attachment (in the Console, set the IPSec over
FastConnect traffic only option, either when you create the virtual circuit or
later on).
Before you try to set the transportOnly mode flag:
- Remove all static rules from the "Autogenerated Drg Route Table for RPC, VC, and IPSec attachments" route table, or whichever route table is currently the default for virtual circuit attachments. By default, the associated import route distribution for the autogenerated route table is the"Autogenerated Import Route Distribution for VCN Routes."
- Remove all route distribution statements from the "Autogenerated Import Route Distribution for VCN Routes" (or the manually created import route distribution associated with a custom route table for virtual circuits) that have a "Match attachment type Virtual Circuit" or "Match ALL" setting.
If you attempt to enable transportOnly mode on a DRG that doesn't meet
these requirements, you should get a detailed error message describing what settings
need to be adjusted. After you make the required changes to your DRG, you will be able
to set the virtual circuit and its attachment to transportOnly mode.
After you set the transportOnly mode flag, Oracle enforces the
following behaviors on your DRG's route tables and import route distributions:
- The virtual circuit attachment's route table only allows a single route towards each of its associated loopback attachments and no other routes.
- The virtual circuit attachment's route table can't have any static routes.
- The import route distribution of the route table associated with the virtual circuit attachment can only import routes from the loopback DRG attachments.
- None of the attachments in the DRG can import routes from the virtual circuit attachment except the loopback attachment. This means that no import route distribution for any other attachment can have a generic "Match ALL" or "Match attachment type - Virtual Circuit" setting.
Any further changes to the import route distribution or changes to static route rules on this DRG will be validated to enforce the necessary routing behaviors.
MACsec Encryption
You can configure FastConnect to use MACsec (IEEE standard 802.1AE) to protect network-to-network connections on Layer 2. To enable MACsec, select an advanced encryption standard (AES) encryption algorithm. The two connected networks exchange and verify security keys, and then establish a secure bidirectional link. The Oracle Cloud Infrastructure Vault service securely stores the actual encryption keys.
Using MACsec has the following requirements:
- The customer premises equipment (CPE) device must also support MACsec.
- The FastConnect selected port speed for single cross-connects or cross-connect groups must be 10 Gbps or greater.
- Not all existing cross-connect or cross-connect group can support MACsec. To upgrade an existing cross-connect or cross-connect group, the details page for the cross-connect or cross-connect group has a MACsec Encryption field with settings for either Capable or Incapable. The connection must be MACsec capable. If the cross-connect or cross-connect group is Incapable of using MACsec, you need to reprovision before configuring MACsec.
- Not all third-party providers can support MACsec on the type of circuit they provide. Check with the provider to verify that the type of connectivity you buy supports MACsec.
FastConnect with MACsec integrates with the Vault service. Here's an overview of the steps to fully configure FastConnect with MACsec.
- Create a Vault.
- Create a master encryption key in Vault.
- Create two secrets to represent the Connectivity Association Key (CAK) and Connectivity association Key Name (CKN) in Vault. The CAK and CKN must be hexadecimal strings with a length of 32 to 64 characters.
- Configure MACsec in a Third-party provider or colocation cross-connect using the CKN and CAK secrets created for the FastConnect circuit.
- Give the on-premises network administrator the original CAK and CKN keys to use when configuring the customer premises equipment (CPE) device.
- Activate the cross-connects for the third-party provider or colocation virtual circuits.
If you decide to add MACsec encryption to an existing FastConnect cross-connect, remember that changing the encryption settings requires restarting the BGP session, which briefly suspends BGP traffic.
MACsec Parameters
When configuring MACsec on a CPE, see the table for various required parameters.
| Parameter | Possible Values | Description |
|---|---|---|
| CAK | 32 to 64 hexadecimal characters | Minimum of 32 hexadecimal characters (0 through 9, A through F). |
| Cipher Suites |
aes128-gcm-xpn aes256-gcm-xpn |
Configure the CPE to match the cipher suite configured in OCI. |
| CKN | 32 to 64 hexadecimal characters | Minimum of 32 hexadecimal characters (0 through 9, A through F). |
| Confidentiality Offset | 0 | The OCI side is always 0, meaning the whole frame is encrypted. If required as part of the CPE configuration, match the OCI side. |
| Interface |
Single physical interface link aggregation group (LAG) |
MACsec for FastConnect supports configuration of MACsec on either a single FastConnect connection or a LAG. Match this configuration option on the CPE. |
| Key-server | 1 or larger | Use any value larger than 0 on the CPE. The OCI FastConnect edge device always uses 0. |
| MKA Include SCI | include SCI | Configure the CPE to include an SCI (Secure Channel Identifier) tag. Configure the "Include SCI" tag on the OCI side. |
| MKA Policy Option |
must-secure |
This requires that all traffic sent on the MACsec-enabled network segment is secure (the Fail Close option in the Console). Match this configuration option on the CPE. The should-secure option (the Fail Open option in the Console) is available but isn't recommended by Oracle. |
| SAK Rekey time | 3600 seconds (1 hour) | CPE configuration must match the OCI SAK rekey time of 1 hour. |
MACsec Hitless Key Rollover
When you're ready to rotate the keys, MACsec for FastConnect supports hitless key rollover. To ensure no loss in communication when rotating keys, always update both the CKN and CAK at the same time. Change the CKN and CAK pair on the OCI side of the FastConnect link first, and then update the CPE.
Perform the following tasks in the order described. Doing these steps out of order might result in a temporary disruption in communication.
- Open the navigation menu , select Identity & Security, and then select Vault.
- Select a compartment that you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
- Select the name of the Vault that includes the CKN and CAK secrets.
- Under Resources, select Secrets.
- Select the name of the secret that represents the CKN.
- Select Create Secret Version.
- Under Secret Contents, enter the new value for the CKN.
- Select Create Secret Version.
Repeat these steps to also change the value of the CAK secret.
When performing hitless key rollover, always update both the CKN and CAK.
- Open the navigation menu and select Networking. Under Customer connectivity, select FastConnect.
- Select the name of the FastConnect that uses the Vault secrets changed in Task 1. You see the cross-connect representing this FastConnect.
- Select Edit.
- Under Connectivity Association Key Name (CKN) select Use current version in Vault: <number> where <number> matches the latest secret version of the CKN secret in the Vault.
- Under Connectivity Association Key (CAK) select Use current version in Vault: <number> where <number> matches the latest secret version of the CAK secret in the Vault.
- After both CKN and CAK versions update, select Save Changes.
- A new pop-up appears to confirm changes. Select Confirm.
After the cross-connect updates to use the new CKN and CAK values, you have a 1 hour rekey period to update the CKN and CAK on the CPE before the session drops.
After the cross-connect updates to use the new CKN and CAK values, you have a 1 hour rekey period to update the CKN and CAK on the CPE before the session drops. See the appropriate documentation for the device.