Cisco ASA Site to Site VPN ‘Using ASDM’

KB ID 0000072

Problem

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

Do the same from command line

Below is a walk-through for setting up one end of a site to site VPN Tunnel using a Cisco ASA appliance – Via the ASDM console. Though if (like me) you prefer using the Command Line Interface I’ve put the commands at the end.

click image for full subnet information

Solution

VPN Setup Procedure carried out on ASDM 6.4

Note: The video above uses IKE v1 and IKE v2, in reality you would choose one or the other, and for IKE v2 both ASA 5500 firewalls need to be running OS 8.4(1) or above.

VPN Setup Procedure carried out on ASDM 5.2

1. Open up the ADSM console. > Click Wizards > VPN Wizard.

2. Select “Site-to-Site VPN” > Next.

3. Enter the Peer IP address (IP of the other end of the VPN tunnel – I’ve blurred it out to protect the innocent) > Select “Pre Shared Key” and enter the key (this needs to be identical to the key at the other end. > Give the tunnel group a name or accept the default entry of its IP address. > Next.

4. Choose the encryption protocol (DES, 3DES, AES-128, AES-192, or AES256), choose the Authentication Method (SHA or MD5), and choose the Diffie Hellman Group (1, 2, 5 or 7). Note the other end must match, this establishes phase 1 of the tunnel. > Next.

5. Now select the Encryption Protocols (DES, 3DES, AES-128, AES-192, or AES256), choose the Authentication method (SHA, MD5 or None). Note this is for phase 2 and will protect the encrypted traffic “In Flight”. > Next.

6. Now you need to specify what traffic to encrypt, on the left hand side enter the network or host details (of what’s behind the ASA you are working on), and on the right hand side the IP address of the network or host that’s behind the other VPN endpoint.  Note the other end should be a mirror image. > Next.

7. Review the Settings (Note I’ve blurred the IP address out again) > Next.

8. Back at the ASDM console commit the settings to the ASA memory, Click File > “Save Running Configuration to Flash.”

ASA 5500 VPN Setup from command line

[box]

object network Site-A-SN
subnet 192.168.1.0 255.255.255.0
object network Site-B-SN
subnet 192.168.2.0 255.255.255.0
nat (inside,outside) source static Site-A-SN Site-A-SN destination static Site-B-SN Site-B-SN
access-list outside_1_cryptomap extended permit ip object Site-A-SN object Site-B-SN
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs
crypto map outside_map 1 set peer {Other Ends IP Address}
crypto map outside_map 1 set ikev1 transform-set ESP-3DES-SHA
crypto ikev1 enable outside
crypto ikev1 policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group {Other Ends IP Address} type ipsec-l2l
tunnel-group {Other Ends IP Address} ipsec-attributes
ikev1 pre-shared-key 12345678901234567890asdfg

[/box]

ASA 5500 VPN for Version 8.2 and older firewalls

[box]

access-list outside_20_cryptomap extended permit ip 10.254.254.0 255.255.255.0 10.1.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 10.254.254.0 255.255.255.0 10.1.0.0 255.255.0.0
nat (inside) 0 access-list inside_nat0_outbound
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 20 match address outside_20_cryptomap
crypto map outside_map 20 set pfs
crypto map outside_map 20 set peer {Other Ends IP Address}
crypto map outside_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group {Other Ends IP Address} type ipsec-l2l
tunnel-group {Other Ends IP Address} ipsec-attributes
pre-shared-key 12345678901234567890asdfg

[/box]

 

Related Articles, References, Credits, or External Links

Original article written 09/11/09

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

Cisco Router – Configure Site to Site IPSEC VPN

KB ID 0000933

Problem

I’ve done thousands of firewall VPN’s but not many that terminate on Cisco Routers. It’s been a few years since I did one, and then I think I was a wuss and used the SDM. So when I was asked to do one last week thankfully I had the configs ready to go.

I’m going to use the IP addresses above, and my tunnel will use the following settings;

  • Encryption: AES.
  • Hashing: SHA.
  • Diffie Hellman: Group 2.
  • PFS: Enabled.
  • Authentication method: Pre-Shared Key.

Solution

1. Setup a policy for phase 1 of the tunnel (ISAKMP).

[box]

R1>enable
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encr aes
R1(config-isakmp)#hash sha
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 86400
R1(config-isakmp)#crypto isakmp key SecretK3y address 1.1.1.2

[/box]

2. Setup an ACL to define what traffic will be encrypted, and a ‘Transform set’ that will dictate the encryption and hashing for phase 2 (IPSEC).

[box]

R1(config)#ip access-list extended VPN-ACL
R1(config-ext-nacl)#permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config-ext-nacl)#crypto ipsec transform-set VPN-TS esp-aes esp-sha-hmac

[/box]

3. Create a ‘Crypto map’ that is used to apply the phase 2 settings to an interface.

[box]

R1(config)#crypto map VPN-C-MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R1(config-crypto-map)#set peer 1.1.1.2
R1(config-crypto-map)#set transform-set VPN-TS
R1(config-crypto-map)#match address VPN-ACL

[/box]

4. Apply that crypto map to an interface, (usually the Internet facing one).

[box]

R1(config-crypto-map)#interface Serial0/1/0
R1(config-if)#crypto map VPN-C-MAP
*Jan 3 07:16:26.785: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#exit
R1(config)#

[/box]

5. In most cases your router will be doing NAT, if so you will need to change the ACL that is looking after the NAT for you, look in your running config for something that looks like the following;

[box]

R1#show run
Building configuration...

Current configuration : 1249 bytes
------------output removed for the sake of space------------
!

ip nat inside source list 100 interface Serial0/1/0 overload
!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
!

------------output removed for the sake of space------------
!
line aux 0
!

[/box]

6. To stop our VPN traffic getting NATTED, we need to put a deny in that ACL, and put it before that permit statement. Remember:

  • Permit=Perform NAT
  • Deny=Don’t perform NAT

On this router (unlike the ASA‘s that I’m more used to), there is no option to define an ACL line number. So its easier to remove the existing one, add the new line then put the original one back. Finally save the changes.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)#access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#exit
R1#
%SYS-5-CONFIG_I: Configured from console by console

