Flex VPN is the last VPN to set up; it's also kind of all of the ones we have done, pushed into one. Flex VPN takes all the other VPNs, mashes them together, and this how we get Flex VPN. For a pretty good overview, check out the Cisco Live! presentation.
This one will get interesting (well it was for me, I saved most of the troubleshooting stuff, as there was just too much of it, but we'll get to that later). The other reason it's interesting is that we are going through three different firewalls, so need to bear this in mind.
Let's start with GDOI-Server as the Flex-VPN client, by enabling aaa new-model and setting an authorization list:
Next, as Flex VON is all IKEv2 based, we need an IKEv2 proposal:
A policy to match our proposal:
Now we need an authorization policy:
We now create an IKEv2 profile, matching the remote address, and specifying how we are going to connect (pre-shared-key), and defining the keyring:
We create the keyring:
And add the keyring to the profile:
Now we create our client specifying the peer and the interface we are going to connect through:
Our tunnel interface does not exist yet, so let's create it and add it to the client settings:
We'll be needing a transform set
And an ipsec profile:
We attach the profile to the tunnel interface:
Let's move on to CA-Flex (the FlexVPN server). We start by making sure that the Flex VPN tunnel source (lo0) is reachable:
Enable AAA new-model and create the authorization list:
Create the IKEv2 authorization policy, which contains a pool for client addressing, and an ACL, which contains any routes we want to have installed as static routes on the client. These routes get important later on:
Next, we have the proposal:
The policy:
The keyring:
The profile:
The transform set:
The ipsec profile:
We tie this to a virtual template:
Then we create an IP addressing pool:
And the ACL for routes we want to install on the client. Here I am using the same as the pool.
That's it for the client and the server, but at the moment, though, the two router cannot talk to each other, despite the routes being in place:
We have the routes; we just can't get to them. The GDOI-Server can reach 1.1.1.1, though, so this will help us find the answer pretty quickly (by looking for an ACL that permits traffic to that address):
Let's start with the zone-based firewall:
This should not be the issue (at least not for the basic ping test), as we are permitting ICMP from any to any. Let's move on:
Looks to be a possibility. Let's add a couple of rules, and test:
Not yet, but we can start to see the hit counts increase. Let's move on:
Ok, let's repeat the process here as well:
Sweet, we have initial reachability. Now let's go and add the rules to permit IKE between the two hosts:
The tunnel is not coming up yet, so let's debug:
Is this caused by NAT translation? Let's add some rules to find out
Adding these rules gets us further but is still not perfect. Let's check the debug logs again:
Everything comes up, but then the tunnel drops due to recursive routing. This is caused by the server, advertising the interface route back through the tunnel. Let's remove this route:
Flex is idle, but interface is up:
GDOI is not well, though:
This is more to do with the Easy VPN set up before, I just didn't see it last time, and this is probably due to no checking properly. I should have saved and reloaded the routers to makes sure. Here is the issue (as I see it) in picture format:
So, I need to differentiate the following:
1: Flex VPN traffic coming into 7.7.7.7 from GET VPN traffic coming into the same address.
2: Easy VPN traffic coming into GDOI-G1's Gi0/1 interface from GET VPN traffic on the same interface.
Interestingly, GDOI-G2 is all fine, which does beg the question as to whether the GDOI-G1 issues are all on GDOI-G1.
After doing some digging, I think I am over analyzing the issue. While a state of IDLE may not seem like what we want, it is, much like the QM_IDLE from DMVPN we looked previously. So, although I took this to mean that there was an issue, actually all is fine, and we can prove this by adding a new loopback on CA-Flex, and just advertising that to the Flex VPN client:
I just spent a long time trying to fix a problem that was not a problem at all, because I neglected to test the basics. The thing is that we cannot ping the Tunnel0 interface IP address from CA-Flex. But this is a routing issue, if I had tried pinging it from the advertised loopback, it would have worked fine:
So, our Flex VPN is working as it should. Let's go and fix GDOI-G1. After much fixing (ahem, read clutching at straws, and trial and error) I got GDOI and Easy VPN working together. Here is the resulting configuration:
So, before we go through the explanation, let's show the proof:
So, what was changed, and why?
In the configuration, the GET VPN interface has been moved to a virtual interface. This allows us to still use the same outside interface (Gi0/1) for Easy VPN and GET VPN, but the two can live happily alongside each other. Here is a side-by-side comparison of GDOI-G1 and GDOI-G2 so we can see the differences:
GDOI-G1
GDOI-G2
Crypto Keyring
crypto keyring Get-Keyring
pre-shared-key address 7.7.7.7 key cisco
** Not required **
ISAKMP Policy
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0
ISAKMP Profile
crypto isakmp profile GET-ISAK-Prof
keyring Get-Keyring
match identity address 7.7.7.7 255.255.255.255
virtual-template 10
** Not Required **
Transform Set
crypto ipsec transform-set GET-TS esp-3des esp-sha-hmac
mode tunnel
crypto ipsec transform-set GET-TS esp-3des esp-sha-hmac
mode tunnel
IPSec Profile
crypto ipsec profile GET-Profile
set transform-set GET-TS
set isakmp-profile GET-ISAK-Prof
crypto ipsec profile GET-Profile
set transform-set GET-TS
GDOI Group
crypto gdoi group GDOI-G1
identity number 1
server address ipv4 7.7.7.7
client registration interface GigabitEthernet0/1
crypto gdoi group GDOI-G2
identity number 2
server address ipv4 7.7.7.7
client registration interface GigabitEthernet0/2
Crypto Map
crypto map G1 10 gdoi
set group GDOI-G1
crypto map G2 10 gdoi
set group GDOI-G2
Outside interface
interface GigabitEthernet0/1
ip address 10.1.13.8 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco
duplex auto
speed auto
media-type rj45
crypto ipsec client ezvpn EZ-Group
interface GigabitEthernet0/2
ip address 10.1.14.9 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco
duplex auto
speed auto
media-type rj45
crypto map G2
Virtual Template
interface Virtual-Template10 type tunnel
ip unnumbered Loopback0
tunnel source GigabitEthernet0/1
tunnel mode ipsec ipv4
tunnel protection ipsec profile GET-Profile
crypto map G1
** Not required **
As you can see, we push the pre-shared-key into a Keyring and set up an ISAKMP profile, to use this keyring, match it to the tunnel destination (GDOI-Server's loopback address), and point it to a virtual template. Under the IPSec profile, we attach the ISAKMP profile, but then unlike GDOI-G2, we do not call the GDOI crypto map on the external interface (Gig0/1), instead, this is called by the virtual template. This virtual template also uses the IPSec profile, the IP address from loopback0, and has the source interface as Gig0/1.
Now, let's compare how Easy VPN was configured before, and how it is now:
Easy-VPN initial
Easy VPN now
ISAKMP policy:
crypto isakmp policy 20
encr aes 256
authentication pre-share
group 2
crypto isakmp policy 20
encr aes 256
authentication pre-share
group 2
Easy VPN Client config:
crypto ipsec client ezvpn
connect auto
group EZ-Group key cisco
mode client
peer 6.6.6.6
crypto ipsec client ezvpn EZ-Group
connect auto
group EZ-Group key cisco
mode client
peer 6.6.6.6
xauth userid mode interactive
Outside interface:
int gi0/1
crypto ipsec client ez EZ-Group
interface GigabitEthernet0/1
crypto ipsec client ezvpn EZ-Group
Inside interface:
int lo0
crypto ipsec client ez EZ-Group inside
interface Loopback0
crypto ipsec client ezvpn EZ-Group inside
Barring the xauth, no changes. I only needed to change one or the other, but (as I found), not both VPNs. This took me some time to figure out. While we do need the separation between the two VPNs, and can achieve this through the keyring, ISAKMP profile, and virtual-template, we only need to do this once if we have two VPNs, when we looked at ISAKMP profiles before, we had three VPNs and needed two ISAKMP profiles. So, whilst we can have one "default", additional VPNs will require separation through ISAKMP profiles and virtual interfaces.
That's pretty much it for this topology. I could go and extend out EIGRP across the VPNs and implement the odd bit of security here and there, but I am itching to upgrade UNetLab to the new version, and start a new lab!
Oh, and if you were wondering what "FYIP" means - it stands for Fuck You ISAKMP Profiles.