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