R1#write mem
Building configuration...
[OK]

[/box]

7. Now at the other site, the config should be a mirror image. I will post it in its entirety, so you can copy and paste it into the router, I will highlight the bits you need to check and change in red.

[box]

crypto isakmp policy 1
encr aes
hash sha
authentication pre-share
group 2
lifetime 86400
crypto isakmp key SecretK3y address 1.1.1.1
ip access-list extended VPN-ACL
permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
crypto ipsec transform-set VPN-TS esp-aes esp-sha-hmac

crypto map VPN-C-MAP 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set VPN-TS
match address VPN-ACL
interface Serial0/1/0
crypto map VPN-C-MAP

no access-list 100 permit ip 20.20.20.0 0.0.0.255 any
access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 100 permit ip 10.10.10.0 0.0.0.255 any

[/box]

8. Test your VPN with the following commands. Note: you need to send some traffic over the VPN before it will establish!

[box]

show crypto isakmp sa
show crypto ipsec sa

[/box]

WARNING: If you have an ACL applied to the routers outside interface, you will need to allow in the Peer IP, like so;

[box]

ip access-list extended outside-in
 permit esp host 1.1.1.1 any
 permit udp host 1.1.1.1 any eq isakmp
 permit udp host 1.1.1.1 any eq non500-isakmp

[/box]

If you do not, the other end will fail Phase 1 with a WAIT_MSG_3 Error!

Related Articles, References, Credits, or External Links

NA

Cisco Simple GRE Tunnels (With IPSEC)

KB ID 0000951

Problem

I’ve spent years setting up VPN tunnels between firewalls. The only time I’ve ever dealt with GRE is for letting VPN client software though firewalls. GRE’s job is to ‘encapsulate’ other protocols and transport those protocols inside a virtual point to point link. Below is the topology, I’m going to use.

The tunnel will run form Router R1 to Router R3, once complete I should be able to ping Host2 from Host1.

Solution

Configure Router R1 for GRE

1. Create and configure a tunnel interface on the R1 Router. It will need an IP address, (here I’m using 10.0.0.1/30). Then you need to specify the source and destination of the GRE tunnel. Finally I’ve changed some MTU settings because typically MTU’s are set to 1500 and GRE adds an overhead, I’m dropping the MTU to 1400 and setting the maximum segment size to 1360.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Tunnel0
*Mar 1 00:01:27.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#ip mtu 1400
R1(config-if)#ip tcp adjust-mss 1360
R1(config-if)#tunnel source 1.1.1.1
R1(config-if)#tunnel destination 2.2.2.1
R1(config-if)#exit

[/box]

2. Then we need to add a static route to the router’s routing table so it knows to use that tunnel for traffic destined for the 192.168.2.0/24 network.

[box]

R1(config)#ip route 192.168.2.0 255.255.255.0 Tunnel0

[/box]

Configure Router R3 for GRE

3. This is simply a mirror image, of the configuration you carried our on router R1.

[box]

R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface Tunnel0
*Mar 1 00:01:30.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip address 10.0.0.1 255.255.255.252
R3(config-if)#ip mtu 1400
R3(config-if)#ip tcp adjust-mss 1360
R3(config-if)#tunnel source 2.2.2.1
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#exit
R3(config)#ip route 192.168.1.0 255.255.255.0 Tunnel0
[/box]

