Home › Security › Cisco Security › Config example: Vanilla static ipsec vpn with crypto map

Config example: Vanilla static ipsec vpn with crypto map

Posted on by jimmy

(Topology here)

This is the far most common implementation of IPSEC Lan2Lan (at least in my world). It uses static crypto-maps applied to outbound interface of each router. A proxy-acl defines interresting traffic, authentication is done with a pre-shared key and it uses isakmp main-mode for setting up the tunnel.

Ok. First thing first. Make sure that the peer router is reachable before doing anything else:


r1#ping 10.10.30.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.30.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great. Now for the config. Start with r1. What traffic need to be protected? Create the crypto acl.

ip access-list extended acl_vpn
permit ip host 192.168.1.50 host 10.3.3.3

Next. Create an isakmp policy defining the parameters for phase 1.

crypto isakmp policy 10
encr aes
authentication pre-share
group 5

For phase 1 we also need to set the pre-shared key.

crypto isakmp key cisco address 10.10.30.3

For phase 2 we need to create an ipsec transform-set.

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

Now this needs to be put together in a crypto map.

crypto map CMAP 10 ipsec-isakmp
set peer 10.10.30.3
set transform-set TSET
match address acl_vpn

Last step is to assign this crypto-map to the outside interface.

interface FastEthernet0.11
crypto map CMAP

On the other router the exact thing needs to be defined, except for the crypto access-list that of course must be mirrored because of the reverse point of view. Also the peer ip must be the correct one. Here is the config for r3 with modifications from above highlighted.

ip access-list extended acl_vpn
permit ip host 10.3.3.3 host 192.168.1.50
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key cisco address 10.10.11.1
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
crypto map CMAP 10 ipsec-isakmp
set peer 10.10.11.1
match address acl_vpn
reverse-route static
crypto map CMAP
interface FastEthernet0.30
crypto map CMAP

In this example there is only one thing left to do: make sure that there are routes for the remote-end network. In my daily work I´ve setup lots of tunnels like this. It´s almost always the same: the router (or firewall) is connected to internet on outside with a default-route to the isp. But what if there is no default route? In my XXXXXXXXXXXXXXXXXXXXXXtopology the isn´t. Look:


r1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.10.10.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.2.2.2/32 [170/1285120] via 10.10.10.1, 17:32:22, FastEthernet0.10
C 10.10.10.0/24 is directly connected, FastEthernet0.10
C 10.10.11.0/24 is directly connected, FastEthernet0.11
C 10.1.1.1/32 is directly connected, Loopback0
S 10.10.30.3/32 [1/0] via 10.10.11.2
D EX 192.168.1.0/24 [170/1285120] via 10.10.10.1, 17:32:22, FastEthernet0.10
D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 17:32:23, FastEthernet0.10

r3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.3.3.3/32 is directly connected, Loopback0
S 10.10.11.1/32 [1/0] via 10.10.30.1
C 10.10.30.0/24 is directly connected, FastEthernet0.30
r3#

As you can see r1 has no route for 10.3.3.3 but only a default-route pointing in the wrong direction. R3 has no default-route at all, and certanly not a route for 192.168.1.50.

That means that even thou the vpn-peers have connectivity to establish a VPN-tunnel AND there is a definition of crypto traffic in the acl bound to the crypto map on outside interface the router is not clever enough to understand to send it that way. The route is not in the routing table. So, we need to add that. The cheapest way to do it is with static routes:

r1:

ip route 10.10.30.3 255.255.255.255 10.10.11.2

r3:

ip route 10.10.11.1 255.255.255.255 10.10.30.1

Now we are good to go. Lets ping 10.3.3.3 from our 192.168.1.50-host:


C:>ping 10.3.3.3

Skickar ping-signal till 10.3.3.3 med 32 byte data:
Svar från 10.3.3.3: byte=32 tid=2ms TTL=254
Svar från 10.3.3.3: byte=32 tid=2ms TTL=254
Svar från 10.3.3.3: byte=32 tid=2ms TTL=254
Svar från 10.3.3.3: byte=32 tid=2ms TTL=254

