On Sun, Feb 25 2007 at 06:20, c l wrote: > Finally got this to work. Here's the config that ended up working. > > I'm not sure why I didn't notice before but the quick mode stuff wasn't > setup correctly. > > ipsec.conf > ike esp from 192.168.1.0/24 to 10.10.0.0/16 peer 2.2.2.2 \ > main auth hmac-sha1 enc 3des group modp768 \ > quick auth hmac-sha1 enc 3des group none psk openbsdrules > There is another potential problem with this configuration. You did not specify the ike mode: active, passive, dynamic.
The default behavior is to use "active". "dynamic" mode comes with DPD (Dead Peer Detection) and don't work with some devices. I remember a post here stating that it doesn't interoperate with Netscreen at the other end. You're lucky to not enter into this problem :) Routing in the enc0 interface is done with the flow statement in the ipsec.conf file. Your ipsec.conf should include a line like this one : flow esp from 192.168.1.0/24 to 10.10.0.0/16 peer peer 2.2.2.2 Good luck! Claer > cisco > IKE proposal > authentication mode - presharedkeys > authentication algorithm - sha/hmac-160 > encryption - 3DES-168 > DH Group - 1 768-bits > Lifetime - 3600seconds > > Lan-to-Lan connection > interface - external(2.2.2.2) > connection type - bi-directional > peer - 1.1.1.1 > presharedkey - openbsdrules > authentication - esp/sha/hmac160 > local network - 10.10.0.0 (wildcard mask 0.0.255.255) > remote network - 192.168.1.0 (wildcard mask 0.0.0.255) > > SA > authentication - esp/sha/hmac160 > encryption - 3DES-168 > mode - tunnel > Lifetime - 1200seconds > > > > Now I just have to figure out the routing :) > > > > > >From: William Bloom <[EMAIL PROTECTED]> > >To: c l <[EMAIL PROTECTED]> > >CC: misc@openbsd.org > >Subject: Re: site-to-site vpn 4.0 to cisco 3000 > >Date: Sun, 25 Feb 2007 18:53:12 -0700 > > > >The man page for isakpd.conf indeed sheds some light, there's an example > >in that page that show's how to specify lifetimes for both phases... > > > > [General] > > Default-phase-1-lifetime= 3600,60:86400 > > Default-phase-2-lifetime= 1200,60:86400 > > > >At this point, if the lifetimes indeed agree, then I myself would be a > >little puzzled over why the proposal would be rejected. Both endpoints > >are configured to use the peer address as the ID? At first blush, your > >settings seem all kosher. > > > >I would agree, though, that it certainly appears that there must still be > >some sort of inconsistency between the proposals. > > > >Another suggestion... > > > >It appears that you've been trying to initiate the VPN from one end, > >perhaps the OpenBSD end. Probably by sending a ping from the 1st site to > >the 2nd. Restart both ends to clear out any SAs that have been > >negotiated and try to ping from the -other- end in order to see what > >happens when the VPN negotiation is initiated the opposite direction. > >The log entries might show something useful. > > > >Also, did the OpenBSD logs show any detail of the failure from the last > >attempts apart from the mismatched SA queries? > > > > > >Bill > > > > > >On Feb 25, 2007, at 14:48, c l wrote: > > > >>Hello, thanks for the reply, it helped if I'm not mistaken. I think > >>I'm getting closer but still no joy. See below. > >> > >>>From: William Bloom <[EMAIL PROTECTED]> > >>>To: c l <[EMAIL PROTECTED]> > >>>CC: misc@openbsd.org > >>>Subject: Re: site-to-site vpn 4.0 to cisco 3000 > >>>Date: Sun, 25 Feb 2007 14:02:13 -0700 > >>> > >>>I've setup maybe 78 LAN-to-LAN VPNs between my datacenter and other > >>>sites of customers and partners. However, I haven't had occasion to > >>>use OpenBSD as a VPN endpoint yet and I'm not an expert on the ike/ > >>>ipsec features of OpenBSD. Having said that, I've done quite a bit of > >>>VPN troubleshooting in the past, so I'll take a stab at this in > >>>general terms... > >>> > >>>My reading of the three 'ike esp' statements in ipsec.conf is that > >>>you've declared three sets of SAs on the OpenBSD endpoint, all to peer > >>>2.2.2.2 - one SA between the interior address spaces of the two > >>>locations, a second between the endpoint address of the 1st location > >>>and the interior address space of the 2nd, and a third between the > >>>endpoint addresses. That third one certainly catches my attention > >>>since I know that -some- pieces of equipment (particularly the PIX, > >>>ASA, and I believe the Juniper although I've never confirmed this for > >>>a Cisco 3000) hate the idea of having their own endpoint address > >>>included in the encryption domain. This seems likely to me as a cause > >>>for the rejection. This is something that IKE might negotiate on > >>>-some- manufacturer's equipment but not others. In most cases, > >>>there's no need for the endpoints to participate in the encryption > >>>domain since they aren't application servers - they only need to > >>>exchange IKE messages and then simply pass IPsec to/from their > >>>respective protected address spaces. > >>> > >>>So my suggestion would be to strike that third 'ike esp' statement and > >>>then see what difference that makes in the log. As a special note, do > >>>be aware that this means that you probably won't be able to ping the > >>>2.2.2.2 address from the 1st site (encryption enforcement on the Cisco > >>>will deny this, since you're pining from an address space at the 1st > >>>site that's covered by the VPN proposal and yet 2.2.2.2 is not in the > >>>encryption domain). If you need to troubleshoot the Cisco by pinging > >>>it, then you'll have to do so from a point -outside- the OpenBSD VPN > >>>endpoint. > >> > >>This did in fact change the behavior. First I did as you suggested and > >>struck the statement for the two end points. The logs showed a similar > >>message as before but this time it complained about the src: 1.1.1.1 > >>dst: 10.10.x.x tunnel. So I removed that one as well. So now my > >>ipsec.conf has just the one line in it. > >> > >>ike esp from 192.168.1.0/24 to 10.10.0.0/16 peer 2.2.2.2 \ > >> main auth hmac-sha1 enc 3des group modp768 psk openbsdrules > >> > >>This gives me a different result. Here is the output from the cisco log. > >> > >>2 02/25/2007 15:28:21.210 SEV=5 IKE/172 RPT=7437 1.1.1.1 > >>Group [1.1.1.1] > >>Automatic NAT Detection Status: > >> Remote end is NOT behind a NAT device > >> This end is NOT behind a NAT device > >> > >>6 02/25/2007 15:28:21.310 SEV=4 IKE/119 RPT=6722 1.1.1.1 > >>Group [1.1.1.1] > >>PHASE 1 COMPLETED > >> > >>7 02/25/2007 15:28:21.310 SEV=4 AUTH/22 RPT=6617 1.1.1.1 > >>User [1.1.1.1] Group [1.1.1.1] connected, Session Type: IPSec/LAN-to > >>-LAN > >> > >>9 02/25/2007 15:28:21.310 SEV=4 AUTH/84 RPT=86 > >>LAN-to-LAN tunnel to headend device 1.1.1.1 connected > >> > >>10 02/25/2007 15:28:21.400 SEV=5 IKE/35 RPT=30 1.1.1.1 > >>Group [1.1.1.1] > >>Received remote IP Proxy Subnet data in ID Payload: > >>Address 192.168.1.0, Mask 255.255.255.0, Protocol 0, Port 0 > >> > >>13 02/25/2007 15:28:21.400 SEV=5 IKE/34 RPT=9176 1.1.1.1 > >>Group [1.1.1.1] > >>Received local IP Proxy Subnet data in ID Payload: > >>Address 10.10.0.0, Mask 255.255.0.0, Protocol 0, Port 0 > >> > >>16 02/25/2007 15:28:21.400 SEV=5 IKE/66 RPT=9174 1.1.1.1 > >>Group [1.1.1.1] > >>IKE Remote Peer configured for SA: L2L: to_openbsd > >> > >>17 02/25/2007 15:28:21.400 SEV=4 IKE/227 RPT=30 1.1.1.1 > >>Group [1.1.1.1] > >>All IPSec SA proposals found unacceptable! > >> > >>18 02/25/2007 15:28:21.400 SEV=4 IKEDBG/97 RPT=86 1.1.1.1 > >>Group [1.1.1.1] > >>QM FSM error (P2 struct &0xe622d7c, mess id 0x58c640ca)! > >> > >> > >>Looks like it's getting a bit farther now. The /var/log/message still > >>give me the dubious ID message along with 'giving up on exchange > >>192.168.1.0/16-10.10.0.0/16, no response from peer'. > >> > >>Something must not match between the SA's > >> > >> > >>> > >>>I haven't googled, as you have, for VPN examples involving OpenBSD and > >>>Cisco VPN 3000, but it would surprise me if someone had configured a > >>>VPN 3000 to include its endpoint address as part of an encryption > >>>domain successfully. > >>> > >>>Another observation, even though it may not be relevant to the symptom > >>>you describe, is that I don't see the phase 1/2 SA lifetimes spelled > >>>out in your OpenBSD configuration even though they are spelled out on > >>>the Cisco device. I can't tell whether your IKE negotiation has > >>>gotten far enough to enforce lifetimes since it choked on the policy > >>>failure for 1.1.1.1/2.2.2.2. For all I know, maybe you've selected > >>>lifetimes on the Cisco that agree with the default lifetimes that > >>>OpenBSD uses. If so, I'd suggest that you explicitly spell out the > >>>lifetimes on the OpenBSD end since IKE/IPsec software (at large, not > >>>necessarily especially for OpenBSD) is somewhat notorious for changing > >>>defaults from time to time. If you accept defaults for things, you > >>>might find one day when upgrade to a future release of OpenBSD that > >>>the VPN suddenly stops negotiating. > >> > >>I specifically changed the cisco's SA lifetimes to 3600 and 1200 because > >>the isakmpd man page says those are the defaults. Maybe I mis-read it? > >>I'll look again. Also the ipsec.conf man page doesn't say anything > >>about specifying the lifetime. Where would I specify this on the > >>OpenBSD box? Does it go in the /etc/isakmpd/ isakmpd.conf file? > >> > >>I'm thinking these values don't jive between the two and that's why I > >>see the > >>"All IPSec SA proposals found unacceptable!" message. > >> > >>Oh and I turned up debugging on isakmpd. Not sure which classes to > >>fiddle with since A=99 gives me tons. I did see some messages about "no > >>sa query matched" > >> > >> > >> > >>> > >>>There's also another reason to spell out lifetimes. Turns out that > >>>some VPN equipment is actually accommodating about proposed lifetime > >>>values from the remote end that don't agree with the local policy, > >>>while other equipment is not. So when interoperating two unlike VPN > >>>platforms (e.g. OpenBSD and Cisco), it's possible to get into a > >>>situation where one endpoint can initiate a VPN tunnel while other > >>>cannot (negotiation only works one way). Spelling out lifetimes on > >>>both ends avoids this situation. BTW, this sort of thing can also > >>>happen with a Diffie- Hellman group mismatch for phase 1, but I see > >>>that you've already spelled that one out on both ends. > >>> > >>>Also, a bit off subject, it is goodness to keep the time sync'd on > >>>both endpoints (e.g. NTP). > >>> > >>> > >>>Bill > >>> > >>>On Feb 25, 2007, at 10:23, c l wrote: > >>> > >>>>Hello list, > >>>> > >>>>I'm trying to get a site-to-site tunnel running between a 4.0 box and > >>>>a cisco 3000 concentrator. > >>>> > >>>>Here's the networks... (ip's changed to protect the innocent) > >>>> > >>>>192.168.1.x [OpenBSD 4.0] 1.1.1.1 <-> internet <-> 2.2.2.2 > >>>>[cisco 3000] 10.10.x.x > >>>> > >>>>My ipsec.conf looks like this.... > >>>> > >>>>ike esp from 192.168.1.0/24 to 10.10.0.0/16 peer 2.2.2.2 \ > >>>> main auth hmac-sha1 enc 3des group modp768 psk openbsdrules > >>>>ike esp from 1.1.1.1 to 10.10.0.0/16 peer 2.2.2.2 \ > >>>> main auth hmac-sha1 enc 3des group modp768 psk openbsdrules > >>>>ike esp from 1.1.1.1 to 2.2.2.2 \ > >>>> main auth hmac-sha1 enc 3des group modp768 psk openbsdrules > >>>> > >>>>On the cisco I've created IKE proposals, defined a LAN-to-LAN > >>>>connection, and SAs like this... > >>>> > >>>>IKE proposal > >>>>authentication - presharedkeys > >>>>encryption - 3DES-168 > >>>>DH Group - 1 768-bits > >>>>Lifetime - 3600seconds > >>>> > >>>>Lan-to-Lan connection > >>>>interface - external(2.2.2.2) > >>>>connection type - bi-directional > >>>>peer - 1.1.1.1 > >>>>presharedkey - openbsdrules > >>>>authentication - esp/sha/hmac160 > >>>>local network - 10.10.0.0 (wildcard mask 0.0.255.255) > >>>>remote network - 192.168.1.0 (wildcard mask 0.0.0.255) > >>>> > >>>>SA > >>>>authentication - esp/sha/hmac160 > >>>>encryption - 3DES-168 > >>>>mode - tunnel > >>>>Lifetime - 1200seconds > >>>> > >>>> > >>>>On the OpenBSD box I start isakmpd with 'isakmpd -K', then ipsecctl > >>>>-f /etc/ipsec.conf > >>>> > >>>>After a bit of time I see this in /var/log/messages > >>>>isakmpd[18700]: ipsec_validate_id_information: dubious ID information > >>>>accepted > >>>> > >>>> > >>>>And the cisco log shows this.... > >>>> > >>>>2 02/25/2007 10:37:16.280 SEV=5 IKE/172 RPT=7394 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>Automatic NAT Detection Status: > >>>> Remote end is NOT behind a NAT device > >>>> This end is NOT behind a NAT device > >>>> > >>>>6 02/25/2007 10:37:16.380 SEV=4 IKE/119 RPT=6680 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>PHASE 1 COMPLETED > >>>> > >>>>7 02/25/2007 10:37:16.380 SEV=4 AUTH/22 RPT=6575 1.1.1.1 > >>>>User [1.1.1.1] Group [1.1.1.1] connected, Session Type: IPSec/LAN-to > >>>>-LAN > >>>> > >>>>9 02/25/2007 10:37:16.380 SEV=4 AUTH/84 RPT=52 > >>>>LAN-to-LAN tunnel to headend device 1.1.1.1 connected > >>>> > >>>>10 02/25/2007 10:37:16.500 SEV=5 IKE/25 RPT=9162 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>Received remote Proxy Host data in ID Payload: > >>>>Address 1.1.1.1, Protocol 0, Port 0 > >>>> > >>>>13 02/25/2007 10:37:16.500 SEV=5 IKE/24 RPT=27 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>Received local Proxy Host data in ID Payload: > >>>>Address 2.2.2.2, Protocol 0, Port 0 > >>>> > >>>>16 02/25/2007 10:37:16.500 SEV=4 IKE/61 RPT=27 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>Tunnel rejected: Policy not found for Src:1.1.1.1, Dst: 2.2.2.2! > >>>> > >>>>18 02/25/2007 10:37:16.500 SEV=4 IKEDBG/97 RPT=52 1.1.1.1 > >>>>Group [1.1.1.1] > >>>>QM FSM error (P2 struct &0xe7ed120, mess id 0xac462db5)! > >>>>&0xe7ed120, mess id 0xac462db5)! > >>>> > >>>> > >>>> > >>>>Any ideas why I'm getting the "tunnel rejected" error? Does anyone > >>>>see any glaring mistakes? After searching the archives and > >>>>google'ing, I gather other folks are doing this without issue. > >>>> > >>>>I have complete control over both devices so if there's any other > >>>>info I can provide let me know. > >>>> > >>>>I realize this isn't a cisco support list so if it's the cisco's > >>>>fault I'll go bother someone else. > >>>> > >>>> > >>>>I appreciate your time, thank you. > >>>>please cc me as I'm not subscribed to the list.