Verify GRE Tunnel

 

4. Use the following command to check the status of the GRE tunnel.

[box]

R1# show interface tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/30
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 1.1.1.1, destination 2.2.2.1
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

[/box]

5. Then make sure that traffic passes over the tunnel.

[box]

R1#ping 192.168.2.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/64/88 ms
R1#

[/box]

Securing the Tunnel with IPsec

6. Our traffic is now going where we want it to, and it’s encapsulated, but it’s still being ‘sent in clear’ if traffic is intercepted ‘in flight’ it can be read. So we need to secure that traffic by encrypting it. First Job is to create an ISAKMP policy that will establish ‘phase-1’ of our secure tunnel. I’m using AES, with Diffie Hellman group 2, and SHA hashing. Ive specified that I will be using a pre-shared-key so that’s been created with the last command, and is assigned to the IP of the ‘other end’ of the VPN tunnel.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption aes
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha
R1(config-isakmp)#exit
R1(config)#crypto isakmp key 0 Sh@reds3cret address 2.2.2.1

[/box]

7. Phase 2 of our tunnel (IPsec) is encrypted and hashed with a ‘transform set’ again I’m using AES and SHA, then I create a profile that uses my transform set.

[box]

R3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
R3(cfg-crypto-trans)#exit
R1(config)#crypto ipsec profile PF-PNL
R1(ipsec-profile)#set transform-set TFS-PNL
R1(ipsec-profile)#exit

[/box]

8. The last job is to apply the profile I created above, to our GRE tunnel interface.

[box]

R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
*Mar 1 00:20:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:20:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:20:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]

9. Again configure router 3 as a mirror image.

[box]

R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption aes
R3(config-isakmp)#group 2
R3(config-isakmp)#hash sha
R3(config-isakmp)#exit
R3(config)#crypto isakmp key 0 Sh@reds3cret address 1.1.1.1
R3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
R3(cfg-crypto-trans)#exit
R3(config)#crypto ipsec profile PF-PNL
R3(ipsec-profile)#set transform-set TFS-PNL
R3(ipsec-profile)#exit
R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
R3(config-if)#
*Mar 1 00:25:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:25:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:25:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]

Cisco IOS Verify IPsec VPN Tunnel Is Up

 

Note: To bring up the tunnel simply send some traffic over it by pinging something on the other side of the tunnel. If you get a reply then the tunnel is up! But to check it status firstly make sure phase 1 has established.

[box]

R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
1.1.1.1         2.2.2.1         QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

R3#

[/box]

QM_IDLE means that phase 1 has established (in Quick Mode), and is in an idle state (this is what you want to see, if you see any other state message you may need to start debugging things).

Once you know phase 1 is established you need to check phase 2.

[box]

R3#show crypto ipsec sa
interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 2.2.2.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 1.1.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 2.2.2.1, remote crypto endpt.: 1.1.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
     current outbound spi: 0x3AA3F6B0(983824048)

     inbound esp sas:
      spi: 0x5C5C5EF1(1549557489)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4559832/3506)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x3AA3F6B0(983824048)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4559832/3506)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

[/box]

 

Related Articles, References, Credits, or External Links

NA

Cisco – Configuring Dynamic Multipoint Virtual Private Networks DMVPN

KB ID 0000954

Problem

A while back I uploaded a run through on how to deploy GRE tunnels and protect those tunnels with IPsec. That point-to-point GRE tunnel is a good solution, but if you have a lot of sites it’s not a solution that scales very well. Yes you can have 2147483647 tunnel interfaces, but good luck manually configuring all those tunnels and even if you did, if you want each of your remote sites to talk to each other you have all those tunnels to configure as well.

To address that we have DMVPN, rather than a point-to-point GRE tunnel it uses multipoint GRE that can have more than two endpoints. In fact it acts like a ‘network overlay’ that joins all the sites together. It is typically deployed in a hub-and-spoke configuration where one router (the hub) sits at the center and each remote site (spoke) joins the multipoint GRE, tunnels back to the hub. The magic part is, if one spoke needs to speak to another spoke, this is done by building a dynamic tunnel between them ‘on the fly’.

Below is the the network topology I’m going to use;

Note: If you use GNS3 heres the topology and configs for all the routers.

I have a main site that will be the ‘Hub Site’ and at that site MainSiteRTR will be the NHS router. The remaining three hub sites will act as ‘spokes’, so my ‘network overlay’ will be 192.168.1.0/24.

Solution

Configure DMVPN Hub (NHS) Router

Before I start, all the sites are pre-configured as per figure1 above, all the routers can see each other via EIGRP.