Ping-statistik för 10.3.3.3:
Paket: Skickade = 4, Mottagna = 4, Förlorade = 0 (0 %),
Ungefärlig överföringstid i millisekunder:
Lägsta = 2 ms, Högsta = 2 ms, Medel = 2 ms

C:>

(I apologize for the swedish OS 🙂 )

But what if we are not allowed to use static routes. In real world noone would ever care but remember that in CCIE lab they will often throw a “and besides, you are not allowed to do it the easy way!” at you.

One solution could be to make the crypto map to insert a route for the remote networks into the local routing table. By doing that we can later on modify our crypto access-list without the need to care about static routes. Let´s do it!


r1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r1(config)#no ip route 10.3.3.3 255.255.255.255 10.10.11.2
r1(config)#crypto map CMAP 10 ipsec-isakmp
r1(config-crypto-map)#reverse-route static
This will remove previously installed VPN routes and SAs
r1(config-crypto-map)#
r1#
r3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r3(config)#no ip route 192.168.1.50 255.255.255.255 10.10.30.1
r3(config)#crypto map CMAP 10 ipsec-isakmp
r3(config-crypto-map)#reverse-route static
r3#

The magic is that, in each router, a static route has appeared in the routing-table without a corresponding static route in the config:


r1#sh ip route 10.3.3.3
Routing entry for 10.3.3.3/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.10.30.3
Route metric is 0, traffic share count is 1

r1#sh run | incl ip route
ip route 10.10.30.3 255.255.255.255 10.10.11.2
r1#

So. What is happening on the wire? First we see the ISAKMP-negotiation and then the encrypted ESP-traffic. Here, the output from wireshark placed in-transit between r1 and r3:


No. Time Source Destination Protocol Info
1 2010-03-19 07:44:28.799137 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
2 2010-03-19 07:44:28.805942 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
3 2010-03-19 07:44:28.810611 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
4 2010-03-19 07:44:28.911985 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
5 2010-03-19 07:44:29.022719 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode)
6 2010-03-19 07:44:29.027372 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode)
7 2010-03-19 07:44:29.032072 10.10.11.1 10.10.30.3 ISAKMP Quick Mode
8 2010-03-19 07:44:29.037702 10.10.30.3 10.10.11.1 ISAKMP Quick Mode
9 2010-03-19 07:44:29.042142 10.10.11.1 10.10.30.3 ISAKMP Quick Mode
10 2010-03-19 07:44:33.532046 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd)
11 2010-03-19 07:44:33.533282 10.10.30.3 10.10.11.1 ESP ESP (SPI=0x43fe1aba)
12 2010-03-19 07:44:34.533694 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd)
..
..

A key to success in configuring VPN is to interprete the debug output. The most common debug-commands are “debug crypto isakmp” and “deb crypto ipsec”. But the output is massive and it takes some exercise to learn to read it. Here is the output from r1 in our example above when establishing the VPN. Let´s see what happens:

r1#clear crypto session
r1#deb crypto isakmp
Crypto ISAKMP debugging is on
r1#deb crypto ipsec
Crypto IPSEC debugging is on
r1#
r1#
*Mar 19 08:50:47.623: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 10.10.11.1, remote= 10.10.30.3,
local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1),
remote_proxy= 10.3.3.3/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0

