Today, i’m officially done with VPN sections on both INE and IPX. So can i say that i know it all? Hell No! Here’s why.

I did the 4B ( Part 2 ) lab today. It was one helluva session. I thought i’d finally figured out how to troubleshoot effectively, until i hit certificate based EZVPN. There were a couple of things that i had run into when i was doing 4A ( Part 2) , but i didn’t remember them and they proved to be the downfall of me . So here are the things that i encountered today in the config :

• There was a task which involved using Certificates to authenticate to an EZVPN server. This had to be done using the cisco VPN client. A couple of issues here are :
  • If you are using the ASA, then make sure you enter “peer-id-validate cert” to instruct the tunnel-groups to look at the cert for the peer-id ( which could be address, hostname ,etc ).
  • If you are configuring certificate based authorization, then XAUTH should be disbaled. This is because, if authentication and authorization are enabled, the ASA uses the user’s login credentials for both user authentication and authorization. So we need to disable XAUTH and instruct the tunnel-group to look into the certificate to get the username for authentication and authorization
    • To disable XAUTH
      • #tunnel-group test ipsec-attributes
        • isakmp ikev1-user-authentication none
    • To instruct the ASA to use a specific field in the certificate for authentication
      • #tunnel-group test general-attributes
        • username-from-certificate <field>
  • I always end up forgetting this. I hope i keep this in mind now onwards.
• Next, after you instruct the ASA to use a particular field in the user’s certificate ( usually the CN  field ), we need to create a user like that either locally on the ASA ( LOCAL authentication/authorization ) or on the ACS ( Remote ) . Here are 2 conditions here too!
  • If the VPN server is an ASA, then the username and the password will be the same. Ex : Suppose we are using the CN field of the client’s certificate ( ex : CN=Vybhav) , to authenticate and authorize the user, we have to create a user with a username of Vybhav and a password of Vybhav.
  • If the VPN server is a router, then the username is the CN name ( same as the previous point ), but the password to be used is “cisco“
• I also came across an awesome command -> #show vpn-sessiondb . This commands lists the properties of the various VPN servers ( L2L, ezvpn , webvpn , sslvpn, l2tp , etc ) that we might configured on the ASA. This is a great verification tool.
• Also, remember that , without using certificate maps, the IOS (or the ASA) by default uses the “OU” field in the client’s certificate to map the user to a group. Keep this in mind when configuring the group (either internally or externally). The password to use in case of IOS is “cisco” and in case of the ASA , we can specify the password using the “group-policy” command.

I have to admit, i find troubleshooting hard. Very hard sometimes , and i’m not ashamed to admit it As any other person who doesn’t know how to solve something, i asked people who they’d do it I asked people on OSL. My question was simple -> ” What’s the best way to approach a troubleshooting scenario” . I got one awesome answer from Jimmy Larsson. This is what he said :

Recently I´ve started to begin my lasb sessions with browsing all configurations. I take 4-5 minutes just to skim thru all pre-loaded configs just to see if there is anything really weird going on. If I see something that catches my attention I either write a note about it or even spend a minute looking at the task to see if there could possible be a reason for that config-item to exist. If I cant find any reason or a statement that restricts me from modifying the config I just remove it. It has saved me a few times. A thing like a VACL is quite obvious to spot in the config and there should either be a reason for that to exist or not. Same goes with mis-spelled password/keys. If it saids “isakmp key “piexpert” it it probably something tricky going on.

That’s excellent advice and i wanted to share it with you guys . Thanks Jimmy!

Also, don’t forget to look into the switches as well. One of the configuration tasks, had a VACL configured in the switch which was gobbling up the SSL encrypted HTTP requests from the test-pc to the ASA(WEBVPN server ). Stuff like that can trip you up , so watch out. This is my personal list of  ”WHAT’s that doing there! :0 ” :

• Route-maps
• ACLs
• Webvpn Filter commands
• VACLs
• VLAN assignments
• Erroneous spellings.

If i see any of the above, i just write a note about it , like Jimmy suggested . It works like a charm and it helps a lot! I’d suggest you give this one a try.

That’s it for today. I intend spending the next two days revising some stuff that i found hard and also reading up on some doc-cd. I always remind myself that it’s about attention to detail  and that keeps me going

Cheers and have a great weekend!

TacACK