Cisco ASA: ‘Received an un-encrypted INVALID_COOKIE notify message, dropping’

KB ID 0001421

Problem

Saw this in a forum today, and knew what it was straight away! While attempting to get a VPN tunnel up from a Cisco ASA (5508-x) to a Sonicwall firewall this was there debug output;

[box]

Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE Initiator: New Phase 1, Intf Lan, IKE Peer x.x.x.x local Proxy Address 192.168.90.150, remote Proxy Address 10.252.1.1, Crypto map (Internet_map)
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing ISAKMP SA payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing Fragmentation VID + extended capabilities payload
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 340
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 96
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing SA payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Oakley proposal is acceptable
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing ke payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing nonce payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing Cisco Unity VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing xauth V6 VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Send IOS VID
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 320
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 272
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing ke payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing ISA_KE payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing nonce payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Received xauth V6 VID
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, Connection landed on tunnel_group x.x.x.x
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, Generating keys for Initiator...
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing ID payload
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing hash payload
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, Computing hash for ISAKMP
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing dpd vid payload
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 110
Apr 06 00:45:29 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=c0ea3190) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 220
Apr 06 00:45:29 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=c0ea3190) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 220
Apr 06 00:45:29 [IKEv1]Group = x.x.x.x, IP = x.x.x.x, Received an un-encrypted INVALID_COOKIE notify message, dropping

[/box]

Solution

So we can see phase 1 (ISAKMP v1) isn’t establishing, I’ve seen this happen before, you need to get the ASA to specify its IP address as its identification.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# crypto isakmp identity address

[/box]

Then try again!

Related Articles, References, Credits, or External Links

NA

Implementing GDOI into DMVPN

KB ID 0000956 

Problem

Just recently I covered DMVPN, which is a great scalable system for adding new sites to your network infrastructure and have them join an existing VPN solution without the need to add extra config at the ‘hub’ site.

One of the advantages of DMVPN is it maintains VPN connections from your ‘Spoke’ sites back to the ‘Hub’ site, but if a spoke site needs to speak to another spoke site, it will dynamically build a VPN tunnel to that spoke site.

That’s great right? Well it’s pretty cool, but there is a downside. There is a slight ‘lag’ while that dynamic VPN is established, for normal network traffic you probably wont even notice, but if you are sending streaming media, or voice traffic then it becomes more of a problem.

So if we had a system where all the routers have all the same settings, the hub router wouldn’t need to ‘broker’ the initial connection and the routers get all their VPN settings from a central ‘Server’. Well that’s what GDOI gives us, we set up a router as a central ‘Key Server’ and all the other GDOI ‘Group Members’ register with the key server, and get all their settings.

So I’ll use the same network that I built the DMVPN on, I’ve added another router that will be the ‘Key Server’, other than that the topology is the same.

Note: The GDOI Key Server, cannot run on the DMVPN hub router.

Solution

GDOI Key Server Setup

1. Firstly setup the requirements for ISAKMP phase 1. Note: here I’m using pre-shared keys, this does not scale well if you have a lot of sites, you might want to look at a PKI solution and use certificates instead.

[box]

crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0

EXAMPLE

KS#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
KS(config)#crypto isakmp policy 10
KS(config-isakmp)#encr aes
KS(config-isakmp)#authentication pre-share
KS(config-isakmp)#group 2
KS(config-isakmp)#crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0
KS(config)#

[/box]

2. Then setup IPSEC phase 2 requirements. With a transform-set and a profile.

[box]

crypto ipsec transform-set TS-GDOI esp-aes esp-sha-hmac

crypto ipsec profile PF-GDOI
set transform-set TS-GDOI

EXAMPLE

KS(config)#crypto ipsec transform-set TS-GDOI esp-aes esp-sha-hmac
KS(cfg-crypto-trans)#crypto ipsec profile PF-GDOI
KS(ipsec-profile)#set transform-set TS-GDOI
KS(ipsec-profile)#

[/box]

3. The Key server will use its certificate for authentication, if you DO have a PKI solution and this router has already enrolled to it then you can skip this step. If not you need to generate a LOCAL certificate on the key server. (Note: This requires the device to have a hostname and domain name set).

[box]

ip domain-name testbench.local
crypto key generate rsa modulus 2048

EXAMPLE

