Skip to main content

 

 

Cisco Defense Orchestrator

Configuring Site-to-Site VPN for Firepower Threat Defense

Cisco Defense Orchestrator (CDO) supports these aspects of site-to-site VPN functionality on Firepower Threat Defense devices:

  • Both IPsec IKEv1 & IKEv2 protocols are supported.
  • Automatic or manual pre-shared keys for authentication.
  • IPv4 and IPv6. All combinations of inside and outside are supported.
  • IPsec IKEv2 site-to-site VPN topologies provide configuration settings to comply with Security Certifications.
  • Static and dynamic interfaces.
  • Support for the dynamic IP address for the extranet device as an endpoint.

Extranet Devices

Each topology type can include extranet devices that you do not manage in CDO. These include:

  • Cisco devices that CDO supports, but for which your organization is not responsible. Such as spokes in networks managed by other organizations within your company, or a connection to a service provider or partner's network.
  • Non-managed devices.  You cannot use CDO to create and deploy configurations to non-managed devices. Add non-managed devices to a VPN topology as "Extranet" devices. Also, specify the IP address of each remote device.

Configure Site-to-Site VPN Connections with Dynamically-Addressed Peers

CDO allows you to create a site-to-site VPN connection between peers when one of the peers' VPN interface IP address is not known or when the interface obtains its address from a DHCP server. Any dynamic peer whose preshared key, IKE settings, and IPsec configurations match with another peer can establish a site-to-site VPN connection.

Consider two peers, A and B. The static peer is a device whose IP address of its VPN interface is fixed and a dynamic peer is a device whose IP address of the VPN interface is not known or has a temporary IP address.

The following use cases describe different scenarios for establishing a secure site-to-site VPN connection with dynamically-addressed peers: 

  • A is a static peer, and B is a dynamic peer or conversely. 
  • A is a static peer, and B is a dynamic peer with a resolved IP address from the DHCP server or conversely. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.   
  • A and B are dynamic with resolved IP addresses from the DHCP server. In such a case, you must select Bind VPN to the assigned IP for at least one peer to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer.  
  • A is a dynamic peer, and B is an extranet device with a static or dynamic IP address. 
  • A is a dynamic peer with a resolved IP address from the DHCP server, and B is an Extranet device with a static or dynamic IP address. You can select Bind VPN to the assigned IP to establish the VPN connection between the IP address of the static peer and the DHCP assigned IP address of the dynamic peer. 

Important: If you select Bind VPN to the assigned IP, the VPN binds statically to the DHCP assigned IP address. However, this dynamic interface can receive many new IP addresses after the peer restarts. Although the VPN tunnel updates the new IP address, the other peer is not updated with the new configuration. You must deploy the site-to-site configuration again for out-of-band changes on the other peer.

Note: If the IP address of the interface is changed by using a local manager like Firepower Threat Defense Manage (FDM), the Configuration Status of that peer in CDO shows "Conflict Detected". When you resolve this out-of-band change, the Configuration Status of the other peer changes to the “Not Synced” state. You must deploy the CDO configuration to the device which is in “Not Synced” state.

Typically, the dynamic peer must be the one that initiates the connection as the other peer would not know the IP address of the dynamic peer. When the remote peer attempts to establish the connection, the other peer validates the connection using the preshared key, IKE settings, and IPsec configurations. 

Because the VPN connection is established only after the remote peer initiates the connection, any outbound traffic that matches access control rules that allow traffic in the VPN tunnel will be dropped until that connection is established. This ensures that data does not leave your network without the appropriate encryption and VPN protection.

Note: A site-to-site VPN connection cannot be configured in the following scenarios:

  • If both peers have DHCP assigned IP addresses.
    • Workaround: You can configure a site-to-site VPN, if one of the peers has a resolved IP address from the DHCP server. In such a case, you must select Bind VPN to the assigned IP to configure site-to-site VPN.
  • If a device has more than one dynamic peer connection. 
    • Workaround: You can configure a site-to-site VPN by performing the following steps:
      • Consider three devices A, B, and C. 
      • Configure site-to-site VPN connection between A (static peer) and B (dynamic peer).
      • Configure site-to-site VPN connection between A and C (dynamic peer) by creating an Extranet device. Assign the static VPN interface IP address of A to the Extranet device and establish a connection with C.

Firepower Threat Defense Site-to-Site VPN Guidelines and Limitations

  • CDO does not support a crypto-acl to design the interesting traffic for S2S VPN. It only supports protected networks.
  • Whenever IKE ports 500/4500 are in use or when there are some PAT translations that are active, the site-to-site VPN cannot be configured on the same ports as it fails to start the service on those ports.
  • Transport mode is not supported only tunnel mode. IPsec tunnel mode encrypts the entire original IP datagram which becomes the payload in a new IP packet. Use tunnel mode when the firewall is protecting traffic to and from hosts positioned behind a firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.
  • For this release, only PTP topology is supported, containing one or more VPN tunnels. Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints. 

Related Topics:

  • Was this article helpful?