Tuesday, January 4, 2011

L2L VPN Config *** ASA section ***

Background information

Have two sites which require a L2L VPN tunnel.  One is a head office/data center location running a ASA firewall and the other one is a remote branch office using a Cisco Router.  The config covered below assumes that both the router and the firewall already have a basic working configuration.  Details below:

Remote Office
Location: Badell, Singapore
Device: 1841 with adventerprisek9-m 12.4(25d)
LAN: 10.251.6.0 /23
WAN: 124.66.16.231

Head Office
Location: Sydney, Australia
Device: ASA 5540 with ASA software v 8.2(2)
LAN: all private ranges
WAN: 203.38.18.222


[INSERT DIAGRAM HERE]




STEP 1 - NAT and ACLS
The first steps are to do with creating (or modifying existing) NAT rules and access-lists in order to control which traffic is allowed to go through the tunnels and wether it is NAT'ed or not

STEP 1.1 - ACL modification to allow traffic past the inside ACL
The 'inside' ACL will have to be modified to allow the appropiate head office subnets access to the remote LAN.  In the example below badell_deg is an object-group with the internal or head office side subnets and badell_singapore_lan is a object-group with the remote LAN's subnet.


access-list acl_in extended permit ip object-group baddell_deg object-group baddell_lan



STEP 1.2 - New ACL to match traffic to be encrypted (referenced in tunnel group)
Later configurations sections require an ACL to match the source and destination of traffic which is to be encrypted.  The same object-groups as above were used.

access-list BADELL_VPN extended permit ip object-group baddell_deg object-group baddell_lan

STEP 1.3 Make sure tunnel bound traffic is not NAT'ed
An ACL needs to get created to match traffic which we do not want to be NAT'ed. note: there may be a pre-existing 'NONAT' ACL already.

access-list NONAT remark ** match DEG subnets to the Badell (Singapore) site **
access-list NONAT extended permit ip object-group baddell_deg object-group baddell_lan

If there is not an existing 'NONAT' ACL we'll also have to create a nat 0 statement which references the interface where traffic is coming from and the ACL name. note: the zero (0) code means do NOT nat.

nat (inside) 0 access-list NONAT
 
The following PAT (code 1) statement will do a global nat with anything that doesn't match the nonat ACL above.  This line will probably already be there and is not strictly required for VPN operation.

nat (inside) 1 10.0.0.0 255.0.0.0


STEP 2 - VPN CONFIG
STEP 2.1 - Crypto isakmp policy (phase 1) key exchange
This is what first greets other devices trying to connect to the ASA and attempts to negotiate phase 1.  In theory one ISAKMP policy could be sufficient to catch all VPN tunnels, however in practice not all devices support a standard set of attributes.  In most cases you'll have many policies (or as many as required) with slightly different policy attributes eg. 3des instead of aes or sha instead of md5.  

Connecting devices will go down the list of policies sequentially until it finds a set of attributes which match it's own. The following shows an example of a ISAKMP policy:


crypto isakmp enable outside
crypto isakmp policy 1
  authentication pre-share
  encryption aes
  hash md5
  group 1
  lifetime 86400


STEP 2.2 - Crypto ipsec transform set
This is a step which negotiates phase 2 encryption attributes. As with the isakmp policy many transform sets may be required in order to cover all VPN tunnels. (write more about he two attributes). The following line shows an example of a transform set:

crypto ipsec transform-set STANDARD esp-aes esp-sha-hmac


STEP 2.3 - Tunnel group
The tunnel group IP address refers to the remote WAN IP - **** refers to the PSK (ASA hides by default)

tunnel-group 124.66.136.122 type ipsec-l2l
tunnel-group 124.66.136.122 ipsec-attributes
  pre-shared-key ****


STEP 2.4 - Crypto map
The crypto map config ties in all the different VPN tunnel configuration sections. The first line defines a name (the word tunnel is a variable) and specifies an interface, in this case outside.


crypto map tunnel interface Outside

crypto map tunnel 10 match address BADELL_VPN
(one thing to note is the ASA will tell you config is not complete here)
crypto map tunnel 10 set peer 124.66.16.231
crypto map tunnel 10 set transform-set STANDARD




Final Steps
The firewall must have a route which directs traffic destined to the remote office LAN via the outside interface of the firewall.  In the example below the whole 10.251.0.0 /16 range (VPN range) has been diverted to the outside interface.

route Outside 10.251.0.0 255.255.0.0 203.58.41.254 1



...Router side config to follow in the next post.


No comments:

Post a Comment