Whoa! The last 2 days have been incredible and i’ve learned just how much IPX can kick ass!

I started the IPX VPN lab ( 4A (Part 1 and 2)and 4B (Part 1 and 2) ) and i found them really challenging. It’s just worded cryptically and the tasks themselves are pretty complex. They try and cram as much hard configs as they can in one task, which i’m totally loving! So let me do a quick review of the stuff that i learnt.

Firstly, i just wanna mention that i could only finish Part 1 of  4A and 4B . This covers L2L and EZVPN .

4A (Part1) – This section involves configuring scenarios from the scratch. Only base configs are provided.

• Suppose you have created a RSA key-pair and you would like the IOS CA you are using to use those keys for signing the certificates, you can achieve by configuring the name of the of PKI server the same as the key. For Example :
  • Suppose we create a key-pair named “X” ,#crypto key generate rsa modulus 1024 label X , if you want the PKI server to use this key “X” , then configure the name of the PKI server as “X”
  • #crypto pki server X
    
• There was a task where the IOS CA had to be configured with a CDP Url so that it’s compatible with non-SCEP clients. When configuring that i noticed this issue. Always ensure that you configure the url “precisely” how it’s given in the Doc-CD. For example :
  • #crypto pki server IOS_CA
    • #cdp-url http://x.x.x.x/cgi-bin/pkiclient.exe?operation=GeTCRL   -> This was not working, and then i found out that the “T” in GeTCRL should’ve been lowercase
    • #cdp-url http://x.x.x.x/cgi-bin/pkiclient.exe?operation=GetCRL   ->  This started working!
  • I always thought URLs were case-independent ,but this was giving me a problem. So i just wanted to point it out.
  • You can find this in the DocCD here -> http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_mng_cert_serv_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1193861

• There was also an interesting task which requires us to ensure that the CA Certificates and key pairs are “archived”. This was a new concept to me and i did some study on this. Here is the document which i used. It’s very interesting. By specifying the “ database archive {pkcs12 | pem} [password [encr-type] password] ” command, we are instructing the router to automatically backup the CA Certificate and keys ( in either .pem or .pkcs ) format and encrypt it using a password , which can be used to retreive the certificates later. The location where the archive must be stored can be specified by using the “database url” command.
  
• Usually when we define a trustpoint on a router, we need to associate an rsa-key pair to it. By default, it takes the default key-pair that is present in the router. But if you want to instruct the router to use a specific key-pair ( say X) , then we use the command “rsakeypair” under the trustpoint configuration sub-menu. Just an FYI
• Here’s a kick-ass concept which i failed to get the first time and then with the help of the DSG, i figured it out
  • Do you guys remember the VPN behind overlapping subnets question in the INE workbook, well IPX has a similar one but here , we’ve to use VTI. So after configuring the NAT on both the routers ( so that they can cheat each other ) , we have to do some new stuff here :
    • In usual crypto maps, multicast routing protocol traffic cannot be sent. So we used to manually define static routes on both the routers for remote subnets ( Well , they’re nat-ed here because they overlap ), so that they could reach one-another. However in case of VTI, multicast routing protocol traffic is available and we can use a routing protocol to tunnel the routing protocol traffic between the 2 routers. So we can effectively eliminate the necessity of the static routes. To achieve this, we need to create a “loopback” interface on both the routers and assign it the same IP address that you are using to NAT the inside (overlapping) subnet to. After this we add this subnet to the routing protocol, so that the routes are propagated to the remote-peer.
    • In usual crypto maps, when specifying NAT, we specify the “ip nat outside” command on the outside interface and “ip nat inside” on the inside (overlapping subnet) interface . But in case of VTI we need to apply ip nat outside to the “tunnel” interface and “ip nat inside” to the loopback interface for the NAT to work.
• Ensure that , when using certificates for IKE Phase 1 authentication,instruct the router to look at the certificates for the ike phase 1 identity using the command “crypto isakmp identity dn“. Failing to do this will result in the tunnel not coming up.
• Always associate an ISKAMP profile to an crypto map or an ipsec profile, if you want the router to use that profile when it’s initiating a connection. Please correct me if i’m wrong. This is my understanding.
• Regarding registering the Cisco VPN client with the CA, it never used to work for me, untill i started following these guidelines -> http://www.mail-archive.com/ccie_security@onlinestudylist.com/msg04969.html

4B ( Part 1 ) -> This is a troubleshooting section where they have partially ( or screwed ) configs which we have to debug

• This was the first time i was doing these and they’re just awesome! IMO , learning to identify the problem will help us strengthen our knowledge and will act as practice for the actual lab.
• One issue i learnt was to start debugging from L1 to L7, no matter how apparent the solution.  The troubleshooting section had all kinds of issues , some simple ( like forgetting to apply the crypto map on the interface , or forgetting to specify the ISAKMP psk for the peer) , to complex issues ( Like PBR configured on the router which was black- holing all the traffic to be sent over the VPN ).
• I had a hard time with this section and i hope to get better soon.

Well that’s it for Part 1. I’ll be doing Part 2 soon and i’ll fill you in how that goes. As for tomorrow, i’ve an exciting new article-series planned. Look-out for that

Cheers and Happy labbing!

TacACK