*Aug 31 13:26:48.970: %CRYPTO-3-IKMP_QUERY_KEY: Querying key pair failed.

RSA keypair issues maybe? Not a chance…

Well possibly but I bet your first thought would not be “Let me check if the router time is correct.” I saw this issue today when configuring a simple site to site VPN tunnel. This error seemed to overtake the screen making me think I had a RSA issue. I then when ahead and checked my RSA key and it was there. I also checked the trustpoint to make sure I referenced it properly. It also was correct. I then decided to blow away the trustpoint and recreate it. This time I let the router automatically generate the RSA key and I still saw the same error. I went back to the debugs, paid a bit more attention and saw the following:

*Aug 31 13:26:39.470: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 136.1.123.12 is bad: CA request failed!
Rack1R3(config)#
*Aug 31 13:26:40.632: %CRYPTO-3-IKMP_QUERY_KEY: Querying key pair failed.
*Aug 31 13:26:41.798: %CRYPTO-3-IKMP_QUERY_KEY: Querying key pair failed.
Rack1R3(config)#
*Aug 31 13:26:42.964: %CRYPTO-3-IKMP_QUERY_KEY: Querying key pair failed.
Rack1R3(config)#
*Aug 31 13:26:45.468: %PKI-3-CERTIFICATE_INVALID_NOT_YET_VALID: Certificate chain validation has failed. The certificate (SN: 0x61EFC13D00000000000B) is not yet valid Validity period starts on 20:19:12 UTC Aug 31 2009

Well obviously at this point I new this was most likely a clock issue. I configured ntp on the router and Wallah! Everything worked as expected.

Ill put out some thin and thick client configs later. For the clientless mode SSL config there are basically 3 things to remember.

1. Configure authentication

aaa new-model
aaa authentication login default local
username bobjones password bobjones

2. Configure the webvpn gateway.

webvpn gateway WebVPN_Gateway
hostname WebVPN_Gateway
ip address 192.168.40.2 port 443
http-redirect port 80
inservice
! Enables the Gateway. You will also notice that the RSA Key is automatically generated. If you want one that is exportable, you will need to create it yourself.

3. Configure the webvpn context. This provides the webvpn configuration

webvpn context WEBVPN_CONTEXT
!
port-forward "R4-Access"
local-port 2222 remote-server "192.168.4.4" remote-port 22 description "SSH to R4"
local-port 2323 remote-server "192.168.4.4" remote-port 23 description "Telnet to R4"
!
title "Welcome to wr-mem SSL VPN"
color Blue
secondary-color Green
text-color Gray
secondary-text-color Gold
policy group webvpn_policy
port-forward "R4-Access" auto-download
default-group-policy webvpn_policy
gateway WebVPN_Gateway domain wr-mem
! You must tie the context to a gateway. The domain parameter will allow you to differentiate this context from another. https://xxx.xxx.xxx.xxx/wr-mem
inservice
! Enables the context and also creates the PKI trustpoint along with the certificate.
exit
exit

Once you get it all in its pretty simple to modify or muddle your way through to make changes. Ill put out some more advanced configs later.

The whole deal:

interface FastEthernet1/1
ip address 192.168.4.2 255.255.255.0
duplex auto
speed auto
no shut
!
interface FastEthernet1/0
ip address 192.168.40.2 255.255.255.0
duplex auto
speed auto
no shut
!
aaa new-model
aaa authentication login default local
username bobjones password bobjones
!
webvpn gateway WebVPN_Gateway
hostname WebVPN_Gateway
ip address 192.168.40.2 port 443
http-redirect port 80
inservice
! Enables the Gateway. You will also notice that the RSA Key is automatically generated. If you want one that is exportable, you will need to create it yourself.
webvpn context WEBVPN_CONTEXT
!
port-forward "R4-Access"
local-port 2222 remote-server "192.168.4.4" remote-port 22 description "SSH to R4"
local-port 2323 remote-server "192.168.4.4" remote-port 23 description "Telnet to R4"
!
title "Welcome to wr-mem SSL VPN"
color Blue
secondary-color Green
text-color Gray
secondary-text-color Gold
policy group webvpn_policy
port-forward "R4-Access" auto-download
default-group-policy webvpn_policy
gateway WebVPN_Gateway domain wr-mem
! You must tie the context to a gateway. The domain parameter will allow you to differentiate this context from another. https://xxx.xxx.xxx.xxx/wr-mem
inservice
! Enables the context and also creates the PKI trustpoint along with the certificate.
exit
exit

My friends always told me “Joe, your an animal. One day your going to try and configure something that will send you right over the edge.” Well I say bring it on. GET VPN is great and I want to tame the beast and use it my battle against the stuff I tend to have to battle sometimes.The networking world is serious business and only the true gladiators can thrive in it.