1. To begin the setup looks very much like a standard GRE tunnel, but we define a source but no destination (we don’t need to, because we specify tunnel mode gre multipoint). There are two commands for the NHRP setup, ‘ip nhrp map multicast dynamic‘ lets EIGRP information propagate to the ‘spokes’. And ‘ip nhrp network-id 1’ creates a group ID for the DMVPN group. All the spokes will need to share this ID to form tunnels with this NHS Router.<.p>

[box]

MainSiteRTR#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
MainSiteRTR(config)#interface Tunnel0
MainSiteRTR(config-if)# ip address 192.168.0.1 255.255.255.0
MainSiteRTR(config-if)# ip nhrp map multicast dynamic
MainSiteRTR(config-if)# ip nhrp network-id 1
MainSiteRTR(config-if)# tunnel source 1.1.1.1
MainSiteRTR(config-if)# tunnel mode gre multipoint
*Mar 1 00:02:31.651: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
MainSiteRTR(config-if)#exit
*Mar 1 00:02:41.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
MainSiteRTR(config)#

[/box]

Configure the Branch ‘Spoke’ Routers

2. There are a few differences here, first ‘ip nhrp map 192.168.0.1 1.1.1.1’ tells the branch router to map the 192.168.0.2 private IP permanently to the 1.1.1.1 public address. ‘ip nhrp map multicast 1.1.1.1’ tells the router to relay ALL its multicast traffic back to the hub router. ‘ip nhrp nhs 192.168.0.1’ tells the spoke router where the hub router is.

[box]

Branch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#interface Tunnel0
Branch1(config-if)# ip address 192.168.0.2 255.255.255.0
Branch1(config-if)# ip nhrp map 192.168.0.1 1.1.1.1
Branch1(config-if)# ip nhrp map multicast 1.1.1.1
Branch1(config-if)# ip nhrp network-id 1
Branch1(config-if)# ip nhrp nhs 192.168.0.1
Branch1(config-if)# tunnel source 2.2.2.1
Branch1(config-if)# tunnel mode gre multipoint
*Mar 1 00:07:28.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
Branch1(config-if)#exit
*Mar 1 00:07:38.387: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Branch1(config)#

[/box]

3. Then configure each branch router the same, (apart from the tunnel source and the endpoint IP).

[box]

Branch 2 Router Config

Branch2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch2(config)#interface Tunnel0
Branch2(config-if)# ip address 192.168.0.3 255.255.255.0
Branch2(config-if)# ip nhrp map 192.168.0.1 1.1.1.1
Branch2(config-if)# ip nhrp map multicast 1.1.1.1
Branch2(config-if)# ip nhrp network-id 1
Branch2(config-if)# ip nhrp nhs 192.168.0.1
Branch2(config-if)# tunnel source 3.3.3.1
Branch2(config-if)# tunnel mode gre multipoint
Branch2(config-if)# exit
*Mar 1 00:09:32.631: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Branch2(config)#

Branch 3 Router Config

Branch3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch3(config)#interface Tunnel0
Branch3(config-if)# ip address 192.168.0.4 255.255.255.0
Branch3(config-if)# ip nhrp map 192.168.0.1 1.1.1.1
Branch3(config-if)# ip nhrp map multicast 1.1.1.1
Branch3(config-if)# ip nhrp network-id 1
Branch3(config-if)# ip nhrp nhs 192.168.0.1
Branch3(config-if)# tunnel source 4.4.4.1
Branch3(config-if)# tunnel mode gre multipoint
Branch3(config-if)# exit
*Mar 1 00:11:05.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
Branch3(config)#
*Mar 1 00:11:15.247: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Branch3(config)#

[/box]

Verifying and Testing the DMVPN Setup

4. On the main site;

[box]

MainSiteRTR#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:3,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1         2.2.2.1     192.168.0.2    UP    never D
     1         3.3.3.1     192.168.0.3    UP    never D
     1         4.4.4.1     192.168.0.4    UP    never D

[/box]

5. On a branch site (Note: There is only one tunnel to the Main Site);

[box]

Branch1#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:1,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1         1.1.1.1     192.168.0.1    UP 00:08:24 S

[/box]

6. But if from the same branch site you ping another branch site, it will dynamically build a tunnel to that site also. (Note: The S denotes static, and the D denotes dynamic).

[box]

Branch1#ping 192.168.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/60/108 ms

Branch1#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1         1.1.1.1     192.168.0.1    UP 00:08:52 S
     1         4.4.4.1     192.168.0.4    UP    never D

[/box]

Protect and Encrypt the Tunnel(s) with IPSEC

7. BE AWARE the traffic traveling over these tunnels is still being sent in cleartext, it’s simply been ‘encapsulated’ with GRE. To rectify that we can protect the tunnels with IPSEC.

[box]

