cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1066
Views
0
Helpful
4
Replies

"apprentice" with crypto transform-set questions

Bill Dickerson
Level 1
Level 1

Greetings - I was sort of a backup person or I guess "apprentice" to our network administrator who recently retired. Same story, guess who is now tasked with figuring it all out.
We have a pair of 5510s in the main office, the second is a "fail-over" in case number 1 dies.
Our remote offices have 5505s (System image file is disk0:/asa844-1-k8.bin)  which connect back here over LAN-to-LAN via the Internet connection provided to that office by various ISPs. Mostly good, some "tunnels" or connections stay up for days if not weeks or months at times with no issues.
But we do have a few trouble offices where either connection drop fairly routinely or in one case they frequently lose the ability to connect back to the mainframe connector address back here. We've various subnets in our main office, the mainframe and email are provided by the State's central IT, or IT Enterprise/ITE. Some of our "networks" are using public addresses, some private.
Each remote office has it's own network. The numbering is based on the office's accounting number, not that it really matters.
So each remote office will have a private 10.252.xxx.xxx scheme where the first set of xxx is the office number and the last set of xxx is the range we assign them, normally broken up with a /27 (255.255.255.224) mask.
With that established, a typical office will be 10.252.24.1-30 (10.252.24.0 network)
I've been tossed into the fire and told to figure out our problem offices. In trying to learn why things are in these as they are I find some things that puzzle me. Can't put my finger on it, but it just doesn't feel right.
One topic at a time - I find Cisco documentation that says you can assign a MAX of 6 transform sets to whatever.
HOWEVER, I find more than 6 listed, 11 in fact. I can't figure out why so many and what the heck we even need more than 1 or 2 for anyway. I think some of this is here because updates to the os over the years means that things simply appeared by the update process and I also think that some was put in just because things were tried - throw it in and see if it helps. I hate that.
I want these cleaned up, and only code that is necessary to be left - and in a way I can understand it. And if that helps with our connection issues, great, but if not at least things will be easier to sort through and figure out.
Here is the area in question for the purposes of this post -
Looking at the small section of our config in a typical remote office ASA5505 I'll post below - what belongs or is necessary, and what is extraneous and can or should be trashed or removed.
Why 11 transform-set lines?
Is this what the max of 6 was referring to? (this quote)>>Following the configuration of a transform set, you assign it to a crypto map. You can assign up to six transform sets to a crypto map. <<

----------------------------------------------------------------------
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac       (why all of these???)
crypto ipsec ikev1 transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac                        |
crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac                  |
crypto ipsec ikev1 transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac                 |
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac                  |
crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac                 |
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac                            |
crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac                          |
crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac                               |
crypto ipsec ikev1 transform-set ESP-DES-MD5 esp-des esp-md5-hmac         (10 of these not counting the next)
crypto ipsec ikev1 transform-set vpnivrs esp-3des esp-md5-hmac  (sort of makes sense-  vpnivrs is the "name" and is used..?)
crypto map ivrsmap 10 match address OUTBND
crypto map ivrsmap 10 set peer 209.111.111.666            (changed to protect the true address)
crypto map ivrsmap 10 set ikev1 transform-set vpnivrs
crypto map ivrsmap interface outside
crypto isakmp nat-traversal 30
crypto ikev1 enable outside
crypto ikev1 policy 10                    (why two of these "policy" lines?)
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 28800
crypto ikev1 policy 65535               (see above - this is number 2 - why two? what does this one do?)
 authentication pre-share
 encryption 3des
 hash sha    
 group 2
 lifetime 86400
--------------------------------------------------------

Some quick stats or tests -

VRAMSASA1# show crypto ikev1 sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 209.111.111.666
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE
 

I can supply whatever additional information may help.
I've already fixed some problems by turning NAT-T back on for the offices supplied Internet via a DSL modem as the modem is apparently a NAT device - outside interfaces on the 5505s with DSL have a 192.168 address and the MODEM has the Internet address where the cable modem supplied sites have a public address direct on the outside interface.  Something bugged me about those sites - and I was able to figure out what and why finally. This configuration example above bugs me now - but I don't know why.
 

Just another public employee trying to make things work correctly, having to learn the hard way now.........
I apologize if this isn't the correct area to post.
Thanks.

 

1 Accepted Solution

Accepted Solutions

You're welcome.

With regards to your follow-on questions A and B - both yes.

DO FIRST - make a backup of your configuration. This is a good idea when making changes of any kind. If you have any doubts, backup before and backup after. Do a side-side comparison to check your work. (I use ExamDiff to make comparing long text files less prone to human error.)

