Site-to-Site VPN Configuration Between ASAs

Security Cloud Control supports these aspects of site-to-site VPN functionality on Adaptive Security Appliance (ASA) 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 the static or dynamic IP address for the extranet device as an endpoint.

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

Security Cloud Control 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.

  • 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.

Note

If the IP address of the interface is changed by using a local manager like Adaptive Security Device Manager (ASDM), the Configuration Status of that peer in Security Cloud Control 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 Security Cloud Control 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 scenario:

If a device has more than one dynamic peer connection.

  • 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.

ASA Site-to-Site VPN Guidelines and Limitations

  • Security Cloud Control 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.

Guidelines for Virtual Tunnel Interfaces

  • VTIs are only configurable in IPsec mode. To terminate GRE tunnels on an ASA is unsupported.

  • You can use dynamic or static routes for traffic using the tunnel interface.

  • The MTU for VTIs is automatically set, according to the underlying physical interface. However, if you change the physical interface MTU after the VTI is enabled, you must disable and reenable the VTI to use the new MTU setting.

  • If Network Address Translation has to be applied, the IKE and ESP packets will be encapsulated in the UDP header.

  • IKE and IPsec security associations will be re-keyed continuously regardless of data traffic in the tunnel. This ensures that VTI tunnels are always up.

  • Tunnel group name must match what the peer will send as its IKEv1 or IKEv2 identity.

  • For IKEv1 in LAN-to-LAN tunnel groups, you can use names which are not IP addresses, if the tunnel authentication method is digital certificates and/or the peer is configured to use aggressive mode.

  • VTI and crypto map configurations can co-exist on the same physical interface, provided the peer address configured in the crypto map and the tunnel destination for the VTI are different.

  • By default, all traffic through VTI is encrypted.

  • By default, the security level for VTI interfaces is 0.

  • Access list can be applied on a VTI interface to control traffic through VTI.

  • Only BGP is supported over VTI.

  • If ASA is terminating IOS IKEv2 VTI clients, disable the config-exchange request on IOS, because ASA cannot retrieve the mode-CFG attributes for this L2L session initiated by an IOS VTI client.

  • IPv6 is not supported.