nat0 » VPN

Cisco Anyconnect for Iphone!

Jimmy Larsson — Tue, 21 Sep 2010 13:27:53 +0000

For those of you that haven´t heard – Cisco Anyconnect VPN client for Iphone is finally released!

/Jimmy

EzVPN Server on IOS in three different flavous

Jimmy Larsson — Thu, 13 May 2010 20:06:16 +0000

Comparizon between 3 different ways to configure EzVPN on IOS.

Example 1: EzVPN-server vanilla-style

aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! username cisco password 0 cisco ! ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto dynamic-map DYNMAP 10 set transform-set TSET reverse-route ! ! crypto map CMAP client authentication list AAA-AUTHEN crypto map CMAP isakmp authorization list AAA-AUTHOR crypto map CMAP client configuration address respond crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! interface GigabitEthernet0/1 crypto map CMAP ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any ! !

Example 2: Vanilla-style with ISAKMP profile on top

aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto dynamic-map DYNMAP 10 set transform-set TSET set isakmp-profile ISAKMP-PROFILE reverse-route ! ! crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! ! interface GigabitEthernet0/1 crypto map CMAP ! ip local pool LOCALPOOL 8.9.24.201 8.9.24.254 ! ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any ! !

Differences between Example 1 and Example 2:
crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond ! crypto dynamic-map DYNMAP 10 set isakmp-profile ISAKMP-PROFILE ! crypto map CMAP client authentication list AAA-AUTHEN crypto map CMAP isakmp authorization list AAA-AUTHOR crypto map CMAP client configuration address respond

Example 3: DVTI
aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! username cisco password 0 cisco ! crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond virtual-template 1 ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto ipsec profile IPSEC-PROFILE set transform-set TSET set isakmp-profile ISAKMP-PROFILE ! interface Virtual-Template1 type tunnel ip unnumbered GigabitEthernet0/1 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROFILE ! ip local pool LOCALPOOL 8.9.24.201 8.9.24.254 ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any

Differences between Example 2 and Example 3
crypto isakmp profile ISAKMP-PROFILE virtual-template 1 ! crypto ipsec profile IPSEC-PROFILE set transform-set TSET set isakmp-profile ISAKMP-PROFILE ! crypto dynamic-map DYNMAP 10 set transform-set TSET set isakmp-profile ISAKMP-PROFILE reverse-route ! ! crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! interface GigabitEthernet0/0 crypto map CMAP ! interface Virtual-Template1 type tunnel ip unnumbered GigabitEthernet0/1 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROFILE !

Config example: GRE tunnel-interfaces

Jimmy Larsson — Fri, 26 Mar 2010 14:02:42 +0000

GRE tunnel-interfaces

Tunnel-interfaces are real cool. In later post I will describe how to use them to establish ipsec-tunnel but for now we will just ignore the fact that we doesn´t encrypt the packets.

GRE (Generic Routing Encapsulation) is invented by Cisco. It uses IP protocol 47 and encapsultates the entire packet within a new GRE-header.

Lets setup a GRE-tunnel in our example-topology. A Tunnel-interface is a virtual interface created in the router. It has an IP-address and can be treated just like any physical interface. In normal case a tunnel-interface needs to be configured with a tunnel source (usually a physical interface in the local router) and a tunnel destination (usually the remote IP to which to establish the tunnel). Like this:

Lets do it. First, make sure that we have connectivity with remote peer. Never forget that.

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 r1#

Now we configure our tunnel-interfaces:

r1(config)#int tu0 r1(config-if)# *Mar 19 13:31:05.402: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down r1(config-if)# r1(config-if)#ip address 10.99.99.1 255.255.255.0 r1(config-if)#tunnel source fa0.11 r1(config-if)#tunnel destination 10.10.30.3 *Mar 19 13:32:24.014: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up r1(config-if)# r1(config-if)#tunnel mode gre ip

r3(config)#int tu0 r3(config-if)#ip address 1 *Mar 19 13:34:54.058: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down r3(config-if)# r3(config-if)#ip address 10.99.99.3 255.255.255.0 r3(config-if)#tunnel source fa0.30 r3(config-if)#tunnel destination 10.10.11.1 *Mar 19 13:36:00.578: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up r3(config-if)# r3(config-if)#tunnel mode gre ip r3(config-if)#

