>
> 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
>
>
> 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
>> 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
>>
>>
>>
>
> _________________________________________________________________
> Want a degree but can't afford to quit? Top school degrees online -
> in as fast as 1 year
http://forms.nextag.com/goto.jsp?url=/serv/
> main/buyer/education.jsp?
> doSearch=n&tm=y&search=education_text_links_88_h288c&s=4079&p=5116
>