MainSiteRTR#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
MainSiteRTR(config)#crypto isakmp policy 10
MainSiteRTR(config-isakmp)# authentication pre-share
MainSiteRTR(config-isakmp)# encryption aes
MainSiteRTR(config-isakmp)# group 2
MainSiteRTR(config-isakmp)# hash sha
MainSiteRTR(config-isakmp)# crypto isakmp key Sh@reds3cret address 2.2.2.1
MainSiteRTR(config)# crypto isakmp key Sh@reds3cret address 3.3.3.1
MainSiteRTR(config)# crypto isakmp key Sh@reds3cret address 4.4.4.1
MainSiteRTR(config)# crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
MainSiteRTR(cfg-crypto-trans)# crypto ipsec profile PF-PNL
MainSiteRTR(ipsec-profile)# set transform-set TFS-PNL
MainSiteRTR(ipsec-profile)# interface Tunnel0
MainSiteRTR(config-if)# tunnel protection ipsec profile PF-PNL
*Mar 1 00:25:34.055: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
MainSiteRTR(config-if)# exit
MainSiteRTR(config)#

[/box]

8. Then simply repeat on the branch routers, the only difference is the peer addresses.

[box]

Branch 1 Router Config

Branch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#crypto isakmp policy 10
Branch1(config-isakmp)# authentication pre-share
Branch1(config-isakmp)# encryption aes
Branch1(config-isakmp)# group 2
Branch1(config-isakmp)# hash sha
Branch1(config-isakmp)#crypto isakmp key Sh@reds3cret address 1.1.1.1
Branch1(config)#crypto isakmp key Sh@reds3cret address 3.3.3.1
Branch1(config)#crypto isakmp key Sh@reds3cret address 4.4.4.1
Branch1(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
Branch1(cfg-crypto-trans)#crypto ipsec profile PF-PNL
Branch1(ipsec-profile)# set transform-set TFS-PNL
Branch1(ipsec-profile)#interface Tunnel0
Branch1(config-if)# tunnel protection ipsec profile PF-PNL
Branch1(config-if)#exit
Branch1(config)#
*Mar 1 00:36:47.179: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
Branch1(config)#

Branch 2 Router Config

Branch2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch2(config)#crypto isakmp policy 10
Branch2(config-isakmp)# authentication pre-share
Branch2(config-isakmp)# encryption aes
Branch2(config-isakmp)# group 2
Branch2(config-isakmp)# hash sha
Branch2(config-isakmp)#crypto isakmp key Sh@reds3cret address 1.1.1.1
Branch2(config)#crypto isakmp key Sh@reds3cret address 2.2.2.1
Branch2(config)#crypto isakmp key Sh@reds3cret address 4.4.4.1
Branch2(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
Branch2(cfg-crypto-trans)#crypto ipsec profile PF-PNL
Branch2(ipsec-profile)# set transform-set TFS-PNL
Branch2(ipsec-profile)#interface Tunnel0
Branch2(config-if)# tunnel protection ipsec profile PF-PNL
Branch2(config-if)#exit
Branch2(config)#
*Mar 1 00:37:57.239: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
Branch2(config)#

Branch 3 Router Config

Branch3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch3(config)#crypto isakmp policy 10
Branch3(config-isakmp)# authentication pre-share
Branch3(config-isakmp)# encryption aes
Branch3(config-isakmp)# group 2
Branch3(config-isakmp)# hash sha
Branch3(config-isakmp)#crypto isakmp key Sh@reds3cret address 1.1.1.1
Branch3(config)#crypto isakmp key Sh@reds3cret address 2.2.2.1
Branch3(config)#crypto isakmp key Sh@reds3cret address 3.3.3.1
Branch3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
Branch3(cfg-crypto-trans)#crypto ipsec profile PF-PNL
Branch3(ipsec-profile)# set transform-set TFS-PNL
Branch3(ipsec-profile)#interface Tunnel0
Branch3(config-if)# tunnel protection ipsec profile PF-PNL
*Mar 1 00:39:10.515: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
Branch3(config-if)#exit

[/box]

9. To test re-establish the tunnels, and this time you can see they are protected;

[box]

MainSiteRTR#show crypto isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
1.1.1.1         3.3.3.1         QM_IDLE           1002    0 ACTIVE
1.1.1.1         4.4.4.1         QM_IDLE           1003    0 ACTIVE
1.1.1.1         2.2.2.1         QM_IDLE           1001    0 ACTIVE

[/box]

Download the DMVPN labs and have a play

Related Articles, References, Credits, or External Links

Cisco Simple GRE Tunnels (With IPSEC)

Cisco PIX 500 – IPSEC Site to Site VPNs (v6)

KB ID 0000611 

Problem

Note: This is for firewalls running an operating system BEFORE version 7, if you have an PIX running version 7 or above go here instead. I’ll run though he commands first and then the configuration from PDM at the end.

Solution

PIX 500: Configure a site to site VPN from command line

1. Connect to the PIX, go to “enable mode”, then to “Configure terminal mode”

[box]

User Access Verification

Password:
Type help or '?' for a list of available commands.
PetesPIX> enable
Password: ********
PetesPIX# configure Terminal
PetesPIX(config)# 

[/box]

2. I’m assuming the network BEHIND the PIX 500 is 192.168.124.0/24 and the network at the far end of the tunnel is 192.168.123.0/24. So I’m going to create two ACL’s one to tell the PIX that this traffic should be encrypted, and the second to tell the PIX NOT to perform NAT on the VPN traffic.

Note: Yes I can use one ACL, but having two makes it easier to troubleshoot any VPN problems.

[box]

PetesPIX(config)# access-list VPN_CRYPTO_ACL permit ip 192.168.124.0 255.255.255.0 192.168.123.0 255.255.255.0
PetesPIX(config)# access-list VPN_NO_NAT line 1 permit ip 192.168.124.0 255.255.255.0 192.168.123.0 255.255.255.0

[/box]

3. Now I’ve got an ACL that will stop performing NAT I need to add it as a “Nat 0” (this means don’t perform NAT).

Note: Check to make sure you do not already have a nat(inside) 0 xxx command, if you do, use the SAME ACL that is already in use.

[box]

PetesPIX(config)# nat (inside) 0 access-list VPN_NO_NAT

[/box]

4. To set up all the VPN parameters you need to create a crypto map. In the example below I set the peer IP (the firewall at the other end of the tunnel), to 81.81.81.81. Then I tie it to the ACL I created earlier (VPN_CRYPTO_ACL). I’ve set the encryption and hashing used for the tunnel to 3DES and SHA (These will be used for IPSec (Phase 2)). Set the timeouts for the tunnel, and finally apply the cryptomap I’ve just created, to the outside interface.

[box]

PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set peer 81.81.81.81
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 match address VPN_CRYPTO_ACL
PetesPIX(config)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set transform-set ESP-3DES-SHA
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set security-association lifetime seconds 28800 kilobytes 4608000
PetesPIX(config)# crypto map VPN_CRYPTO_MAP interface outside

[/box]

5. The next command lets VPN traffic bypass any other ACLs configured on the firewall.

[box]

PetesPIX(config)# sysopt connection permit-ipsec

[/box]

6. I’m using a “shared secret” that also needs to be setup on the other end of the tunnel. As I said earlier the peer IP is 81.81.81.81.

[box]

PetesPIX(config)# isakmp key 123456 address 81.81.81.81 netmask 255.255.255.255 no-xauth no-config-mode

[/box]

7. To establish the VPN phase 1 (ISAKMP) the devices at both ends of the tunnel need a matching ISAKMP policy. I’ve already set up my shared secret, the first line lets the other end know that’s how we will be communicating. Then once again I’m using 3DES and SHA. I’m telling the system to use Diffie Hellman group 2 for the secure key exchange, and then binding this policy to the outside interface.

Note: If you are interested on how all this stuff works see here

[box]

PetesPIX(config)# isakmp policy 20 authen pre-share
PetesPIX(config)# isakmp policy 20 encrypt 3des
PetesPIX(config)# isakmp policy 20 hash sha
PetesPIX(config)# isakmp policy 20 group 2
PetesPIX(config)# isakmp enable outside

[/box]

8. Then save the changes with a write mem command.

[box]

PetesPIX# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d

7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesPIX#

[/box]

PIX 500: Configure a site to site VPN from the PDM

1. To connect to the PDM you are going to need two things, an OLD browser (IE6) and an OLD version of Java. Select Wizards > VPN Wizard.

2. Site to Site > Next.

3. Set the Peer (Device at the other end of the tunnel) and a shared secret that you will also use at the other end > Next.

4. Set the policy that will be used for phase 1 > Next.

5. Now the phase 2 policy > Next

6. Enter the network behind the PIX > Next.

7. Enter the network at the far end of the tunnel > Finish.

8. Finish by saving the changes > File > Save running configuration to flash.

Related Articles, References, Credits, or External Links

Set up a PIX Firewall with the PDM

PIX 506E and 501 Firewall Image and PDM Upgrade

VPN Problem Cisco PIX v6 to Cisco ASA 5500

KB ID 0000761 

Problem

I found this out purely by accident today, while replacing an old PIX 506E that had died with an ASA 5505. The client’s other site still had a PIX 506E (Running 6.3(5)). I was setting up the VPN, and noticed something that WOULD have been a problem if I had not spotted it.

Solution

Essentially the older PIX firewalls are set for 3DES encryption, MD5 Hashing and Diffie Hellman 2. After version 8.4 the ASA does not have a policy set for this, you need to create one. If I had simply gone ahead, phase 1 of the VPN tunnel would not have established and I would have seen;

[box]

Password:
Type help or ‘?’ for a list of available commands.
Petes-ASA> en
Password: ********
Petes-ASA#debug crypto isakmp 200

<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>

Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=ce4a3ffe) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56
Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping
Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Information Exchange processing failed

<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>

[/box]

And phase 1 would have sat saying, MM_WAIT_MSG2. So you need to create a matching phase 1 (ISAKMP) policy on the ASA.

Create an IKE version 1 Policy via Command Line

1. Connect to the ASA and issue the following commands;

[box]Sent username “pete”
Type help or ‘?’ for a list of available commands.
Petes-ASA>
Petes-ASA> enable
Password: *******
Petes-ASA# configure terminal
Petes-ASA(config)#crypto ikev1 policy 1
Petes-ASA(config-ikev1-policy)# authentication pre-share
Petes-ASA(config-ikev1-policy)# encryption 3des
Petes-ASA(config-ikev1-policy)# hash md5
Petes-ASA(config-ikev1-policy)# group 2
Petes-ASA(config-ikev1-policy)# lifetime 86400
Petes-ASA(config-ikev1-policy)# exit
Petes-ASA(config)# write mem
Building configuration…
Cryptochecksum: b984ffbc dd77cdbf f2cd8d86 0b8f3f96

3965 bytes copied in 1.490 secs (3965 bytes/sec)
[OK]

[/box]

Create an IKE version 1 Policy via ASDM

If you are creating a Site to Site VPN tunnel from the ASDM wizard you can add the policy during step 6, like so;

Or to add it after the tunnel has been created, Configuration > Site-to-Site VPN > Advanced > IKE Policies > Add > The priority may be changed, but set the rest of the settings as shown. > OK > Apply > File > Save Running Configuration to Flash.

Related Articles, References, Credits, or External

Links

Cisco ASA5500 Site to Site VPN from ASDM

Cisco PIX 500 – IPSEC Site to Site VPNs (v6)

Cisco ASA Site to Site VPN’sSite to Site ISAKMP VPN (Main Mode)

KB ID 0000213

Problem

As with most things, before you have a hope of fixing something, you will stand a better chance if you know how it works in the first place. Below is a quick run though of what’s happening with your site to site VPN‘s and how they work.

For the entire process we will have two Cisco ASA 5500 firewalls and a site to site VPN.

Solution

What’s an Initiator and a Responder?

1. Our Laptop 192.168.1.50 wants to talk to a server on the other site at 172.16.1.50

2. To get out of the local network the Laptop goes through the ASA at its local site, The ASA knows that traffic destined for 172.16.1.50 needs to be sent down the VPN tunnel, so it needs to bring up the tunnel. IT BECOMES THE INITIATOR, contacts the ASA on the other site THAT BECOMES THE RESPONDER.

3 Once that’s complete the tunnel is up and traffic can pass.

So how does it bring up the Tunnel?

To establish an ISAKMP VPN tunnel 3 things have to happen.

1. Phase 1 has to complete.

2. Phase 2 has to complete.

3. The Traffic has to be allowed to pass.

VPN Phase 1 (ISAKMP)

This stage brings up the first secure tunnel (eventually there will be three tunnels) and for it to establish the firewalls need to agree what they are going to do to bring up the tunnel, then Secure the tunnel. This process uses SIX MESSAGES (Note: We are dealing to Main Mode here not Aggressive mode). Both firewalls need a matching Phase 1 Policy to continue. And the Policy is proposed in MESSAGE1 and accepted in MESSAGE2.

A Phase 1 policy consists of,

1. The Authentication method (either a pre shared key or an RSA signature is usual).

2. The Encryption method (DES, 3DES, AES, AES-192, or AES-256).

3. The Hashing Method (MD5 or SHA).

4. The Diffie Helman Group (1, 2 or 5 usually).

5. Lifetime (In seconds before phase 1 should be re-established – usually 86400 seconds [1 day]).

MESSAGE 1

The Initiator sends policies that it proposes to use, for phase 1 to the other ASA.

MESSAGE 2

Providing the responder has a matching policy it will accept one of those proposed by the initiator and send it back in message 2.

 

Now the two ends have agreed HOW they will establish phase 1, they then need to agree on a “Shared Key” both ends must use the same shared key, but the shared key cant be sent between them because the network link is not secure. To do this they use a Diffie Hellman key exchange, this uses a mathematical process called modular exponentiation, a simple example of how that works (The math’s involved in a real key exchange are much more complicated!).

How Diffie Hellman works (simply)

Problem Site A and Site B need to use the same secret key (which will be a big long number). they cant send that number to each other because if they do it will be seen.

Solution:

Both sites pick a random number, and they have a common number, this common number can be passed between sites, In our example Site A chooses 4 and Site B chooses 5

Both sites use the common number and raise it by the power of the random number they are using so Site A arrives at 16, and Site B at 32.

The sites then send the number they have arrived at, to the other site.

Each site uses the other sites total and raises it to the power of their original random number, this results in them both having the same key, with only the numbers 2, 16 and 32 being passed between them.

Back to our VPN Tunnel

The next two messages are the initiator and responder swapping their Diffie Hellman information, Each side produces a DH Public Key, and mathematically computes a long number called a “Nonce”

MESSAGE 3

The initiator generates a “Public Key” also called the DH Public Value or Xa It also generates a Nonce or Ni and sends both of them to the responder.

MESSAGE 4

The responder generates a “Public Key” also called the DH Public Value or Xb It also generates a Nonce or Nr and sends both of them to the initiator.

At this point both the initiator and the responder can calculate the DH Shared secret key, they then use the DH Secret Key, the “Shared Secret” that is manually entered onto both peers, and the Nonce from the other peer to create 3 DIGITAL KEYS, because of the nature of Diffie Hellman each end will produce the same keys.

Key 1 = SKEYID_d Used to work out any future IPsec keying Key 2 = SKEYID_a Used for data integrity and authentication (IKE) Key 3 = SKEYID_e Used to encrypt all further IKE traffic.

MESSAGE 5

The initiator now sends its ID to the responder (this is either its IP address or a hostname). It also sends a “Hash” this authenticates the initiator to the responder as its made from the SKEYID, the pre-shared key and other information only known to the two peers.

MESSAGE 6

Message 6 is basically the mirror of Message 5, the responder sends its ID (IP or Hostname) Back the the initiator with its “Hash” and authenticates itself back to the initiator.

At this point both peers recalculate the hash they have received from the other peer, and they should both come out the same, if this happens then the IKE SA’s are established and phase 1 is complete.

So what’s PFS?

Perfect Forward Secrecy is a method by which new keys are generated, each new key is mathematically linked to the key that came before it, the prior key being a “Grandfather” key. With PFS enabled this link is broken so a key can not be forward/reverse engineered to guess a previous/new key value). Every new negotiation produces a new fresh key.