KS(config)#ip domain-name testbench.local
KS(config)#crypto key generate rsa modulus 2048

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
*Mar 1 00:17:13.591: %SSH-5-ENABLED: SSH 1.99 has been enabled
KS(config)#

[/box]

4. To setup the key server, create a group (GDOI-VPN) and give it an identity number,all members of the group will share this number. It used the profile we created above, and will apply encryption based on ACL 123 (we will create in a minute). Finally it sets the IP that it will be used as the key servers (this is the IP in use on FastEthernet 0/0).

[box]

crypto gdoi group GDOI-DMVPN
identity number 999
server local
rekey retransmit 10 number 2
rekey authentication mypubkey rsa rsa
rekey transport unicast
sa ipsec 10
profile PF-GDOI
match address ipv4 123
replay counter window-size 64
address ipv4 5.5.5.2

EXAMPLE

KS(config)#crypto gdoi group GDOI-DMVPN
KS(config-gdoi-group)#identity number 999
KS(config-gdoi-group)#server local
KS(gdoi-local-server)# rekey retransmit 10 number 2
KS(gdoi-local-server)# rekey authentication mypubkey rsa rsa
KS(gdoi-local-server)# rekey transport unicast
KS(gdoi-local-server)# sa ipsec 10
KS(gdoi-sa-ipsec)# profile PF-GDOI
KS(gdoi-sa-ipsec)# match address ipv4 123
KS(gdoi-sa-ipsec)# replay counter window-size 64
KS(gdoi-sa-ipsec)# address ipv4 5.5.5.2
KS(gdoi-local-server)#

[/box]

5. Create the ACL we specified above, this ACL will get downloaded to all the group members. As will the VPN profile, they will then apply that profile to traffic defined in the ACL. It’s an ‘interesting traffic ACL, (if you are used to working with VPN’s).

[box]

access-list 123 permit gre any any

EXAMPLE

KS(config)#access-list 123 permit gre any any
KS(config)#

[/box]

Setup GDOI Group Members

Note: These settings are the same for the DMVPN hub router and all the spoke routers.

6. As above we specify a matching phase 1 policy.

[box]

crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0

EXAMPLE

Branch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#crypto isakmp policy 10
Branch1(config-isakmp)#encr aes
Branch1(config-isakmp)#authentication pre-share
Branch1(config-isakmp)#group 2
Branch1(config-isakmp)#crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0
Branch1(config)#

[/box]

7. Then join the router to the GDOI group.

[box]

crypto gdoi group GDOI-DMVPN
identity number 999
server address ipv4 5.5.5.2

EXAMPLE

Branch1(config)#crypto gdoi group GDOI-DMVPN
Branch1(config-gdoi-group)#identity number 999
Branch1(config-gdoi-group)#server address ipv4 5.5.5.2
Branch1(config-gdoi-group)#exit

[/box]

8. Then use that group to create a ‘crypto map’, and apply that map to the public interface that ‘faces outwards’. Note: Normally when applying encryption to DMVPN you would apply your crypto to the tunnel interface, with GDOI you do NOT.

[box]

crypto map CM-GDOI 10 gdoi
set group GDOI-DMVPN
interface FastEthernet0/0
crypto map CM-GDOI

EXAMPLE

Branch1(config)#crypto map CM-GDOI 10 gdoi
% NOTE: This new crypto map will remain disabled until a valid
group has been configured.
Branch1(config-crypto-map)#set group GDOI-DMVPN
Branch1(config-crypto-map)#interface FastEthernet0/0
Branch1(config-if)#crypto map CM-GDOI
*Mar 1 05:11:31.546: %CRYPTO-5-GM_REGSTER: Start registration to KS 5.5.5.2 for group GDOI-DMVPN using address 2.2.2.1
*Mar 1 05:11:31.582: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON

[/box]

9. Now I could add a route to my DMVPN network, with a static statement (i.e. ip route 192.168.0.0 0.0.255.255 Tunnel0), but I’m using EIGRP anyway, so I can just advertise the DMVPN network into my EIGRP group.

[box]

router eigrp 20
network 192.168.0.0

EXAMPLE

Branch1(config)#router eigrp 20
Branch1(config-router)#network 192.168.0.0
Branch1(config-router)#exit
Branch1(config)#

[/box]

Testing GDOI

[box]

Branch1#show crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: port 848
IKE SA: local 2.2.2.1/848 remote 5.5.5.2/848 Active
IPSEC FLOW: permit 47 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Branch1#

