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