Now lets get back to reality. I didnt really configure in 28 minutes. Im not sure how long it took me because I wasnt timing myself. I did however successfully configure GET VPN in my own scenario. Im starting to like GET VPN a bit more. I understand how it works but now I just need to remember exactly what to configure. This is actually pretty easy stuff. I did my configuration using gns3 and a another handy little app called process lasso. My laptop seems to manage great with it.  The GET VPN setup worked without a hitch.  Here is the config:

Key Server Config

1. Configure the phase 1 policy

crypto isakmp policy 10
auth pre-share
encry 3des
hash md5
group 2

2. Configure preshare keys for all group members

crypto isakmp key cisco address 192.168.0.2
crypto isakmp key cisco address 192.168.3.1

3. Confiure IPSec transform set and profile

crypto ipsec transform-set trans_gdoi esp-3des esp-sha-hmac
crypto ipsec profile ipsec_gdoi_profile
set transform-set trans_gdoi

4. Configure the match ACL. This should be as generic as possible to ensure you cover all of the GMs. (100 entry limit)

access-list 100 permit ip 192.168.12.0 0.0.0.255 192.168.12.0 0.0.0.255

5. Configure GDOI Group

crypto key gen rsa general-keys label getvpn_rekey mod 1024 exportable
! This is for rekeys <KEK>
! Below is the Key Server config
crypto gdoi group group_getvpn
identity number 1111
server local
rekey transport unicast
rekey authentication mypubkey rsa getvpn_rekey
sa ipsec 1
profile ipsec_gdoi_profile
match address ipv4 100
address ipv4 192.168.0.1

Group Member Config

1. Configured the phase 1 policy

crypto isakmp policy 10
auth pre-share
encry 3des
hash md5
group 2

2. Configure preshare keys for all key servers (Group members only need to make phase 1 with the KS)

crypto isakmp key cisco address 192.168.0.1

3. Configure GDOI Group

crypto gdoi group group_getvpn
identity number 1111
server address ipv4 192.168.0.1

4. Apply the GDOI group to a crypto map and the crypto map to the interface

crypto map map_getvpn 10 gdoi
set group group_getvpn
!
interface fa0/0
crypto map map_getvpn

Thats it. Since GET VPN preseves the IP header you only need to make sure the traffic defined by your match ACL is routed correctly to the other group members. GETVPN will insert the ESP header, encrypt the payload and in keep the original IP header intact. Here are some show commands you can use to verify:

GROUP MEMBER:
Router#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
192.168.0.1     192.168.3.1     GDOI_IDLE         1001    0 ACTIVE

Router#sh cry gdoi ipsec sa
SA created for group group_GETVPN:
FastEthernet0/0:
protocol = ip
local ident = 192.168.12.0/24, port = 0
remote ident = 192.168.12.0/24, port = 0
direction: Both, replay(method/window): Time/5 sec
Router#

Router#sh crypto gdoi gm
Group Member Information For Group group_GETVPN:
IPSec SA Direction : Both
ACL Received From KS : gdoi_group_group_GETVPN_temp_acl
Re-register
Remaining time : 3398 secs

KEY SERVER:

Router#sh cry gdoi ks
Total group members registered to this box: 1
Key Server Information For Group group_GETVPN:
Group Name : group_GETVPN
Group Identity : 111
Group Members : 1
IPSec SA Direction : Both
ACL Configured:
access-list 100
Router#

So whats the big deal about SVTI? Well its cool of course. There are some things you need to know (Restrictions).

SVTI (Static Virtual Tunnel Interface) supports tunnel mode only and ip any any proxy ID. The main deal here is the “IP any any proxy id”. The proxy ID in crypto maps is what us Cisco folks know as the match ACL. The match ACL defines what traffic flow is to be encrypted for the tunnel. The remote peer must have a mirrored copy of this configured. So why even bother if you have to encrypt everything? Well thats not the case. Remember, We are actually only encrypting what we send to the tunnel interface. So even if we have “any any” as the proxy id we are not necessarily encrypting all traffic to the remote peer. You can have multiple SVTI configured then you would define what traffic you want to send to the tunnel interface by using route entries. Think of all the possibilities of this. You can configure some sweet route-maps to redirect traffic, apply different features to the interface itself like nat, ACLs etc…

So SVTI is a “always on” type of tunnel. You define what you want to encrypt by using route statements pointing to the tunnel interface but the tunnel will always remain up regardless of traffic flow. You can filter using ACLs, ip inspects, auth proxy and more. The issue I hit was the proxy id problem. Openswan had the left and right subnets defined instead of a any any config. The tunnel would come up for like 20 seconds then fail miserably. Openswan was whining that it didnt like the 0.0.0.0 proxy ID sent to it because it wasnt configured that way.

