Add a management connection for third-party enforcers | Enforcers | Cisco Security Cloud Control: Mesh Policy Engine

Add a management connection so Mesh Policy Engine can reach third-party enforcers on private networks. Use the connection details to complete setup for policy deployment.

For third-party enforcers with management interfaces that do not have internet-reachable IP addresses, you need to establish a route-based site-to-site VPN connection using a Virtual Tunnel Interface (VTI) from the customer VPN peer to Cisco so that Mesh Policy Engine can access and update policies directly on your enforcers. You will have your own Cisco AWS VPC on a private network to terminate the connection on the Cisco end.

The VPN connection includes an active and a standby tunnel for redundancy; however, only one tunnel can be active. You can configure the other tunnel and manually bring it up in case of failure.

Figure 1. Management connection to Cisco

If you use active/standy failover for the customer VPN peers, you can add two VPN connections. Only one tunnel can be active, so be sure to enable only one tunnel for each connection.

For Cisco enforcers, a separate proxy connection is not required. If your third-party enforcer has a management interface with a routable IPv4 address, you don't need a VPN connection; Mesh Policy Engine can access your enforcer directly over the internet using the standard encrypted connection supported by your platform for management.

Procedure

From the Security Cloud Control Home page, click Mesh Policy Engine.
Choose Enforcers > Management connections > VPN connections.

Click Create VPN connection.

Enter the Proxy VPC network.

For your initial VPN connection, provide the private network for the VPC. Subsequent connections, if any, will use the same network.

Use a /24 network with the last octet a multiple of 16, between 0 and 208. This network can't overlap with your local enforcer network. If you have multiple Security Cloud Control organizations in the same region, make sure this network does not overlap with any other organization proxy VPC network. 10.0.0.0/16 is reserved. Cisco splits the subnet into three /28 subnets—one per AWS Availability Zone—for the proxy instances and load balancer, with headroom for future expansion.

If you want to change the VPC network, you need to delete all VPN connections and start over.
Enter a Name for this connection.
Enter the Customer outside IP address.

Identify the public outside IPv4 address of your VPN peer. This address is your VTI's tunnel source interface IP address.
Enter a Pre-shared key of your choice, between 8 to 64 characters of letters, digits, period (.), and underscore (_) only.

Cisco stores the pre-shared key in the AWS Secrets Manager.
Optional: In Cryptographic options, change the cryptographic settings for the connection.
See the following defaults:
- IKE versions—IKEv2
- Encryption—AES256, AES256-GCM-16
- Integrity—SHA2-256, SHA2-384, SHA2-512. If you use GCM encryption, they provide built-in integrity.
- DH groups—14, 15, 16, 19, 20, 21
- Startup action—Responder. Sets if the Cisco VPN peer responds to tunnel initiation or initiates the tunnel.
Click Submit.

The request appears in the Request status tab with status IN_PROGRESS.

Refresh the Request status page to track status.

First-time provisioning of the VPC takes approximately 30 minutes. You can leave the page and return later. When the request reaches COMPLETED, the new connection appears on the main table with two tunnel endpoints—the Cisco outside IP address—for each tunnel.

Note

The Cisco outside IP addresses are not known in advance. AWS allocates them dynamically when the VPN connection is created, so you must submit the connection in Mesh Policy Engine before you can add the customer peer connection.

Adding additional connections reuses the existing Proxy VPC and takes approximately 10 minutes per connection.

Table 1. Request status
State	Meaning
`SUBMITTED`	The request is accepted and waiting to start. You can reject it from this state.
`IN_PROGRESS`	The workflow is running.
`COMPLETED`	The workflow finished successfully. The connections table reflects the new state.
`FAILED`	The workflow encountered an error. Expand the row for the failure reason and request ID. Contact support with that ID.
`REJECTED`	You canceled the request before it started.

Configure the customer VPN peer to establish a tunnel to one of the Cisco outside IP addresses.

Every AWS Site-to-Site VPN connection has two tunnels that terminate in different Availability Zones. The two tunnels exist for AWS-side resilience: if one tunnel goes down because of AWS maintenance, an Availability Zone event, or an endpoint replacement, the other tunnel remains available.

On the customer side, configure only one tunnel as active at any time. Treat the second tunnel as a cold standby—fully configured on your peer, but kept administratively down until you need to fail over. The reason you can't have two active tunnels is Cisco's VPN uses static routing, not BGP. With static routing, the customer peer does not have a dynamic protocol to elect a single active path, which could cause asymmetric flows and traffic flapping.
1. View the completed connection on the VPN connections tab and pick one of the two Cisco outside IP addresses as the primary. Either tunnel is acceptable; the two endpoints are equivalent.
2. Configure the primary tunnel on the customer peer.
  Use the following settings:
  - Tunnel source interface—The interface that has the public outside IP address you specified.
  - Inside IP address—Customer inside IP address. The inside network for the VTI endpoints is a 169.254.x.x/30 network with two addresses. Cisco uses the first IP address as its inside IP address. For example, if the Cisco inside IP address is 169.254.6.7/30, the customer IP address will be 169.254.6.8/30.
  - Tunnel destination IP address—Cisco outside IP address.
  - Cryptographic settings—Use the same or compatible settings as the Cisco peer:
    - IKE versions
    - Encryption
    - Integrity
    - DH groups
    - Customer startup action—For example, if you set the Cisco startup action to be Responder, then you should set the customer peer to be Initiator.
3. Configure a static route on the customer peer to send enforcer traffic to the proxy VPC network over the primary tunnel.
  
  To simplify routing for the two tunnels, you can configure two static routes—the primary one with a higher metric—and use static route tracking such as SLA monitor. For the monitored address, you can specify the Cisco outside IP address.
Mesh Policy Engine automatically routes traffic to your enforcers through the proxy. No additional Mesh Policy Engine configuration is required.
Configure the second tunnel but leave it administratively down.

If the primary tunnel goes down—for AWS maintenance, endpoint replacement, or any failure—bring up the standby manually and take the primary down.

Configure a static route with a lower metric for this tunnel.
For active/standby high availibility for the customer VPN peer, you can add a second VPN connection.

Like the active VPN connection, you can only make one of the tunnels active. High availability will fail over automatically to the standby VPN connection. There isn't any way to fail over automatically to the standby tunnel within each VPN connection, however.
To delete a connection, click the Delete icon.

Deleting the last remaining connection also tears down the proxy VPC and the proxy. All private connectivity infrastructure is removed, and any subsequent setup must start over when you add a new connection.