Branch1#show crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI-DMVPN
    Group Identity           : 999
    Rekeys received          : 0
    IPSec SA Direction       : Both
    Active Group Server      : 5.5.5.2
    Group Server list        : 5.5.5.2

    GM Reregisters in        : 2042 secs
    Rekey Received           : never


    Rekeys received
         Cumulative          : 0
         After registration  : 0

 ACL Downloaded From KS 5.5.5.2:
   access-list  permit gre any any

TEK POLICY for the current KS-Policy ACEs Downloaded:
  FastEthernet0/0:
    IPsec SA:
        spi: 0x93842CD3(2474912979)
        transform: esp-aes esp-sha-hmac
        sa timing:remaining key lifetime (sec): (2197)
        Anti-Replay : Disabled

[/box]

Complete GDOI with DMVPN Configs

Below I’ll show the configs, with the GDOI config highlighted in Red and the DMVPN config highlighted in blue.

[box]

GDOI Key Server Config

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname KS
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
!
no ip domain lookup
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS-GDOI esp-aes esp-sha-hmac 
!
crypto ipsec profile PF-GDOI
set transform-set TS-GDOI
!
crypto gdoi group GDOI-DMVPN
identity number 999
server local
rekey retransmit 10 number 2
rekey authentication mypubkey rsa rsa
rekey transport unicast
sa ipsec 10
profile PF-GDOI
match address ipv4 123
replay counter window-size 64
address ipv4 5.5.5.2
!
ip tcp synwait-time 5
!
interface FastEthernet0/0
ip address 5.5.5.2 255.255.255.252
speed auto
half-duplex
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 20
network 5.5.5.0 0.0.0.3
no auto-summary
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
access-list 123 permit gre any any
!
control-plane
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
login
!
end

[/box]

DMVPN Hub Server Config

[box]


version 12.4 
service timestamps debug datetime msec 
service timestamps log datetime msec 
no service password-encryption 
! 
hostname MainSiteRTR
! 
boot-start-marker 
boot-end-marker 
! 
no aaa new-model 
memory-size iomem 5 
no ip icmp rate-limit unreachable 
ip cef ! no ip domain lookup 
! 
multilink bundle-name authenticated 
! 
archive 
log config 
hidekeys 
! 
crypto isakmp policy 10 
encr aes 
authentication pre-share 
group 2 
crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0
 
!
crypto gdoi group GDOI-DMVPN 
identity number 999 
server address ipv4 5.5.5.2 
!
crypto map CM-GDOI 10 gdoi 
set group GDOI-DMVPN 
! 
ip tcp synwait-time 5 
!
interface Tunnel0 
ip address 192.168.0.1 255.255.255.0 
no ip redirects 
ip nhrp map multicast dynamic 
ip nhrp network-id 1 tunnel source 1.1.1.1 
tunnel mode gre multipoint 
! 
interface FastEthernet0/0 
ip address 172.16.1.1 255.255.0.0 
duplex auto 
speed auto 
! 
interface FastEthernet0/1 
ip address 1.1.1.1 255.255.255.252 
duplex auto 
speed auto 
crypto map CM-GDOI 
! 
interface FastEthernet1/0 
ip address 5.5.5.1 255.255.255.252 
duplex auto 
speed auto 
! 
router eigrp 20 
network 1.1.1.0 0.0.0.3 
network 5.5.5.0 0.0.0.3 
network 172.16.1.0 0.0.0.255 
network 192.168.0.0 
no auto-summary 
! 
ip forward-protocol nd 
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 
! 
no ip http server 
no ip http secure-server 
! 
no cdp log mismatch duplex 
! 
control-plane 
! 
line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line vty 0 4 
login 
! 
end 

Branch (Spoke) Routers 

version 12.4 
service timestamps debug datetime msec 
service timestamps log datetime msec 
no service password-encryption 
! 
hostname Branch1 
! 
boot-start-marker 
boot-end-marker 
! 
no aaa new-model
memory-size iomem 5 
no ip icmp rate-limit unreachable 
ip cef 
! 
no ip domain lookup 
! 
multilink bundle-name authenticated 
! 
archive log 
config hidekeys 
! 
 crypto isakmp policy 10 
encr aes 
authentication pre-share 
group 2 
crypto isakmp key P@ssword123 address 0.0.0.0 0.0.0.0 
!
 crypto gdoi group GDOI-DMVPN 
identity number 999 
server address ipv4 5.5.5.2 
!
 crypto map CM-GDOI 10 gdoi 
