On further study of the iskampd.conf man page, I am thinking that you
may be correct by turning you attention to the isakmpd.conf as a
possible trouble spot.
I notice that you specified group mod768 (Diffie -Hellman group 1)in
your ipsec statements. As I said, not having had occasion to run a
VPN before using OpenBSD as an endpoint, I am having to generalize
from all the other VPN setups that I have done. Generally, the
Diffie-Hellman group is only relevant in two places, one being the
'main' mode for phase 1 and the other being for PFS in phase 2 (-if-
PFS is enabled). I see that the isakmpd normally uses DH2 by default
for 'main' mode (so claims the man page), and this can be defined
otherwise (e.g. DH 1) if preferred. I -suspect- that the DH group
specified in the ipsecd.conf is not relevant to 'main' mode; it is
perhaps used only when PFS is configured.
So a possible problem might be that site #1 is using DH 2 for its
proposal and an edit to isakmpd.conf may be the solution. Or, an
alternative might be to reconfigure the VPN 3000 to use DH 2. If you
have PFS enabled, deconfigure it for now in order to simplify
things. Once you've got the VPN running, you can play around with
PFS enablement if you really need it.
I'm afraid I'm a bit hindered by having not used OpenBSD in any of
the 70+ VPNs I've set up in the past. Mostly, I've worked with
CheckPoint, Juniper, Cisco routers/PIX/ASA/VPN300, SonicWall, Nortel,
and LinkSys. None of my customers have selected OpenBSD for VPN, yet.
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.
_________________________________________________________________
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
[EMAIL PROTECTED]
_________________________________________________________________
Win a Zunemake MSN. your homepage for your chance to win! http://
homepage.msn.com/zune?icid=hmetagline
--
William Bloom
[EMAIL PROTECTED]
