IPsec Bit-n-Pieces

From Secure Computing Wiki
Revision as of 14:20, 16 October 2008 by 74.95.66.25 (Talk) (New page: <blockquote> --- 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> than...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

--- 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