Now we can see that we have our tunnel-interfaces configured and up/up:
r1#sh ip int brie | excl unassigned Interface IP-Address OK? Method Status Protocol FastEthernet0.10 10.10.10.2 YES NVRAM up up FastEthernet0.11 10.10.11.1 YES NVRAM up up Loopback0 10.1.1.1 YES NVRAM up up Tunnel0 10.99.99.1 YES manual up up r1#

Does it work?

r1#ping 10.99.99.3

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

Great. Now we have a virtual interface on each router inter-connecting them. Wanna have a look at the transit-traffic? Lets go to the wireshark between the routers:

As you see in the screen-dump above wireshark is smart enough to see that it is icmp-pings in the packets. Have a look at the middle-part of the window and you can see that the original IP-packet is inserted into a GRE-packet which in turn is inserted into a new IP-header. The internal (original) IP-header is destinated to the ip-address we pinged but the outer header is between the GRE tunnel endpoints, the physical interfaces. Remember, in my transit-network I might have routers that has no clue about any 10.99.99-addresses.

But our goal was to make our client 192.168.1.50 behind r1 reach the 10.3.3.3-address behind r3, right? How about routing? First r1.

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, 23:48:00, FastEthernet0.10 C 10.99.99.0/24 is directly connected, Tunnel0 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, 23:48:00, FastEthernet0.10 D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 23:48:02, FastEthernet0.10 r1#

and r3.

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, 4 subnets, 2 masks C 10.3.3.3/32 is directly connected, Loopback0 C 10.99.99.0/24 is directly connected, Tunnel0 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#

Ooops. r1 doesn´t know of 10.3.3.3 and r3 doesnt know of 192.168.1.50. First we do it the ugly lazy way: add static routes of remote networks. Next-hop should be the remote router tunnel-interface:

r1(config)#ip route 10.3.3.3 255.255.255.255 10.99.99.3 r3(config)#ip route 192.168.1.50 255.255.255.255 10.99.99.1

Now we have a working tunnel. My windows-client 192.168.1.50 can ping 10.3.3.3

^C C:UsersJimmyDesktop>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=1ms TTL=254 Svar från 10.3.3.3: byte=32 tid=1ms TTL=254 Svar från 10.3.3.3: byte=32 tid=1ms 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 = 1 ms, Högsta = 2 ms, Medel = 1 ms

C:UsersJimmyDesktop>

One of the major functions of tunnel-interfaces is that it supports routing protocols. In r1 we already have eigrp running. Lets try to run eigrp thru the tunnel…

First, remove our static routes.

r1(config)#no ip route 10.3.3.3 255.255.255.255 10.99.99.3 r3(config)#no ip route 192.168.1.50 255.255.255.255 10.99.99.1

First, add the tunnel-interface to the eigrp-process of r1:
r1#sh run | sect router router eigrp 11 network 10.1.1.1 0.0.0.0 network 10.10.10.2 0.0.0.0 no auto-summary r1#conf t Enter configuration commands, one per line. End with CNTL/Z. r1(config)#router eigrp 11 r1(config-router)#network 10.99.99.1 0.0.0.0 r1(config-router)#

In r3 we have no routing protocol running. Time to add that…
r3(config)#router eigrp 11 r3(config-router)#network 10.3.3.3 0.0.0.0 r3(config-router)#network 10.99.99.3 0.0.0.0 *Mar 19 14:06:26.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 11: Neighbor 10.99.99.1 (Tunnel0) is up: new adjacency r3(config-router)#no auto-summary r3(config-router)#

So, what happened?
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 10.99.99.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks D EX 10.2.2.2/32 [170/26885120] via 10.99.99.1, 00:01:08, Tunnel0 C 10.3.3.3/32 is directly connected, Loopback0 C 10.99.99.0/24 is directly connected, Tunnel0 S 10.10.11.1/32 [1/0] via 10.10.30.1 D 10.10.10.0/24 [90/26882560] via 10.99.99.1, 00:01:08, Tunnel0 D 10.1.1.1/32 [90/27008000] via 10.99.99.1, 00:01:08, Tunnel0 C 10.10.30.0/24 is directly connected, FastEthernet0.30 D EX 192.168.1.0/24 [170/26885120] via 10.99.99.1, 00:01:09, Tunnel0 D*EX 0.0.0.0/0 [170/26885120] via 10.99.99.1, 00:01:09, Tunnel0 r3#

Cool. r3 got itself a default-route to the world thru the tunnel.