VPN Phase 2

Once Phase 1 has completed the second stage of the VPN can start. Like phase 1 this state also requires messages to be sent between the peers, IPsec usually executes in “Quick mode” this means that there are only 3 MESSAGES.

Note: If PFS is configured only on one end then it will fail at this point with an “Attribute not supported” error.

MESSAGE 1

The Initiator sends another Hash to the responder, this is similar to the one used in phase 1 but also includes info within this message to guarantee integrity.

The Phase 2 proposal includes

1. Encapsulation method either ESP or AH.

2. Hashing method (Integrity checking) either SHA-HMAC or MD5-HMAC.

3. Diffie Hellman Group (1, 2, or 5).

4. The SPI – This number is the LABEL for the end of the tunnel the initiator will use for outbound traffic.

Tunnel mode (Tunnel or Transport). A timeout in seconds is specified, as is the ID (usually the subnet of both ends of the tunnel).

MESSAGE 2

The Responder replies with its own “Hash” with the accepted proposal and its own SPI for outgoing encrypted traffic from the responder, and finally its own Key Exchange Payload.

Once this is complete both peers generate new DH secret keys and combine them with the SKEYID_d key from phase 1 to create keys for IPsec encryption.

MESSAGE 3

The final Message is sent from imitator to responder, and serves to inform the responder that its previous message was received.

Once phase 2 is complete IPsec SA’s have been established and the tunnel is up.

 

Related Articles, References, Credits, or External Links

NA

Site to Site IPSEC VPN from SonicWALL to Cisco ASA

KB ID 0000357

Problem

You want to put in a secure IPSEC VPN tunnel from a Cisco ASA Device to a Sonicwall Firewall. Note in this example we will use 3DES for encryption, SHA1 for Hashing, Diffie Hellman Group 2, PFS enabled, and we will use a shared secret (Pre Shared Key).

SonicWALL used in this example is a PRO 3060.

Solution

The main two gotcha’s

Update 12/03/11 Feedback from Wajma Omari:

I would like to add that this configuration will build the Tunnel but one more step needed to enable the Traffic between the two networks and that is by adding ACL from Inside network to the Remote Site Configuration – Firewall – Advanced – ACL Manager – Add – Add ACL and then ADD ACE

Thanks for the very helpful article

Many Thanks for the feedback! Pete

Related Articles, References, Credits, or External Links

Special thanks to David Pounds for his help with the SonicWALL configuration.