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