set group GDOI-DMVPN 
! 
ip tcp synwait-time 5 
!
 interface Tunnel0 ip address 192.168.0.2 255.255.255.0 
no ip redirects 
ip nhrp map 192.168.0.1 1.1.1.1 
ip nhrp map multicast 1.1.1.1 
ip nhrp network-id 1 
ip nhrp nhs 192.168.0.1 tunnel source 2.2.2.1 
tunnel mode gre multipoint 
! 
interface FastEthernet0/0 
ip address 2.2.2.1 255.255.255.252 
duplex auto 
speed auto 
crypto map CM-GDOI 
! 
interface FastEthernet0/1
ip address 172.17.1.1 255.255.0.0
duplex auto 
speed auto 
! 
router eigrp 20 
network 2.2.2.0 0.0.0.3 
network 172.17.0.0 
network 192.168.0.0
 no auto-summary 
! 
ip forward-protocol nd 
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 
! 
no ip http server 
no ip http secure-server 
! 
control-plane
! 
line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line vty 0 4 
login 
! 
end

[/box]

Related Articles, References, Credits, or External Links

Cisco – Configuring Dynamic Multipoint Virtual Private Networks DMVPN

Using OSPF over DMVPN

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

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

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

KB ID 0000216

Problem

Site to Site VPN’s either work faultlessly straight away, or involve head scratching and a call to Cisco TAC, or someone like me to come and take a look. If I’m honest, the simplest and best answer to the problem is “Remove the Tunnel from both ends and put it back again”. Just about every VPN tunnel I’ve put in that did not work, was a result of my fat fingers putting in the wrong subnet, IP address or shared secret.

However you can’t always remove the tunnel and start again, especially if you only have control of your end of the tunnel. In that case you need to do some troubleshooting and debugging.

Solution

To Troubleshoot and debug a VPN tunnel you need to have an appreciation of how VPN Tunnels work READ THIS.

Now you have read that you are an expert on IKE VPN Tunnels 🙂

 

Step 1

To bring up a VPN tunnel you need to generate some “Interesting Traffic” Start by attempting to send some traffic over the VPN tunnel.

Step 2 See if Phase 1 has completed.

Connect to the firewall and issue the following commands.

[box]

User Access Verification
Password: 
Type help or '?' for a list of available commands. 
PetesASA> enable 
Password: ******** 
PetesASA# show crypto isakmp

[/box]

You may see a lot more information if you have Existing VPN tunnels, but what you are looking for is this,

[box]

IKEv1 SAs:

   Active SA: 2
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2

1   IKE Peer: 123.123.123.123
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE <<YOUR SIDE BROUGHT THE VPN UP

There are no IKEv2 SAs

[/box]

If you see MM_ACTIVE (This means phase 1 has completed in Main Mode, and is active) So phase 1 has completed successfully, you need to jump forward and troubleshoot Phase 2.

Note: If you see AG_{something} this means you are trying to bring the tunnel up in aggressive mode!

If there is nothing listed at all – then your side is not even trying to bring up the tunnel. Try and generate a lot of VPN traffic – Like a persistent ping {ping 192.168.1.1 -t} and issue the show crypto isakmp command a few times to be sure. if you never see anything then its not getting as far as phase 1!

If your still reading this, then your problem is with Phase 1, and you have an ISAKMP SA state error.

ISAKMP SA MESSAGE STATES (On the Initiator)

MM_WAIT_MSG2

Message 1 has been sent to the responder but there has been no reply.

Causes:

1. There is no network connectivity to the firewallsecurity device at the other end, can you ping it?

2. The IP address of the far firewall is incorrect in the tunnel-group, issue a “show run tunnel-group” command, check you have a tunnel group with the correct IP address.

3. The IP address in the “Crypto Map” is incorrect, issue a “show run crypto map” command and check the line that ends “crypto map {name} {number} set peer xxx.xxx.xxx.xxx” to make sure.

4. You do not have a matching phase 1 policy with the other end, issue a “show run crypto isakmp” command make sure the other end has a matching policy, if you cant check the other end then generate some VPN traffic, issue the following command and check for the following,

[box]

 

EXAMPLE PHASE 1 POLICIES DONT MATCH

 

Password: Type help or ‘?’ for a list of available commands. PetesASA> en Password: ******** PetesASA#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]

MM_WAIT_MSG4

The Phase 1 Policies have been agreed with both peers, the initiator is waiting for the responder to send it its keying information. I’ve seen two things cause this.

