>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.
>>>>
>>>>_________________________________________________________________
>>>>With tax season right around the corner, make sure to follow these few
>>>>simple tips.
http://articles.moneycentral.msn.com/ Taxes/
>>>>PreparationTips/PreparationTips.aspx?icid=HMFebtagline
>>>>
>>>
>>>--
>>>William Bloom
>>>williambloom@mac.com
>>>
>>>
>>>
>>
>>_________________________________________________________________
>>Win a Zunemake MSN. your homepage for your chance to win! http://
>>homepage.msn.com/zune?icid=hmetagline
>>
>
>--
>William Bloom
>williambloom@mac.com
>
>
>
