> 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
> >To: c l
> >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
> >>>To: c l
> >>>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.