r1#sh ip route *Mar 19 14:06:30.122: %SYS-5-CONFIG_I: Configured from console by console 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, 7 subnets, 2 masks D EX 10.2.2.2/32 [170/1285120] via 10.10.10.1, 1d00h, FastEthernet0.10 D 10.3.3.3/32 [90/27008000] via 10.99.99.3, 00:02:06, Tunnel0 C 10.99.99.0/24 is directly connected, Tunnel0 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, 1d00h, FastEthernet0.10 D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 1d00h, FastEthernet0.10 r1#

… and r1 knows how to find 10.3.3.3

As I said before: Voila!

Here are the configs for r1 and r3.

Next session will add encryption to this configuration.

Config example: Static to dynamic IPSec

Jimmy Larsson — Sat, 20 Mar 2010 08:37:58 +0000

(Topology here)

Ok. So we have established a static VPN-tunnel between two routers. But what if r1 has a dynamic or unknown peer ip? Let´s change the previous configuration to reflect this:

The config on r1 will be the same. The changes will be done on r3. First, remove what we don´t need anymore:

r3(config)#no crypto map CMAP 10 r3(config)#no crypto isakmp key cisco address 10.10.11.1

Next, let´s compensate for that. Since we cannot use a standard crypto map we need to create a dynamic one instead. Into that we ties the proxy-acl (acl_vpn) as well as the transform-set. What´s the difference? Well it doesn´t have any set peer statement…

r3(config)#crypto dynamic-map DYNMAP 10 r3(config-crypto-map)#set transform-set TSET r3(config-crypto-map)#match address acl_vpn

Also, we must have a pre-shared key. But we don´t know which host ip to tie it to, so it must be a wildcard key.

r3(config)#crypto isakmp key cisco address 0.0.0.0

We still need a crypto map into which we ties the dynmap. Let´s make it with the highest sequence-number available since we might add more tunnels in the future, and this “wildcard”-alike dynmap need to be put as a last resort to not match all other tunnels…

r3(config)#crypto map CMAP 65535 ipsec-isakmp dynamic DYNMAP

One thing left. Remember that reverse-route in the crypto-map of our previous config? Can we put it into the dynmap instead?

r3(config)#crypto dynamic-map DYNMAP 10 r3(config-crypto-map)#reverse-route static %Static keyword not applicable to dynamic maps, re-enter cmd r3(config-crypto-map)#

Darn! Then we have to use a static route to point out the direction of the remote network:

r3(config)#ip route 192.168.1.50 255.255.255.255 10.10.30.1

Now the tunnel goes up! But only if we try to initiate it from 192.168.1.50. It cannot be initiated from 10.3.3.3 since r3 doesn´t have a clue how to contact r1. However, as long as the tunnel is up traffic can be generated from both ends.

Here are the relevant parts of configurations:

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

r3
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 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto dynamic-map DYNMAP 10 set transform-set TSET match address acl_vpn crypto map CMAP 65535 ipsec-isakmp dynamic DYNMAP ! interface FastEthernet0.30 ip address 10.10.30.3 255.255.255.0 crypto map CMAP

(and the full configs for r1 and r3)

Config example: Vanilla static ipsec vpn with crypto map

Jimmy Larsson — Fri, 19 Mar 2010 13:37:16 +0000

(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:


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_MM1Going 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_MM2Going 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.3We 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 0We 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_MM3Ok. 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_MM4And 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_MM5So. 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_MM6We 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_COMPLETESo. 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_QM1IKE_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_IDLEWe 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_IDLEWe 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 1r1#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…

Configuration examples for VPN solutions

Jimmy Larsson — Fri, 19 Mar 2010 11:37:19 +0000

IPsec. Gre. Ipsec/Gre. Crypto maps. Isakmp profiles. Ipsec profiles. Dynamic crypto maps. DMVPN Phase 1, phase 2, phase 3. GET VPN. Easy VPN. NHRP. X-auth. PKI. AnyConnect. Portal. RRI. I could continue forever.

In my journey of investigating all weird flavours of VPN I´ve decided to try each of them in my home-lab and make a blog-post of each one. I will use a common base topology like this:

The scenario is this: Two routers, r1 and r3, are connected to a transit-network. It might be internet, it might be anything else. It might be a crossover ethernet-cable and it might be a multi-hop MPLS-cloud. The host 192.168.1.50 needs to access 10.3.3.3 in a secure way over the transit-network.

To make sure that the routers have connectivity they have host-routes of eachother into the transit-network.

This is a blog post to collect the different configurations together. In the list below I will add each configuration example as I go…