conn mytestVPN
left=192.168.40.129
leftsubnet=10.10.10.10/32
leftnexthop=192.168.40.1
right=192.168.40.10
rightsubnet=192.168.55.128/26
esp=3des-md5-96
auto=start
pfs=no
ikelifetime=28800
keylife=3600

As you can see, the right and left subnets are equivalent to a Cisco match address. The SVTI interface however does not use a match ACL. Here is the quick and dirty config for it.

crypto ipsec transform-set tset_3des_md5 esp-3des esp-md5-hmac
!
crypto ipsec profile 3des_profile
set transform-set tset_3des_md5
!
crypto isakmp key cisco address 192.168.40.129
!
interface Tunnel22
ip address 1.1.1.1 255.255.255.252
no snmp trap link-status
tunnel source FastEthernet0/0
tunnel destination 192.168.40.129
tunnel mode ipsec ipv4
tunnel protection ipsec profile 3des_profile
!
ip route 10.10.10.10 255.255.255.255 tunnel 22

Look how small the config is. This is a much easier way to configure tunnels than using a crypto map. Ultimately, in this scenario I decided to use a crypto map config because I’m not sure if Openswan has anything to compare as far as SVTIs go. Maybe its possible to bind to a loopback and then use route statements to route the encryption traffic correctly in linux.

I did however get this working by configuring openswan for a 0.0.0.0/0 to 0.0.0.0/0 proxy id.

conn mytestVPN
left=192.168.40.129
leftsubnet=0.0.0.0/0
leftnexthop=192.168.40.1
right=192.168.40.10
rightsubnet=0.0.0.0/0
esp=3des-md5-96
auto=start
pfs=no
ikelifetime=28800
keylife=3600

With this configured everything came up as expected. I think the loopback idea might work but haven’t tried it yet.

I planned on putting some debug info in this post. Will need to work on this later when I get some routers working to show examples.

More details can be found in the GDOI RFC

Yesterday afternoon I passed the CCIE Security Written exam and recertified my CCIE Security until the end of 2011!  Even though my CCIE was not set to expire until December, I’m happy to get recertification out of the way now before some other stuff takes up all my time.

The first time I passed the written was in 2006 and it was a very different test back then!  The blueprint is no longer online, but as I recall, half of it was routing (BGP) and IOS stuff and the other half was PIX, IPS, 3k, and network attacks.  Surely there were some “general” security questions in there, but the exam of 2006 was a far cry from the one I took yesterday.

Speaking of which, the CCIE Security Written is a fine test.  Like any Cisco exam there are some questions that one might think are too narrow or niggling, but overall I have no complaints.  Also, just like with the lab exam, the blueprint is there for a reason.  Let it be your guide.  Beyond the blueprint, I recommend that you have a general understanding of infosec at all layers.  Don’t forget that those layers go up to 7 and so does the need for security!

Finally, resist any urge you might have to ignore the “soft” stuff like standards, regulations, procedures.  All that stuff on the bottom of the blueprint is fair game, even if you think, “That’s annoying, I would just look that up!” (*cough* me *cough*)

So whether you’re just getting started on the path or looking to recertify yourself, good luck!

I stumbled on this when I was googling to figure out what the exam blueprint has in mind for the “Application Protocols” section.  A link to the Safari version of the book came up in my search results so I clicked through and took a quick read (it’s only 96 pages).  Here’s a mini review:

This isn’t really a book so much as a series of snippets on many of the CCIE Security Written Exam topics.   The book is billed as a final preparation for the exam and I think it would do nicely in that capacity and more.

The sections of the book mirror exactly the sections on the written blueprint.  This is a nice touch and it’s almost like the book is fleshing out the blueprint to the next level.  As I mentioned at the top, I was looking for insight into the “Application Protocols” section and where the blueprint lists “SMTP” and calls it a day, this book lists the SMTP basics and provides a list of SMTP commands.

I can see a CCIE candidate using this book throughout the study process:

1. Refreshment and Orientation. If it’s been a while between exams, or you just want to get a feel for the exam, a quick read through the book should help there.  While there aren’t many details, there are often links to more info if you need a push in getting started.
2. Prioritization. As mentioned, this book is light on details.  That said, it does feel like it presents the core nuggets you will need to get by on the exam.   If you’re strapped for time, or you’re just looking for some direction, learning the details of those nuggets first might be a useful strategy.
3. Final Preparation. I personally like to use flashcards for my final exam preparation, but this book serves a similar function.  I feel like reading over these quick reference sheets close to exam time could help “prime” your brain and get you in the mood to test.