Above we see that our ping triggered a request to setup a VPN (

*Mar 19 08:50:47.623: ISAKMP:(0): SA request profile is (NULL)
*Mar 19 08:50:47.623: ISAKMP: Created a peer struct for 10.10.30.3, peer port 500
*Mar 19 08:50:47.623: ISAKMP: New peer created peer = 0x840A5978 peer_handle = 0x80000008
*Mar 19 08:50:47.623: ISAKMP: Locking peer struct 0x840A5978, refcount 1 for isakmp_initiator
*Mar 19 08:50:47.623: ISAKMP: local port 500, remote port 500
*Mar 19 08:50:47.623: ISAKMP: set new node 0 to QM_IDLE
*Mar 19 08:50:47.623: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 8515F140
*Mar 19 08:50:47.623: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
*Mar 19 08:50:47.623: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-03 ID
*Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-02 ID
*Mar 19 08:50:47.623: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
*Mar 19 08:50:47.623: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1
Going into the next state…IKE_I_MM1 is “we are sending main mode msg 1”
*Mar 19 08:50:47.623: ISAKMP:(0): beginning Main Mode exchange
*Mar 19 08:50:47.623: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_NO_STATE
*Mar 19 08:50:47.623: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.627: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_NO_STATE
*Mar 19 08:50:47.627: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.627: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2
Going into the next state…IKE_I_MM2 means “we got a reply on our first message”
*Mar 19 08:50:47.627: ISAKMP:(0): processing SA payload. message ID = 0
*Mar 19 08:50:47.627: ISAKMP:(0): processing vendor id payload
*Mar 19 08:50:47.627: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Mar 19 08:50:47.627: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Mar 19 08:50:47.627: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3
We have a pre-shared key configured for remote peer. That´s good…
*Mar 19 08:50:47.627: ISAKMP:(0): local preshared key found
*Mar 19 08:50:47.627: ISAKMP : Scanning profiles for xauth ...
*Mar 19 08:50:47.627: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
*Mar 19 08:50:47.627: ISAKMP: encryption AES-CBC
*Mar 19 08:50:47.627: ISAKMP: keylength of 128
*Mar 19 08:50:47.627: ISAKMP: hash SHA
*Mar 19 08:50:47.631: ISAKMP: default group 5
*Mar 19 08:50:47.631: ISAKMP: auth pre-share
*Mar 19 08:50:47.631: ISAKMP: life type in seconds
*Mar 19 08:50:47.631: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Mar 19 08:50:47.631: ISAKMP:(0):atts are acceptable. Next payload is 0
We have match on ISAKMP policies. This example is simple since both peers has only one isakmp policy defined so the first try is a match. Remember, both peers try to find a match among all their localy configured isakmp policies and their buddies. In more complex configurations or when dealing with vpn-clients it´s not uncommon to see tenths of policies from each end. Then the previous lines will be repeated for all attempts.
*Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:actual life: 0
*Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:life: 0
*Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa vpi_length:4
*Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Mar 19 08:50:47.631: ISAKMP:(0):Returning Actual lifetime: 86400
*Mar 19 08:50:47.631: ISAKMP:(0)::Started lifetime timer: 86400.
*Mar 19 08:50:47.631: ISAKMP:(0): processing vendor id payload
*Mar 19 08:50:47.631: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Mar 19 08:50:47.631: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2
*Mar 19 08:50:47.631: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_SA_SETUP
*Mar 19 08:50:47.631: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3
Ok. IKE_I_MM3 means that we send the third packet (our second as a sender)

*Mar 19 08:50:47.731: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_SA_SETUP
*Mar 19 08:50:47.731: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.731: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4
And we got a reply. The fourth packet in the 6-packet main-mode flow

*Mar 19 08:50:47.731: ISAKMP:(0): processing KE payload. message ID = 0
*Mar 19 08:50:47.827: ISAKMP:(0): processing NONCE payload. message ID = 0
*Mar 19 08:50:47.827: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3
*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload
*Mar 19 08:50:47.827: ISAKMP:(2007): vendor ID is Unity
*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload
*Mar 19 08:50:47.827: ISAKMP:(2007): vendor ID is DPD
*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload
*Mar 19 08:50:47.827: ISAKMP:(2007): speaking to another IOS box!
*Mar 19 08:50:47.827: ISAKMP:received payload type 20
*Mar 19 08:50:47.827: ISAKMP (2007): His hash no match - this node outside NAT
*Mar 19 08:50:47.827: ISAKMP:received payload type 20
*Mar 19 08:50:47.827: ISAKMP (2007): No NAT Found for self or peer
*Mar 19 08:50:47.827: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Mar 19 08:50:47.827: ISAKMP:(2007):Old State = IKE_I_MM4 New State = IKE_I_MM4

*Mar 19 08:50:47.827: ISAKMP:(2007):Send initial contact
*Mar 19 08:50:47.827: ISAKMP:(2007):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
*Mar 19 08:50:47.827: ISAKMP (2007): ID payload
next-payload : 8
type : 1
address : 10.10.11.1
protocol : 17
port : 500
length : 12
*Mar 19 08:50:47.827: ISAKMP:(2007):Total payload length: 12
*Mar 19 08:50:47.827: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_KEY_EXCH
*Mar 19 08:50:47.827: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.827: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.827: ISAKMP:(2007):Old State = IKE_I_MM4 New State = IKE_I_MM5
So. the fifth packet is where we send our pre-shared key
*Mar 19 08:50:47.831: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Mar 19 08:50:47.831: ISAKMP:(2007): processing ID payload. message ID = 0
*Mar 19 08:50:47.831: ISAKMP (2007): ID payload
next-payload : 8
type : 1
address : 10.10.30.3
protocol : 17
port : 500
length : 12
*Mar 19 08:50:47.831: ISAKMP:(0):: peer matches *none* of the profiles
*Mar 19 08:50:47.831: ISAKMP:(2007): processing HASH payload. message ID = 0
*Mar 19 08:50:47.831: ISAKMP:(2007):SA authentication status:
authenticated
*Mar 19 08:50:47.831: ISAKMP:(2007):SA has been authenticated with 10.10.30.3
*Mar 19 08:50:47.831: ISAKMP: Trying to insert a peer 10.10.11.1/10.10.30.3/500/, and inserted successfully 840A5978.
*Mar 19 08:50:47.831: ISAKMP:(2007):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Mar 19 08:50:47.831: ISAKMP:(2007):Old State = IKE_I_MM5 New State = IKE_I_MM6
We got a reply, the sixth (and last) packet of Main mode phase 1

*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_I_MM6
*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE
So. Phase 1 is completed.
*Mar 19 08:50:47.835: ISAKMP:(2007):beginning Quick Mode exchange, M-ID of -1445410418
Quick mode = Phase 1
*Mar 19 08:50:47.835: ISAKMP:(2007):QM Initiator gets spi
*Mar 19 08:50:47.835: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLE
*Mar 19 08:50:47.835: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.835: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
IKE_QM_I_QM1 means that we´ve sent our first phase 2 packet
*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

*Mar 19 08:50:47.843: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) QM_IDLE
We got an answer. The reply is the second of three packets in phase 2. The content of this received packet is SA-data for ipsec SA:s. Which traffic to protect (proxies), encryption parameters and so on. What happens next is that this information is compared to our local configuration to make sure that it matches. Then the SA:s are being setup…

