Overview
This article is a short tutorial, written to provide a working example of a VPN configuration where the central hub is run by a Cisco ASA firewall and remote devices are either Cisco ASA firewalls or IOS routers, all of them behaving as Easy VPN hardware clients.
This kind of network may be useful to manage constrained network contexts where remote branches might not have static public IP addresses available, or even worse where our devices might be placed behind third-party network boxes making some kind of NAT toward the public Internet. It is common to find this kind of difficulties, they could be remote offices in developing countries or industrial plants where the IT infrastructure was not conceived from the beginning to be managed from a central location.
Requirements set for this VPN solution
We are trying to achieve the following:
- provide remote locations with a redundant uplink to make highly available the vpn tunnel
- not being constrained by the availability of static ip addresses or nat-free uplinks
- define a single entry point for the whole VPN, pointed by external users to reach any remote location
The choice of the correct devices for any remote location goes far beyond the scope of this text, we prefer to focus instead on the most interesting configuration details to understand how our goals were translated into Cisco nuts and bolts.
Network diagram
External users can connect to a central location using Cisco VPN Client to be redirected to remote locations, literally hairpinning one vpn tunnel into another, this will be described later in further detail.
Central ASA VPN hub – Easy VPN server
hostname VPNHUB interface Ethernet0/0 nameif outside security-level 0 ip address 192.0.1.2 255.255.255.248 route outside 0.0.0.0 0.0.0.0 192.0.1.1 1 interface Ethernet0/3 nameif inside security-level 100 ip address 192.168.10.1 255.255.255.0 !--- this line allows the reverse tunnel (hairpin) between different tunnels same-security-traffic permit intra-interface !--- pools objects and nats ip local pool vpnpool 172.16.16.1-172.16.16.254 mask 255.255.255.0 ip local pool clientpool 172.16.17.1-172.16.17.254 mask 255.255.255.0 object network inside subnet 192.168.10.0 255.255.255.0 object network branch1 subnet 10.1.1.0 255.255.255.0 object network branch2 subnet 10.1.2.0 255.255.255.0 object network branch2 subnet 10.1.3.0 255.255.255.0 object network branch3 subnet 10.1.4.0 255.255.255.0 nat (inside,outside) source static inside inside destination static branch1 branch1 nat (inside,outside) source static inside inside destination static branch2 branch2 nat (inside,outside) source static inside inside destination static branch3 branch3 nat (inside,outside) source static inside inside destination static branch4 branch4 object network inside nat (inside,outside) dynamic interface !--- crypto map and related ACLs access-list VPN_CLient_nets standard permit 192.168.10.0 255.255.255.0 access-list VPN_CLient_nets standard permit 10.1.1.0 255.255.255.0 access-list VPN_CLient_nets standard permit 10.1.2.0 255.255.255.0 access-list VPN_CLient_nets standard permit 10.1.3.0 255.255.255.0 access-list VPN_CLient_nets standard permit 10.1.4.0 255.255.255.0 access-list NEMCLient_branch1 standard permit 10.1.1.0 255.255.255.0 access-list outside extended permit ip 10.1.0.0 255.255.0.0 any access-list outside extended permit udp any host 192.0.1.2 eq 4500 access-list outside extended deny ip any any access-list inside extended permit ip any any access-group outside in interface outside access-group inside in interface inside crypto ipsec ikev1 transform-set esp-aes256-sha esp-aes-256 esp-sha-hmac crypto dynamic-map outside_dyn_map 10 set ikev1 transform-set esp-3des-sha crypto dynamic-map outside_dyn_map 10 set security-association lifetime seconds 86400 crypto dynamic-map outside_dyn_map 10 set security-association lifetime kilobytes 2147483647 crypto map outside_map 10 ipsec-isakmp dynamic outside_dyn_map crypto map outside_map interface outside crypto ikev1 enable outside crypto ikev1 policy 10 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 !--- VPN client to be hairpinned to the NEM tunnel group-policy RA-SWclientpol internal group-policy RA-SWclientpol attributes vpn-idle-timeout none split-tunnel-policy tunnelspecified split-tunnel-network-list value VPN_CLient_nets tunnel-group RA-SWclient type remote-access tunnel-group RA-SWclient general-attributes address-pool clientpool default-group-policy RA-SWclientpol tunnel-group RA-SWclient ipsec-attributes ikev1 pre-shared-key ***** isakmp keepalive threshold 30 retry 5 !--- NEM tunnel from branch devices group-policy branch1pol internal group-policy branch1pol attributes vpn-idle-timeout none split-tunnel-policy tunnelspecified split-tunnel-network-list value NEMCLient_branch1 tunnel-group branch1 type remote-access tunnel-group branch1 general-attributes address-pool clientpool default-group-policy branch1pol tunnel-group branch1 ipsec-attributes ikev1 pre-shared-key d1jkstrahatesMe isakmp keepalive threshold 30 retry 5 ikev1 user-authentication none
There are some interesting bits of code here:
-
same-security-traffic permit intra-interface
first of all, this makes possible the “hairpin” between different tunnels, where packets coming from external software-based VPN clients are reverse-routed and encapsulated inside Easy VPN tunnels
-
vpn-idle-timeout none
this is required to allow the creations of IPSEC security associations for the VPN Client address pool even when clients are not connected; if a VPN clients connects after an Easy VPN client branch1, it would be basically kept out of its remote network 10.1.1.0/24 without this line
-
ikev1 user-authentication none
this flags allows the remote devices to connect without entering any user credential other than PSK group password, this is required if the remote device inside the branch location is unmanned, for instance in plant monitoring
Remote router – Easy VPN client
!--- EzVPN clients to be bound to uplink interfaces, they are both !--- pointed toward our ASA's outbound interface crypto ipsec client ezvpn EasyBackup connect auto group branch1 key DijkstraHatesMe mode network-extension peer 192.0.1.2 crypto ipsec client ezvpn Easytunnel connect auto group branch1 key DijkstraHatesMe !--- some configuration was omitted here for the sake of shortness !--- we tracking main uplink availability using IP SLA routines backup EasyBackup track 10 mode network-extension peer 192.0.1.2 !--- main uplink interface FastEthernet4 ip nat outside crypto ipsec client ezvpn EasyTunnel !--- failover uplink, in this example it is a UMTS interface interface Cellular0 ip nat outside crypto ipsec client ezvpn EasyBackup !--- internal interface, some unrelevant lines were striped off interface Vlan1 ip address 10.1.1.254 255.255.255.0 ip nat inside crypto ipsec client ezvpn EasyTunnel inside crypto ipsec client ezvpn EasyBackup inside
Configuration of branch devices is pretty straightforward, the failover/failback mechanism is basically handled by IP SLA and tracking configuration, but we won’t get into these details here: to accomplish a highly available VPN, the router is initiating Easy VPN tunnels from both uplinks.
Easy VPN network extension mode – handle with care
Easy VPN comes handy, as explained in the overview, when facing constrained branch connectivity since it works using dynamic ip addresses or even being located behind NAT-ting devices. However, this is far from being a best practice and, if possible, better solutions such as DMVPN should be evaluated first as long as we can avoid some constraints.
Furthermore, Cisco is advising not to let Easy VPN Clients connect without user authentication, because if the devices is lost or stolen an attacker could retrieve our tunnel-group PSK and be able to connect to the network. To mitigate this problem, some steps could be taken:
- enforce physical security and place remote devices within hardened enclosures, such as NEMA boxes
- use different PSKs for any branch location
- apply the least privilege principles and limit all unneeded traffic on the central VPN hub (occam’s razor keeps coming back!)
- forbid any login to central hub device from remote locations
- undertake any action aimed at reducing the scope of a compromise, even at higher session and application layers
Afterword
This configuration is currently used in a production network, using Cisco ASA 5510 as the VPN server and Cisco ASA 881 G routers as remote devices. Feel free to contact me if you are trying out this configuration.
