Cisco ASA: Bridge mode with dynamic VPN tunnel. Part2.

Now once Network side is configured we can move on to VPN configuration specifics.

Since the user is most likely behind an Internet modem with dynamic private IP we need to configured dynamic VPN. In order to avoid failing PCI, SOX, and other security audits related to IKEv1 aggressive mode we will configure IKEv2 and peer id validation.

Below is configuration breakdown.

Define interesting traffic for both tunnels

object network OG_Local-to-dc1
subnet 10.x.x.x 255.255.255.0
object network OG_Local-to-dc2
subnet 10.y.y.y 255.255.255.0
access-list dc1 extended permit ip object OG_Local-to-dc1 object-group OG_RFC-1918
access-list dc2 extended permit ip object OG_Local-to-dc2 object-group OG_RFC-1918

Build Phase1 policies. Setup identity key-id for VPN hubs to identify this ASA. Key-id will be different for each remote ASA to properly build dynamic tunnels.

crypto isakmp identity key-id ASA-id1    /// each id needs to be unique per ASA
crypto isakmp disconnect-notify
crypto ikev2 policy 1
encryption aes-256
integrity sha
group 5 2
prf sha
lifetime seconds 86400
crypto ikev2 enable outside

Build Phase 2 policy.

crypto ipsec ikev2 ipsec-proposal AES256
protocol esp encryption aes-256
protocol esp integrity sha-1 md5

Define Group Policy (GP) to enforce IKEv2.

group-policy GroupPolicy_ikev2 internal
group-policy GroupPolicy_ikev2 attributes
vpn-tunnel-protocol ikev2

Define Crypto-Map (CM) policies for both tunnels and assign it to outside interface.

crypto map outside_map 1 match address dc1
crypto map outside_map 1 set peer <dc1 IP>
crypto map outside_map 1 set ikev2 ipsec-proposal AES256
crypto map outside_map 1 set security-association lifetime kilobytes unlimited
crypto map outside_map 2 match address dc2
crypto map outside_map 2 set peer <dc2 IP>
crypto map outside_map 2 set ikev2 ipsec-proposal AES256
crypto map outside_map 2 set security-association lifetime kilobytes unlimited
crypto map outside_map interface outside

Tunnel Group to dc1.

 tunnel-group <dc1 IP> type ipsec-l2l
tunnel-group <dc1 IP> general-attributes
default-group-policy GroupPolicy_ikev2
tunnel-group <dc1 IP> ipsec-attributes
ikev2 remote-authentication pre-shared-key <key1>
ikev2 local-authentication pre-shared-key <key1>

Tunnel Group to dc2.

tunnel-group <dc2 IP> type ipsec-l2l
tunnel-group <dc2 IP> general-attributes
default-group-policy GroupPolicy_ikev2
tunnel-group <dc2 IP> ipsec-attributes
ikev2 remote-authentication pre-shared-key <key2>
ikev2 local-authentication pre-shared-key <key2>

Hub configuration will be similar to certain extend. This section only needs to be configured once.

crypto ikev2 policy 1
encryption aes-256
integrity sha
group 5 2
prf sha
lifetime seconds 86400

crypto ikev2 enable outside
crypto isakmp identity auto

crypto ipsec ikev2 ipsec-proposal AES256
protocol esp encryption aes-256
protocol esp integrity sha-1 md5

Note the difference between Hub and Spoke GP. Hub will have additional attributes configured.

group-policy GroupPolicy_ikev2 internal
group-policy GroupPolicy_ikev2 attributes
vpn-idle-timeout none
vpn-session-timeout none
vpn-tunnel-protocol ikev2
nem enable
address-pools none

Configuration below is for dc1 Hub and will change with each additional remote ASA.

object network obj_dc1-to-Remote-ASA1
subnet 10.x.x.x 255.255.255.0
access-list Remote-ASA1_Subnets extended permit ip object-group OG_RFC-1918 object obj_dc1-to-Remote-ASA1

Separate Dynamic CM will be defined per Remote ASA.

crypto dynamic-map ASA-id1 1 match address Remote-ASA1_Subnets
crypto dynamic-map ASA-id1 1 set ikev2 ipsec-proposal AES256

Then it will be attached to static CM with unique sequence number. It is best to keep track of CM sequence numbers to avoid duplicates.

crypto map outside_map # ipsec-isakmp dynamic Remote-ASA1

Tunnel-group id needs to match Remote ASA id.

tunnel-group ASA-id1 type ipsec-l2l
tunnel-group ASA-id1 general-attributes
default-group-policy GroupPolicy_ikev2

tunnel-group ASA-id1 ipsec-attributes
ikev2 remote-authentication pre-shared-key <key1>
ikev2 local-authentication pre-shared-key <key1>

Configuration below is for dc2 Hub and will change with each additional remote ASA.

object network obj_dc2-to-Remote-ASA1
subnet 10.y.y.y 255.255.255.0

access-list Remote-ASA1_Subnets extended permit ip object-group OG_RFC-1918 object obj_dc2-to-Remote-ASA1

Separate Dynamic CM will be defined per Remote ASA. Keep names the same across the Hubs.

crypto dynamic-map ASA-id1 1 match address Remote-ASA1_Subnets
crypto dynamic-map ASA-id1 1 set ikev2 ipsec-proposal AES256

Keep sequence numbers the same across the Hubs for simple tracking.

crypto map outside_map # ipsec-isakmp dynamic Remote-ASA1

tunnel-group ASA-id1 type ipsec-l2l
tunnel-group ASA-id1 general-attributes
default-group-policy GroupPolicy_ikev2

tunnel-group ASA-id1 ipsec-attributes
ikev2 remote-authentication pre-shared-key <key2>
ikev2 local-authentication pre-shared-key <key2>

Now since this is a dynamic tunnel there are a few caveats.

One of them is traffic has to initiate from remote ASA in order to establish specific Security Association (SA) within VPN tunnel. Here is an example where remote ASA networks only have SAs to 10.0.0.0/8. If traffic was to initiate from 172.16.0.0/12 it would fail because SA does not exist.

One simple solution to this is adding fake ntp server residing on 172.16.0.0/12 subnet.

ntp server 172.21.1.1 source <interface>   /// management-access interface

As you can see SA is created and traffic can now be initiated from 172.16.0.0/12.

Unfortunately, this will only work from the interface defined as management access. If you try to use any other interface it will fail routing lookup so it will not work on the second tunnel. That’s why I’ve assigned port 1/6 to dc1 subnet so SA is built over the primary tunnel.

Another concern is ASA management. I’ve already mentioned it has to be a Layer3 physical interface but another limitation is “management-access” command allows only single interface to be defined. So if your management is on primary subnet and tunnel goes down you have no way of managing this ASA. For that reason, I’ve assigned FP IP on the secondary tunnel. That way I can always ssh to it over the back-up tunnel and from CLI expert mode connect to inside interface of the ASA. If you have a switch trunked to ASA you can use that as jump box and also resolve all of the concerns with IPSEC SAs through SLA mechanism by run continuous pings from primary and secondary Vlan interfaces.

Leave a reply:

Your email address will not be published.

Site Footer

Sliding Sidebar