Finally got this to work. Here's the config that ended up working.
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 <[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 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 <[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]
_________________________________________________________________
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