When you have preshared keys (which show up as hashes when you do a simple "show run") you should use the following (while logging your terminal output):

term pager 0

more system:running-config

The first line will make the whole output scroll by at once and the second will print the configuration with any preshared keys in plain text.

View solution in original post

4 Replies 4

Marvin Rhoads
Hall of Fame
Hall of Fame

Welcome to the VPN Forum - this is the right place for your question.

You're mostly on point. The various named transform sets are either included with the default ASA configuration file or added as part of a system software upgrade. The ones that aren't specified for use in a site-site or remote access VPN are unnecessary and can be safely removed.

The six transforms you speak about is the number that can be associated with a given crypto map. The ASA itself can define a pool of as many as you have by multiplying the number of available security protocols and algorithms. In my experience, a single transform should suffice for a given crypto map.

If you are fortunate enough to control both ends of your tunnels (or can agree on a common transform set with the remote site admins) you can get by with only a single defined transform set used for all your VPNs.

The second policy you mentioned above (crypto ikev1 policy 65535) would be a catch-all policy since it has priority number 65535 - the last possible number. This would serve as a backup in case no earlier policy match was found. 

First, a big thank you for the quick response - and one I mostly understand. I was thinking more like "stuck with" and not "control", but it's not really that bad. As of 3 weeks ago I'm it and do have full control over both ends but that means I have to be careful and sure of what I am doing. It's all me if things go south. 
There is no IT staff at any of our remote offices and asking clerical staff or the social workers/counselors, well..... so I can't make a mistake that means I lose remote access through SSH or other means.
I'm curious and like challenges and was determined to stabilize things and fix the problems. I've decided these offices have lived with the issues long enough and jumped in with both feet.

If I read you correctly out of that list of transform-sets, the first 10 are generic and not used or assigned, where the last, the 11th IS, and given a name that matches us - IVRS. If that is correct, the first 10 can be removed. 

Then it would appear that if the home office 5510s have policies that match perfectly the policies on the 20-some 5505s in the remote offices, there is no need for the second crypto ikev1 policy (the 65535) - I assume that may also be a "default" and allow devices to connect if controlled by different admins have nothing else specifically defined. I guess maybe it's a "master key" in a way?

So that I have this in terms or words I can't make a mistake with -

A. The first 10 transform-sets can go away on the 5505s. This is because there is that 11th, which is defined specifically and given a name matching us, and it is the ONLY one of those 11 used -and the line that defines which is used is this one:
crypto map ivrsmap 10 set ikev1 transform-set vpnivrs

B. This second policy can go away as well as long as the home-office 5510s have this same policy defined or configured, and all of the other 5505s also have this - as long as all of our devices have the same first policy in place, we'd be ok - and this one could go away:
crypto ikev1 policy 65535
 authentication pre-share
 encryption 3des
 hash sha    
 group 2
 lifetime 86400

Any caveats or DO THIS FIRST! warnings - or can I simply remove those 10 transform-sets and the second ikev1 policy?

I've been digging into these for the entire time since our senior admin retired. I have done exhaustive searches and found that quite often the most helpful information came from these very forums - because it was real people like me, not a trained Cisco engineer or developer, asking questions I could understand and relate to - but more - the replies were easily understood as well. For me the place to find answers to my specific questions or needs was obvious - a friendly place with helpful answers.

My work day ends in 2 minutes, so it would be Monday before I catch up here again, but thanks for the info so far. That's a big help and does match with my gut feelings at this point.

You're welcome.

With regards to your follow-on questions A and B - both yes.

DO FIRST - make a backup of your configuration. This is a good idea when making changes of any kind. If you have any doubts, backup before and backup after. Do a side-side comparison to check your work. (I use ExamDiff to make comparing long text files less prone to human error.)

When you have preshared keys (which show up as hashes when you do a simple "show run") you should use the following (while logging your terminal output):

term pager 0

more system:running-config

The first line will make the whole output scroll by at once and the second will print the configuration with any preshared keys in plain text.

This is a big help. 
I always did "sh run" and then copied it all into QWINED editor and removed the extraneous lines from the paging, replaced the hashes and so on. Besides answers to my original novice questions your tips will save me time.
I have used windiff but will take a look at ExamDiff as I'm always looking for different or better tools or alternatives. 
I'm building a document/file of "tips for ASAs" to make life easier for me and that's where your tips and info are going to go.

I've got other questions - but one thing at a time, and in new threads.
I believe I can call this one answered (and in a manner where I could understand why it was being done).

Thanks again.