CCIE Security Exam Quick Reference Sheets is not a substitute for all the experience you need to pass the CCIE Security written, nor is it the only book you should read in your exam prep.   Rather, the book is a lightweight guide to the exam topics that can point you in the right direction and serve as your last-minute review buddy before test time.

One of the cards is about the Security Wheel, the continuous process by which we strive to create a secure network. The Security Wheel is a 4 part cycle consisting of:

1. Secure
2. Monitor
3. Test
4. Improve

This is pretty straightforward, but for some reason every time I was faced with “Security Wheel” on the front of the card, I blanked out on one of the phases.  So, just like with the OSI Model, I decided to create a quick mnemonic device:

The Security Wheel Spins Madly Toward Infinity.

So far I like this one and it seems to be working for me.  Do you have any mnemonics that you use to remember the Security Wheel or any other test topics?  Share them in the comments!

Image Credit: The Security Wheel, Network Security Technologies and Solutions (CCIE Professional Development Series), p. 18, Figure 1-6.

So far, I’ve been less-than-dilligently reading Yusuf Bhaiji’s latest CCIE Security Book, Network Security Technologies and Solutions (CCIE Professional Development Series), but now it’s time to break out the equipment again.

Maybe you’re in the same boat, or maybe you’re just getting started.  Either way, the first thing you need is a switch; a clean switch, in fact, so that old configs don’t get in your way.

To this end, I grabbed my trusty 24 port 2900xl and fired it up.  It had all sorts of config on it, but that was easily blown away:

2900xl#write erase
Erasing the nvram filesystem will remove all files! Continue? [confirm]
[OK]
Erase of nvram: complete
2900xl#reload
Proceed with reload? [confirm]

The cleaning doesn’t end there, though.  We can’t forget about all those pesky VLANs that made so much sense once upon a time:

2900xl#sho vlan
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4,
Fa0/5, Fa0/6, Fa0/7, Fa0/8,
Fa0/9, Fa0/10, Fa0/11, Fa0/12,
Fa0/13, Fa0/14, Fa0/15, Fa0/16,
Fa0/17, Fa0/18, Fa0/19, Fa0/20,
Fa0/21, Fa0/22, Fa0/23, Fa0/24
100  100_lab_vlan                     active
101  101_lab_vlan                     active
102  102_lab_vlan                     active
110  110_lab_vlan                     active
111  111_lab_vlan                     active
113  113_lab_vlan                     active
120  AAA_lab_vlan                     active
121  R1_lab_vlan                      active
122  R2_lab_vlan                      active
123  R3_lab_vlan                      active
124  R4_lab_vlan                      active
125  125_lab_vlan                     active

Look at them all.  I’ve got no use for them now, so lets get rid of them.   We could delete them one at a time…

2900xl#vlan da
2900xl(vlan)#no vlan 100
Deleting VLAN 100...


…but there are so many.  Even more than the ones in the excerpt above.  Killing them one at a time would take forever.  So, what do we do now?  Let’s delete all the vlans at once!

2900xl#del vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
2900xl#

Once we delete vlan.dat the switch will forget about all those crusty old VLANs from the last time the switch was used.   One reload later and we’ve got that new switch smell back:

2900xl>sho vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4,
Fa0/5, Fa0/6, Fa0/7, Fa0/8,
Fa0/9, Fa0/10, Fa0/11, Fa0/12,
Fa0/13, Fa0/14, Fa0/15, Fa0/16,
Fa0/17, Fa0/18, Fa0/19, Fa0/20,
Fa0/21, Fa0/22, Fa0/23, Fa0/24
1002 fddi-default active

Now we’re ready to get studying. Good luck!

Was it worth it? Yeah, I think so. It was kind of expensive and I mainly spent time doing the lab work but I really needed this time. It has been hard finding the motivation at home or even having the time at home to get prep work done with the kids, wife and everything else. Like I said before, I think the class format would be more beneficial to work through things as a group. Some of my class mates were behind in the lab work. It would be good to review material, do the lab and then review the results. See what people got wrong and why. I think this would allow everyone to learn a bit more.

- 6/29 – I originally started writing this post a few weeks ago. Sorry to be so late in getting it out. I’ve recently had mixed emotions about continuing for my CCIE and I’m trying to find the spark to get me going again. I have a lot of gripes about the program, many of them not technical at all but process wise and I wont bother sharing them here. Either way it has been something Ive wanted to do for many years now and if I don’t complete it I will feel like I’ve let one of my goals go which would haunt me for quite some time. So to save sanity I’m going to continue with the practice and do the best I can. Hoping to schedule my lab attempt soon, which I could take it in San Jose but doesn’t make sense since I live here in RTP. Hope to be posting some GET VPN topics, SVTI and DVTI posts soon.