1. Different Vendors equipment talking the the ASA, or simply the version of OS on the ASA have been different.

2. There is a comms error, check there’s no router with firewall capabilities in the link.

MM_WAIT_MSG6

If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.

Check your Pre-Shared Keys match on the ASA issue a “more system:running-config” then keep pressing the space bar till you see the tunnel- group and shared key

e.g.

tunnel-group 123.123.123.123 ipsec-attributes pre-shared-key this-is-the-pre-shared-key

Again if you can’t check the other end then issue the following debug and the following will tell you if there is a key mismatch.

This error can also be seen if one end has PFS set and the other end does not. In this case the error will appear and dissapear and the connection is repeatedly “torn down”

e.g

crypto map outside_map 20 set pfs [box]

 

EXAMPLE PHASE 1 PRE SHARED KEYS DONT MATCH

 

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

 

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

 

Apr 01 15:11:47 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=5456d64e) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56 Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Received an un-encrypted PAYLOAD_MALFORMED notify message, dropping Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Error, peer has indicated that something is wrong with our message. This could indicate a pre-shared key mismatch. Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Information Exchange processing failed

 

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

[/box]

ISAKMP SA MESSAGE STATES (On the Responder)

MM_WAIT_MSG3

The Phase 1 Policies have been agreed with both peers, the responder is waiting for the initiator to send it its keying information. I’ve seen two things cause this.

1. Different Vendors equipment talking the the ASA, or simply the version of OS on the ASA have been different.

2. There is a comms error, check there’s no router with firewall capabilities in the link.

3. I’ve seen this on a VPN from a VMware Edge Gateway, that had PFS (perfect forward secrecy) enabled, and the ASA did not.

Also see: Cisco ASA VPN to Cisco Router “MM_WAIT_MSG3”

MM_WAIT_MSG5

Make sure the Pre-Shared Keys Match

If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.

 

Here’s an Example of Phase one completing message by message successfully.

MESSAGE 1 (Leaving the Initiator)

[box]

 

Apr 01 11:38:51 [IKEv1]: IP = 123.123.123.123, IKE Initiator: New Phase 1, Intf inside, IKE Peer 123.123.123.123 local Proxy Address 192.168.1.0, remote Proxy Address 172.16.1.0, Crypto map (outside_map) Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing ISAKMP SA payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver 02 payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver 03 payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver RFC payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing Fragmentation VID + extended capabilities payload Apr 01 11:38:51 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 168

[/box]

MESSAGE 2 (Arriving at the Responder)

[box]

Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 117
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing SA payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Oakley proposal is acceptable
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing ke payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing nonce payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing Cisco Unity VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing xauth V6 VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Send IOS VID
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

[/box]

MESSAGE 3 (Leaving the Initiator)

[box]

Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 256

[/box]

MESSAGE 4 (Arriving at the Initiator)

[box]

Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + NONE (0) total length : 228
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing ke payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing ISA_KE payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing nonce payload

[/box]

MESSAGE 5 (Leaving the Initiator)

[box]

Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Generating keys for Initiator...
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing ID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing hash payload
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Computing hash for ISAKMP
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing dpd vid payload
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 84

[/box]

MESSAGE 6 (Arriving at the Initiator)

[box]

Apr 01 11:38:53 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + NONE (0) total length : 64
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, processing ID payload
Apr 01 11:38:53 [IKEv1 DECODE]: Group = 123.123.123.123, IP = 123.123.123.123, ID_IPV4_ADDR ID received 123.123.123.123
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, processing hash payload
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Computing hash for ISAKMP
Apr 01 11:38:53 [IKEv1]: IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Oakley begin quick mode
Apr 01 11:38:53 [IKEv1 DECODE]: Group = 123.123.123.123, IP = 123.123.123.123, IKE Initiator starting QM: msg id = 26f952ae
Apr 01 11:38:53 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, PHASE 1 COMPLETED

[/box]

Note: You can debug Phase 1 traffic on a particular tunnel, with the following command.

debug crypto condition peer 123.123.123.123

or, simply;

debug crypto isakmp

Phase 1 Debug Errors

[box]

