giovedì, Marzo 28, 2024

Easy VPN server for constrained branch networks

AreaNetworking.it
AreaNetworking.ithttps://www.areanetworking.it
AreaNetworking.it è tra i principali e più storici media italiani del settore ICT. Nato nel 2003 per opera di Federico Lagni, l'attività del gruppo è sia online - con il portale rivolto a figure professionali ICT (IT Manager, CTO, Security Specialist, Datacenter Engineer, etc) - sia offline con l'organizzazione delle più importanti conferenze italiane su temi tecnologici.

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

Vpn overview

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.

 

Articoli correlati

Non perdere il lancio online della Community GDPR Day: 26 marzo 2024

La sicurezza dei dati e delle informazioni non è più un'opzione, ma una necessità imprescindibile. Lo dimostrano i tanti attacchi informatici che, con frequenza...

Digital Transformation


 

Noleggia una Tesla per il tuo evento ICT!

Categorie