*Mar 19 08:50:47.843: ISAKMP:(2007): processing HASH payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing SA payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007):Checking IPSec proposal 1
*Mar 19 08:50:47.843: ISAKMP: transform 1, ESP_AES
*Mar 19 08:50:47.843: ISAKMP: attributes in transform:
*Mar 19 08:50:47.843: ISAKMP: encaps is 1 (Tunnel)
*Mar 19 08:50:47.843: ISAKMP: SA life type in seconds
*Mar 19 08:50:47.843: ISAKMP: SA life duration (basic) of 3600
*Mar 19 08:50:47.843: ISAKMP: SA life type in kilobytes
*Mar 19 08:50:47.843: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
*Mar 19 08:50:47.843: ISAKMP: authenticator is HMAC-SHA
*Mar 19 08:50:47.843: ISAKMP: key length is 128
*Mar 19 08:50:47.843: ISAKMP:(2007):atts are acceptable.
*Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1
*Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 10.10.11.1, remote= 10.10.30.3,
local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1),
remote_proxy= 10.3.3.3/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
 spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Mar 19 08:50:47.843: Crypto mapdb : proxy_match
src addr : 192.168.1.50
dst addr : 10.3.3.3
protocol : 0
src port : 0
dst port : 0
*Mar 19 08:50:47.843: ISAKMP:(2007): processing NONCE payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418
*Mar 19 08:50:47.843: ISAKMP:(2007): Creating IPSec SAs
*Mar 19 08:50:47.843: inbound SA from 10.10.30.3 to 10.10.11.1 (f/i) 0/ 0
(proxy 10.3.3.3 to 192.168.1.50)
*Mar 19 08:50:47.843: has spi 0xCB15AC0E and conn_id 0
*Mar 19 08:50:47.843: lifetime of 3600 seconds
*Mar 19 08:50:47.843: lifetime of 4608000 kilobytes
*Mar 19 08:50:47.843: outbound SA from 10.10.11.1 to 10.10.30.3 (f/i) 0/0
(proxy 192.168.1.50 to 10.3.3.3)
*Mar 19 08:50:47.843: has spi 0xBA3D8C69 and conn_id 0
*Mar 19 08:50:47.843: lifetime of 3600 seconds
*Mar 19 08:50:47.847: lifetime of 4608000 kilobytes
*Mar 19 08:50:47.847: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLE
We send our third and last packet in phase 2 packet exchange…
*Mar 19 08:50:47.847: ISAKMP:(2007):Sending an IKE IPv4 Packet.
*Mar 19 08:50:47.847: ISAKMP:(2007):deleting node -1445410418 error FALSE reason "No Error"
*Mar 19 08:50:47.847: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Mar 19 08:50:47.847: ISAKMP:(2007):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE
*Mar 19 08:50:47.847: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Mar 19 08:50:47.847: Crypto mapdb : proxy_match
src addr : 192.168.1.50
dst addr : 10.3.3.3
protocol : 0
src port : 0
dst port : 0
*Mar 19 08:50:47.847: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 10.10.30.3
*Mar 19 08:50:47.847: IPSEC(rte_mgr): VPN Route Event static keyword or dynamic SA create for 10.10.30.3
*Mar 19 08:50:47.847: IPSEC(policy_db_add_ident): src 192.168.1.50, dest 10.3.3.3, dest_port 0