Petes-ASA((config)# debug crypto isakmp
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, QM FSM error (P2 struct &0x00007fda92308b10, mess id 0xc02b7a5d)!
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Removing peer from correlator table failed, no match!
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Session is being torn down. Reason: crypto map policy not found

[/box]

This was due to more than one misconfiguration, firstly the source and destination network objects in the interesting traffic ACL were the wrong way round! (Don’t forget to check your static NAT statement as well). And the TRANSFORM SET didn’t match, (sometimes you can see phase one established but then it disappears).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[box]

Petes-ASA((config)# debug crypto ikev1
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, No Group found by matching OU(s) from ID payload:   Unknown
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Trying to find group via IKE ID...
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Trying to find group via IP ADDR...
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, peer ID type 2 received (FQDN)
Apr 19 16:36:10 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Unable to compare IKE ID against peer cert Subject Alt Name
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, IKE MM Responder FSM error history (struct &0x00007ffd9e230670)  <state>, <event>:  MM_DONE, EV_ERROR-->MM_BLD_MSG6, EV_COMPARE_IDS-->MM_BLD_MSG6, EV_CERT_OK-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_ACTIVATE_NEW_SA-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_VALIDATE_CERT-->MM_BLD_MSG6, EV_UPDATE_CERT
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, IKE SA MM:3a1ed893 terminating:  flags 0x01018002, refcnt 0, tuncnt 0
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, sending delete/delete with reason message

[/box]

The ASA did not like the certificate presented by the remote peer, (Even though is was a good cert issued by NDES). To get past this you need to make a change to the tunnel group.

[box]

Petes-ASA(config)# tunnel-group TG-TUNNEL-HQ ipsec-attributes
Petes-ASA(config-ipsec)# peer-id-validate nocheck

[/box]

Or if you prefer the ASDM;

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[box]

Petes-ASA((config)# debug crypto ikev1
%ASA-3-717009: Certificate validation failed. Peer certificate key usage is invalid, serial number: 6B00002B3F8571E2605FA02883000100002C3E, subject name: hostname=Petes-Router-Petes-HQ.petenetlive.com.
%ASA-3-717027: Certificate chain failed validation. Certificate chain is either invalid or not authorized.

[/box]

The ASA did not like the certificate presented by the remote peer, (Even though is was a good cert issued by NDES). To get past this you need to make a change to the trustpoint on the ASA.

[box]

Petes-ASA(config)# crypto ca trustpoint PNL-Trustpoint
Petes-ASA(config-ca-trustpoint)# ignore-ipsec-keyusage 

[/box]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[box]

Petes-ASA# debug crypto ikev1
Petes-ASA# Feb 17 12:25:17 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Received encrypted Oakley Main Mode packet with invalid payloads, MessID = 0
Feb 17 12:25:17 [IKEv1]Group = 212.20.251.44, IP = 123.123.123.123, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Feb 17 12:25:23 [IKEv1]IP = 123.123.123.123, Header invalid, missing SA payload! (next payload = 4)
\

[/box]

Amazingly this had nothing to do with a mismatched pre shared key, the other end was set to use PFS (Perfect Forward Secrecy,) and my end (the ASA) was not.

If you have got this far the next step is to troubleshoot Phase 2

Related Articles, References, Credits, or External Links

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

Thanks To SteveH for the Certificate Phase 1 Error details.

VPN Error – ‘CRYPTO-4-RECVD_PKT_NOT_IPSEC’

KB ID 0000936 

Problem

While setting up a simple site to site to site VPN, I was unable to get ISAKMP phase 1 to establish. When I had a look on the device at the far end. I saw this error logged in the console, every time I tried to bring up the tunnel.

[box]

*Mar 1 00:21:42.811: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /192.168.2.3, src_addr= 192.168.1.2, prot= 1

[/box]

Solution

After about 40 minutes of staring at the configs, I realised I’d applied the crypto-map (on the router I was trying to bring the tunnel up from), to the inside interface and not the outside one – Doh!

Related Articles, References, Credits, or External Links

NA

Cisco ASA to Juniper SRX Site to Site VPN

KB ID 0000710

Problem

You want to establish a site to site VPN from a site with a Cisco ASA firewall, to another site running a Juniper SRX firewall. I had to do this this week, and struggled to find any good information to help.

In the example below I’m configuring the whole thing from a laptop (172.16.254.206) that’s on the Juniper’s site. Use the diagram below, and substitute your own IP addresses and subnet addresses, to get a workable solution for your site.

When the process is complete, I will test it by pinging the host behind the Cisco ASA on the remote site (10.254.254.5).

Solution

Before you begin, I will assume both firewalls are functioning properly and the clients behind them can access internet services (where allowed) through them already.

Step 1 – Configure the ASA

Model used Cisco ASA 5505 v8.4 (ASDM 6.4)

1. Connect to the ASDM > Wizards > VPN Wizards > Site-to-site VPN Wizard.

2. Next.

3. Enter the public IP address of the Juniper Firewall > Next, (Note: I’m assuming the VPN is terminated on the outside interface, if not change it).

4. IKE version 1 > Next.

5. Enter the Local (behind the ASA) network > Then the Remote (behind the Juniper) network > Next.

Note: You can type them in, but if you use the pick-list button you can select ‘inside-network’ for the local, and define a network object for the remote network.

6. Enter a pre shared key, (remember this, you need to enter it on the Juniper).

7. Accept the default of 3DES and SHA1 > Next.

8. Enable PFS > Tick the box to exempt traffic from NAT > Next.

9. Review the settings > Finish

11. Save the changes > File > Save running Configuration to Flash.

Step 2 – Configure the Juniper SRX (Route Based VPN)

Model used SRX100B version 11.2R4.3

The SRX support two types of VPN

  1. Route based VPN – VPN selection is done based on the route. In this you define a route pointing to the tunnel interface (st0 interface) bound to the VPN.
  2. Policy based VPN – VPN is selected based on the policy.

12. Log onto the Juniper Web Device Manager.

13. Tasks > Configure VPN > Launch VPN Wizard.

14. Accept the default of Site-to-site > Start.

15. Give the tunnel a name > Set the local zone to trust > Add in the local subnet (behind the Juniper) > Name the Secure Tunnel Interface (just put in a zero) > Set the secure tunnel zone to Untrust > Enter the physical address the VPN will be terminating on, (usually the fe0/0/0.0 interface, but it does not have to be) > Next.

Note: On the Juniper, when specifying a subnet use the short subnet notation, i.e. 192.168.1.0 255.255.255.0 would be 192.168.1.0/24 (if you get stuck use my subnet calculator).

16. Supply the public IP address of the ASA > and add in the subnet at the far end of the tunnel (behind the ASA) > Next.

17. Set the IKE (phase 1) settings to Compatible, Main Mode, enter the same pre shared key you setup in Step 1 (number 6) > Set the IPSEC (phase 2) settings to Compatible, IPsec Perfect Forward Secrecy (PFS) to group 2 > Next.

18. Accept the defaults > Next.

19. Review the settings > Commit.

Step 3 – Additional Steps required (for Cisco ASA)

20. Navigate to IPsec VPN > Auto Tunnel > Phase II > Select your tunnel > Edit > IPsec VPN Options > Tick ‘use proxy identity’ > Enter the local and remote subnets > OK.

21. Navigate to Security > Zones/Screen > Select the untrust zone > Edit > Host Inbound traffic – Interface > Select the physical address that the VPN is terminating on (usually fe-0/0/0.0) > Add IKE as an Interface service > OK.

22. To save the changes > Action > Commit.

23. Test the VPN by attempting to ping a host on the other end.

Juniper SRX Command Line

On the Cisco firewalls I prefer to work at command line. The Juniper Firewall also supports CLI, you can check the VPN config with the following commands;

If you want you can execute the below commands on CLI to get the “set” commands

            show security ike | display set
            show security ipsec | display set
            show | display set | match <external interface configured in ike>
            show | display set | match <st.x>

Above  commands will give you the “set” commands for cli.

Related Articles, References, Credits, or External Links

Special thanks to Kalanidhi Tripathi at JTAC for his assistance.

Juniper KB Articles

 

SRX Getting Started – Configure VPN tunnel for site-to-site connectivity

How to configure IPSec VPN on a J Series or SRX Series device

 

Cisco ASA 5500 – VPN Works in One Direction

KB ID 0000759

Problem

The title of this article can cover a multitude of possible causes, however I recently had a strange problem where a client with a remote site protected by an ASA5505 had a VPN tunnel connected to their main site which had an ASA5510. The tunnel established at phase 1, and phase 2, the main site could talk to the remote site, but the remote site refused to talk back to the main site.

Update 23/04/19: Seen again this time, the ASA at the ‘problem end’ had a static route pointing 10.0.0.0/8 internally, but VPN traffic needed to get to 10.4.0.0/24 at the other end of the VPN tunnel, so traffic was reputed back into the LAN again and dropped.

Update 13/08/14: Seen again, this time from ASA at the problem end, I could ‘ping inside {IP at the remote site}’ and get a response, and the tunnel established. But internal clients could not send traffic over the VPN.

Solution

Usually if you can only “Establish” a tunnel from one side, and it still works, the culprit is normally that PFS has only been specified at one end of the tunnel. On both ends issue a ‘show run crypto map’ command and make sure both ends either use PFS or do not use PFS.

[box]

crypto map outside_map 1 match address outside_1_cryptomap
 crypto map outside_map 1 set pfs
 crypto map outside_map 1 set peer 123.123.123.123 
 crypto map outside_map 1 set ikev1 transform-set ESP-3DES-SHA[/box]

However in this case there was a ‘Rogue NAT entry’ on the ASA5505, that looks like a throwback from an OS upgrade.

[box]

 nat (inside,outside) source static LocalSN LocalSN destination static Site1SN Site1SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site2SN Site2SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site3SN Site3SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site4SN Site4SN
 nat (inside,outside) source dynamic any interface
 nat (inside,outside) source static LocalSN LocalSN destination static Site5SN Site5SN
 !
 object network OBJ-NAT-ALL
 subnet 0.0.0.0 0.0.0.0 
 nat (inside,outside) dynamic interface [/box]


Note
: The line in red should not have been there. The last three lines are all you need (Note: your object may be called obj_any).

You can see why it’s causing a problem if you do a packet-trace on some traffic, (see the two examples below).

Packet-Tracer Results (Misconfigured)

[box]

PetesASA# packet-tracer input inside icmp 192.168.2.2 8 0 192.168.1.1

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: input
 Result: ALLOW
 Config:
 Additional Information:
 in 0.0.0.0 0.0.0.0 outside

Phase: 2
 Type: ACCESS-LIST
 Subtype: log
 Result: ALLOW
 Config:
 access-group inside_access_in in interface inside
 access-list inside_access_in extended permit ip any any
 Additional Information:

Phase: 3
 Type: CONN-SETTINGS
 Subtype:
 Result: ALLOW
 Config:
 class-map class-default
 match any
 policy-map global_policy
 class class-default
 set connection decrement-ttl
 service-policy global_policy global
 Additional Information:

Phase: 4
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 nat (inside,outside) source dynamic any interface <Problem!
 Additional Information:
 Dynamic translate 192.168.2.2/0 to 123.123.123.123/21205 <Problem!

Phase: 5
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 6
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 8
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 9
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (inside,outside) source dynamic any interface <Problem!
 Additional Information:

Phase: 10
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 11
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 12
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 32065, packet dispatched to next module

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: outside
 output-status: up
 output-line-status: up
 Action: allow

[/box]

Packet-Tracer Results (Configured Correctly)

[box]

PetesASA# packet-tracer input inside icmp 192.168.2.2 8 0 192.168.1.1

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: input
 Result: ALLOW
 Config:
 Additional Information:
 in 0.0.0.0 0.0.0.0 outside

Phase: 2
 Type: UN-NAT
 Subtype: static
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup < That's Better!
 Additional Information:
 NAT divert to egress interface outside
 Untranslate 192.168.1.1/0 to 192.168.1.1/0  < That's Better!

Phase: 3
 Type: ACCESS-LIST
 Subtype: log
 Result: ALLOW
 Config:
 access-group inside_access_in in interface inside
 access-list inside_access_in extended permit ip any any
 Additional Information:

Phase: 4
 Type: CONN-SETTINGS
 Subtype:
 Result: ALLOW
 Config:
 class-map class-default
 match any
 policy-map global_policy
 class class-default
 set connection decrement-ttl
 service-policy global_policy global
 Additional Information:

Phase: 5
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup < That's Better!
 Additional Information:
 Static translate 192.168.2.2/0 to 192.168.2.2/0 < That's Better!

Phase: 6
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 8
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 9
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 10
 Type: VPN
 Subtype: encrypt
 Result: ALLOW
 Config:
 Additional Information:

Phase: 11
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup  < That's Better!
 Additional Information:

Phase: 12
 Type: VPN
 Subtype: ipsec-tunnel-flow
 Result: ALLOW
 Config:
 Additional Information:

Phase: 13
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 14
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 15
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 33263, packet dispatched to next module

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: outside
 output-status: up
 output-line-status: up
 Action: allow

[/box]

Related Articles, References, Credits, or External Links

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

Original Article Written 05/02/13