14:17 <ecrist> fwiw, I got my CCNA about 8 years ago, so I can sort of follow the logic. You cleared up the majority of fuzziness for me, however.

14:17 <ecrist> fwiw, I got my CCNA about 8 years ago, so I can sort of follow the logic. You cleared up the majority of fuzziness for me, however.

14:17 <einval> hehe, cool

14:17 <einval> hehe, cool

−

</blockquote>

+

</pre>

Latest revision as of 13:21, 16 October 2008

--- Log opened Thu Oct 16 13:52:48 2008
13:52 -!- Irssi: Starting query in freenode with einval
13:52 <einval> i think its better to outline this via pm ;)
13:53 <ecrist> thanks
13:53 <ecrist> I've got a crypto isakmp policy 1; enc 3des
13:53 <ecrist> authentication pre-share
13:53 <ecrist> group 2
13:54 <einval> k
13:54 <einval> its not what the peer expects
13:54 <ecrist> the 'new' client also mentions IPsec Hash of SHA1-HMAC
13:54 <einval> you need an ike policy that matches exactly what the peer requires, so i assume the following:
13:54 <einval> cry isa pol 10
13:54 <einval> authen pre-share
13:55 <einval> enc 3des
13:55 <einval> hash sha
13:55 <ecrist> ok, but I already have an isakmp policy - can I have more than one?
13:55 <einval> dont know what the peer expects for DH group
13:55 <einval> yes
13:55 <ecrist> group 2
13:56 <einval> they get offered/compared also in the sequence
13:56 <einval> so, 1 first, then 2 (or 10) etc.
13:56 <ecrist> ah, I think that's what I was missing.
13:56 <ecrist> so, is there a limit to how many connections we can put on this unit?
13:56 <einval> one thing is that an isakmp policy is for all vpn peers
13:56 <ecrist> what does that mean?
13:57 <einval> an ipsec policy (in the crypto map) is specific per peer
13:57 <einval> lets step back
13:57 <ecrist> ok
13:57 <einval> an IPSec VPN negotiation has two phases
13:57 <einval> first, there is IKE
13:57 <einval> it negotiates an secure channel over an unsecure media
13:58 <einval> allowing the two peers to talk in private, if you will
13:58 <einval> after this is done
13:58 <einval> IPSec will be negotiated
13:58 <ecrist> ok
13:58 <einval> this is responsible to define methods to transport payload data securely
13:58 <einval> so
13:59 <einval> the isakmp policy is for IKE
13:59 <einval> the crypto map is for IPSec
13:59 <ecrist> ok
14:00 <einval> you only can have multiple isakmp policy porposals (the sequences)
14:00 <ecrist> so, I can have as man isakmp policies as I want, as long as one matches what the other side wants.
14:00 <einval> exaclty
14:00 <ecrist> great, that explains a lot
14:00 <ecrist> and then I have crypto map sequences, which set up the IPsec
14:01 <einval> yeah
14:01 <ecrist> on crypto map per interface, many sequence sets per crypto map
14:01 <ecrist> s/^on/one/
14:01 <einval> the logic is that you can only have a single crypto map bound to an interface, but this interface may serve lots of peers
14:01 * einval nods
14:02 <ecrist> now that makes sense.
14:02 <ecrist> so, from my client's config sheet (they do more cisco vpn than I do)
14:03 <ecrist> the ipsec part of things (you already did the other for me) says 3des, group 2, sha1-hmac with 28,800 seconds
14:03 <ecrist> that would be transform-set sha1-hmac, right?
14:03 <ecrist> for the crypto map?
14:03 <einval> its a little more complicated
14:04 <einval> the crypto map is where everything is put together
14:04 <einval> the pieces to it are:
14:04 <einval> an access-list that describes the vpn traffic
14:04 <ecrist> ok, so you know, I'm looking at their config request with one of my working ipsec vpns to try and match things together, mentally.
14:05 <einval> i see
14:05 <ecrist> I understand access list stuff
14:05 <ecrist> it's the crypto stuff that's got me conflustered.
14:05 <einval> yeah, only explaining what is required there, not every bit of configuration ;)
14:06 <einval> so, the acl (match address)
14:06 <einval> the peer ip (set peer x.x.x.x)
14:06 <einval> the pfs group, if requested (set pfs)
14:06 <einval> and the ipsec transform set (set transform)
14:06 <einval> the transform set must be configured before
14:07 <einval> cry ipsec transform <name> esp-3des esp-sha
14:07 <einval> thats basically it
14:08 <ecrist> ok, so how do I figure out the transform set from their data?
14:08 <einval> cry ipsec transform ESP-3DES-SHA esp-3des esp-sha
14:09 <einval> then do "set transform ESP-3DES-SHA" in the crypto map
14:09 <ecrist> they mention HMAC, too
14:09 <ecrist> sha1-hmac
14:10 <ecrist> so, would it be
14:10 <ecrist> crypto ipsec transform-set ESP-3DES-SHA1 esp-3des esp-sha-hmac
14:10 <einval> hashed mac, yes, its included in esp-sha
14:10 <einval> yes
14:10 <ecrist> ok
14:10 <ecrist> if you're ever in Minneapolis, I owe you a beer. ;)
14:11 <einval> thanks ;)
14:12 <einval> about the time value, you dont need to specify it, both peers will negotiate to the shorter one
14:12 <ecrist> ok, good to know.
14:13 <ecrist> you've helped me sort this out, I really appreciate it
14:13 <einval> you are welcome
14:14 <einval> altough cisco did a great job to make it simple as possible, ipsec concepts can be hard to grasp, so the IOS logic is confusing
14:17 <ecrist> fwiw, I got my CCNA about 8 years ago, so I can sort of follow the logic. You cleared up the majority of fuzziness for me, however.
14:17 <einval> hehe, cool