*Mar 19 08:50:47.847: IPSEC(create_sa): sa created,
(sa) sa_dest= 10.10.11.1, sa_proto= 50,
sa_spi= 0xCB15AC0E(3407195150),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 59
sa_lifetime(k/sec)= (4453107/3600)
*Mar 19 08:50:47.847: IPSEC(create_sa): sa created,
(sa) sa_dest= 10.10.30.3, sa_proto= 50,
sa_spi= 0xBA3D8C69(3124595817),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 60
sa_lifetime(k/sec)= (4453107/3600)
*Mar 19 08:50:47.847: IPSEC(update_current_outbound_sa): updated peer 10.10.30.3 current outbound sa to SPI BA3D8C69
*Mar 19 08:50:48.027: ISAKMP:(2006):purging SA., sa=8515E77C, delme=8515E77C
r1#

Voila!

And just to make sure all looks good let´s check our SA:s:


r1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.10.30.3 10.10.11.1 QM_IDLE 2007 ACTIVE
r1#
As you can see there is one isakmp SA created. State QM_IDLE is good, it means that all is fine in isakmp/phase 1
r1#sh crypto ipsec sa

interface: FastEthernet0.11
Crypto map tag: CMAP, local addr 10.10.11.1

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

local crypto endpt.: 10.10.11.1, remote crypto endpt.: 10.10.30.3
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0.11
current outbound spi: 0xBA3D8C69(3124595817)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xCB15AC0E(3407195150)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 59, flow_id: Onboard VPN:59, sibling_flags 80000046, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4453106/1047)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xBA3D8C69(3124595817)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 60, flow_id: Onboard VPN:60, sibling_flags 80000046, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4453106/1047)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:
r1#
 There are 2 ipsec SA:s established. One in each direction. That´s just the way it is. Looking at the number of encaps/decaps packets gives us a hint that we are both sending traffic and receiving traffic thru the tunnel.

That´s all for now. This was a massive post. I will use this exampel as a template for the next VPN configurations so hopefully they will not be as massive as this. 😉

Please feel free to comment if there is anything I´ve missed or if I got something the wrong way…

Configs for r1 and r3 here…

Tagged with: ,
Posted in Cisco Security

Signuppp

[mc4wp_form id="2457"]
Website Security Test