[Openswan Users] Is OpenSWAN a good method for this?

[Whit Blauvelt]

Hi,

Apologies for asking such a general question. We were using FreeSWAN
internally some years back, then switched to OpenVPN, which has been great
for that. But now we're needing to return to IPsec to tunnel from our Linux
firewall to a remote Cisco 5510. The current state of documentation for
Linux IPsec options is sparse and disorganized. So my questions are quite
basic:

For a Linux-Cisco IPsec tunnel, are each of these equally compatible with
the Cisco?

- OpenSWAN
- KAME (ipsec-tools)
- OpenBSD's isakmpd

For Ubuntu 8.04 (with kernel 2.6.24-19-server, and no X), which of those
options installs and works most smoothly? (I note that Ubuntu seems to be
largely ignoring bugs filed against OpenSWAN - see
"https://bugs.launchpad.net/ubuntu/+source/openswan/+bugs".)

At the Cisco end they prefer as defaults (but will alter if required):

Phase 1 - pre-g2-3des-sha-86400s
Phase 2 - pfs2-esp-3des-sha-28800s
and a PSK (not cert)

Are there known gotchas there for Linux? For OpenSWAN? I'm recalling
FreeSWAN having some problems with pfs; does that remain an issue?

Looking at the OpenSWAN wiki, I see for instance a comparison of Linux IPsec
options without KAME or isakmpd included. Googling on the various
combinations, I find of plenty of problem reports and partial recipes, but
little in the way of complete accounts of success. It's obvious from the
volume on this mailing list that OpenSWAN is still a viable option. It's
fully possible I've missed answers to exactly the questions here - but my
eyes glaze over after sampling so many dozens of threads. If answers are
forthcoming, I'll try to integrate them into the OpenSWAN wiki, so at least
next time someone like me won't have to address the list for such basic
stuff.

Best,
Whit

[Paul Wouters]

Post by Whit Blauvelt
For a Linux-Cisco IPsec tunnel, are each of these equally compatible with
the Cisco?
- OpenSWAN
- KAME (ipsec-tools)
- OpenBSD's isakmpd

I don't think anyone can really tell you that, unless someone has done a
comparative analyses.

Post by Whit Blauvelt
For Ubuntu 8.04 (with kernel 2.6.24-19-server, and no X), which of those
options installs and works most smoothly? (I note that Ubuntu seems to be
largely ignoring bugs filed against OpenSWAN - see
"https://bugs.launchpad.net/ubuntu/+source/openswan/+bugs".)

Debian/ubuntu ships horribly old openswan packages.

Post by Whit Blauvelt
Phase 1 - pre-g2-3des-sha-86400s
Phase 2 - pfs2-esp-3des-sha-28800s
and a PSK (not cert)

Should work.

Post by Whit Blauvelt
Are there known gotchas there for Linux? For OpenSWAN? I'm recalling
FreeSWAN having some problems with pfs; does that remain an issue?

I don't remember freeswan having problems with pfs. The only special case with
pfs is that freeswan/openswan always accepted pfs even when pfs=no (because
it never hurts) and in some cases that could backfire at rekey time.

Post by Whit Blauvelt
Looking at the OpenSWAN wiki, I see for instance a comparison of Linux IPsec
options without KAME or isakmpd included. Googling on the various
combinations, I find of plenty of problem reports and partial recipes, but
little in the way of complete accounts of success. It's obvious from the
volume on this mailing list that OpenSWAN is still a viable option. It's
fully possible I've missed answers to exactly the questions here - but my
eyes glaze over after sampling so many dozens of threads. If answers are
forthcoming, I'll try to integrate them into the OpenSWAN wiki, so at least
next time someone like me won't have to address the list for such basic
stuff.

Documentation and wiki needs a lot of work :( Helping there would be awesome.
The mailinglist archives should be a gold mine of information from previous
answers (I've been doing that for almost 10 years).
However, we do keep the man pages up to date, and do ship with some examples
in /etc/ipsec.d/examples/

Paul

[Whit Blauvelt]

Post by Paul Wouters
Debian/ubuntu ships horribly old openswan packages.

I've installed openswan-2.6.24 from source. Note compiling it required
libgmp3-dev, bison and flex, in addition to what I already happened to have
installed on the Ubuntu box.

Post by Paul Wouters

Post by Whit Blauvelt
Phase 1 - pre-g2-3des-sha-86400s
Phase 2 - pfs2-esp-3des-sha-28800s
and a PSK (not cert)

Should work.

At the moment I'm stuck on:

# ipsec setup --start
ipsec_setup: Starting Openswan IPsec U2.6.24/K2.6.24-19-server...
ipsec_setup: no default routes detected

Is that a fatal error? My routing rules and tables are complex, so it's not
going to find a default route where it expects to if it's being simple
minded. I do have a specific route set to the other end:

# ip ro ls
yy.yy.yy.222 via xx.xx.xx.97 dev eth5 src xx.xx.xx.114
...

And I can ping it by that route.

My ipsec.conf looks like:

version 2.0

config setup
klipsdebug="none"
plutodebug="all"
uniqueids=yes
protostack=netkey

conn cisco
type=tunnel
left=xx.xx.xx.114 # my IP
leftsubnet=192.168.1.0/24
leftnexthop=xx.xx.xx.97
leftid=@<fqdn>
right=yy.yy.yy.222 # IP address of Cisco ASA 5510
rightsubnet=zz.zz.zz.192/26 # LAN behind Cisco
rightid=@<otherend>
keyingtries=0
pfs=yes
auto=add
auth=esp
esp=3DES-SHA1
ike=3DES-SHA1
authby=secret

And it's obviously not getting anywhere yet:

# ipsec auto --up cisco
104 "cisco" #1: STATE_MAIN_I1: initiate
010 "cisco" #1: STATE_MAIN_I1: retransmission; will wait 20s for response
...

No sign this is an iptables problem - I've got the rules re-enabled there
that were working a while back for freeswan.

Thanks for any clues,

Whit

[Whit Blauvelt]

Post by Whit Blauvelt
# ipsec setup --start
ipsec_setup: Starting Openswan IPsec U2.6.24/K2.6.24-19-server...
ipsec_setup: no default routes detected
Is that a fatal error? ...

No, that wasn't fatal. I needed to adjust my firewall rules. Which got me to
the next hangup:

# ipsec auto --up cisco
104 "cisco" #1: STATE_MAIN_I1: initiate
003 "cisco" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
106 "cisco" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "cisco" #1: received Vendor ID payload [Cisco-Unity]
003 "cisco" #1: received Vendor ID payload [XAUTH]
003 "cisco" #1: ignoring unknown Vendor ID payload [3c7dcb3b07c043b07e8648c9c7e10420]
003 "cisco" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
108 "cisco" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "cisco" #1: received Vendor ID payload [Dead Peer Detection]
004 "cisco" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "cisco" #2: STATE_QUICK_I1: initiate
010 "cisco" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "cisco" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "cisco" #2: max number of retransmissions (2) reached STATE_QUICK_I1.
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "cisco" #2: starting keying attempt 2 of an unlimited number, but releasing whack

Any hints appreciated.

Whit

[Avesh Agarwal]

Post by Whit Blauvelt

Post by Whit Blauvelt
# ipsec setup --start
ipsec_setup: Starting Openswan IPsec U2.6.24/K2.6.24-19-server...
ipsec_setup: no default routes detected
Is that a fatal error? ...

No, that wasn't fatal. I needed to adjust my firewall rules. Which got me to
# ipsec auto --up cisco
104 "cisco" #1: STATE_MAIN_I1: initiate
003 "cisco" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
106 "cisco" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "cisco" #1: received Vendor ID payload [Cisco-Unity]
003 "cisco" #1: received Vendor ID payload [XAUTH]
003 "cisco" #1: ignoring unknown Vendor ID payload [3c7dcb3b07c043b07e8648c9c7e10420]
003 "cisco" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
108 "cisco" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "cisco" #1: received Vendor ID payload [Dead Peer Detection]
004 "cisco" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "cisco" #2: STATE_QUICK_I1: initiate
010 "cisco" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "cisco" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "cisco" #2: max number of retransmissions (2) reached STATE_QUICK_I1.
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals sent by
openswan end. Verify your cisco side settings (encryption lago, hash
algo and DH groups) with the ones you set with openswan and see if there
is any mismatch.

Avesh

Post by Whit Blauvelt
000 "cisco" #2: starting keying attempt 2 of an unlimited number, but releasing whack
Any hints appreciated.
Whit
_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Whit Blauvelt]

Post by Avesh Agarwal

Post by Whit Blauvelt
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals
sent by openswan end. Verify your cisco side settings (encryption
lago, hash algo and DH groups) with the ones you set with openswan
and see if there is any mismatch.

Thanks Avesh. I'm looking. But I can't see the mismatch yet. The Cisco (I'm
told) is set like this:

IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

And my ipsec.conf looks like this:

version 2.0

config setup
klipsdebug="none"
plutodebug="all"
uniqueids=yes
protostack=netkey

conn cisco
type=tunnel
left=xx.xx.xx.114 # my IP
leftsubnet=192.168.1.0/24
leftnexthop=xx.xx.xx.97
leftid=@<fqdn>
right=yy.yy.yy.222 # IP address of Cisco ASA 5510
rightsubnet=zz.zz.zz.192/26 # LAN behind Cisco
rightid=yy.yy.yy.222
keyingtries=0
pfs=yes
auto=add
auth=esp
esp=3DES-SHA1
ike=3DES-SHA1
authby=secret

The only thing that jumps at me is the possibility that "pfs2" at the Cisco
is not compatible with "pfs" at my end. Would that be the case? I see no
mention of pfs2 in the docs in the tar. But from a note elsewhere -
http://tristesse.org/OpenswanAnnoyances - it looks like Cisco's "pfs2" and
Openswan's "pfs" should be the same thing, right?

Another note in that same page suggests I may need nat_traversal=yes, but
that's not the fix as then I get:

003 "cisco" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected

with the same failure in the end.

Best,
Whit

[Avesh Agarwal]

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals
sent by openswan end. Verify your cisco side settings (encryption
lago, hash algo and DH groups) with the ones you set with openswan
and see if there is any mismatch.

Thanks Avesh. I'm looking. But I can't see the mismatch yet. The Cisco (I'm
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
that. Well, you can try following:

phase2=esp
phase2alg=3DES-SHA1;modp1024

Regards
Avesh

Post by Whit Blauvelt
version 2.0
config setup
klipsdebug="none"
plutodebug="all"
uniqueids=yes
protostack=netkey
conn cisco
type=tunnel
left=xx.xx.xx.114 # my IP
leftsubnet=192.168.1.0/24
leftnexthop=xx.xx.xx.97
right=yy.yy.yy.222 # IP address of Cisco ASA 5510
rightsubnet=zz.zz.zz.192/26 # LAN behind Cisco
rightid=yy.yy.yy.222
keyingtries=0
pfs=yes
auto=add
auth=esp
esp=3DES-SHA1
ike=3DES-SHA1
authby=secret
The only thing that jumps at me is the possibility that "pfs2" at the Cisco
is not compatible with "pfs" at my end. Would that be the case? I see no
mention of pfs2 in the docs in the tar. But from a note elsewhere -
http://tristesse.org/OpenswanAnnoyances - it looks like Cisco's "pfs2" and
Openswan's "pfs" should be the same thing, right?
Another note in that same page suggests I may need nat_traversal=yes, but
003 "cisco" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
with the same failure in the end.
Best,
Whit

[Paul Wouters]

Post by Avesh Agarwal

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals
sent by openswan end. Verify your cisco side settings (encryption
lago, hash algo and DH groups) with the ones you set with openswan
and see if there is any mismatch.

Thanks Avesh. I'm looking. But I can't see the mismatch yet. The Cisco (I'm
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
phase2=esp
phase2alg=3DES-SHA1;modp1024

The specs also did not mention whether to use Main Mode or Aggressive Mode.
If this fails, try adding aggrmode=yes

Paul

[Whit Blauvelt]

Post by Paul Wouters
The specs also did not mention whether to use Main Mode or Aggressive Mode.
If this fails, try adding aggrmode=yes

Thanks Paul. If that's the fix, it has implications I need to handle, since
simply adding it to the conn section produces first:

# ipsec auto --up cisco
024 need --listen before --initiate

and then on second invocation:

# ipsec auto --up cisco
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
112 "cisco" #1: STATE_AGGR_I1: initiate
003 "cisco" #1: Informational Exchange message must be encrypted
010 "cisco" #1: STATE_AGGR_I1: retransmission; will wait 20s for response
003 "cisco" #1: Informational Exchange message must be encrypted

Best,
Whit

[Avesh Agarwal]

Post by Whit Blauvelt

Post by Paul Wouters
The specs also did not mention whether to use Main Mode or Aggressive Mode.
If this fails, try adding aggrmode=yes

Thanks Paul. If that's the fix, it has implications I need to handle, since
# ipsec auto --up cisco
024 need --listen before --initiate
# ipsec auto --up cisco
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
112 "cisco" #1: STATE_AGGR_I1: initiate
003 "cisco" #1: Informational Exchange message must be encrypted
010 "cisco" #1: STATE_AGGR_I1: retransmission; will wait 20s for response
003 "cisco" #1: Informational Exchange message must be encrypted

Hello Whit,

Your earlier message suggested that your Cisco end is using "main mode"
because your first phase was established right. I believe that your main
issue is that DH group is not set correctly for phase2.

So either you can change "esp=3DES-SHA1" to "esp=3DES-SHA1;modp1024"

or you can remove this "esp=3DES-SHA1", and add following:
phase2=esp
phase2alg=3des-sha1-modp1024

Thanks and Regards
Avesh

Post by Whit Blauvelt
Best,
Whit
_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Whit Blauvelt]

Post by Avesh Agarwal
phase2=esp
phase2alg=3des-sha1-modp1024

To be precise, that's exactly what I did. No joy though.

Best,
Whit

[Paul Wouters]

Post by Whit Blauvelt
Thanks Paul. If that's the fix, it has implications I need to handle, since
# ipsec auto --up cisco
024 need --listen before --initiate

Is this an embedded system? This seems to show openswan is still starting
up and you have to wait with issuing the --up command.

Post by Whit Blauvelt
# ipsec auto --up cisco
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
003 "cisco" #1: multiple transforms were set in aggressive mode. Only first one used.
003 "cisco" #1: transform (5,2,2,0) ignored.
112 "cisco" #1: STATE_AGGR_I1: initiate
003 "cisco" #1: Informational Exchange message must be encrypted
010 "cisco" #1: STATE_AGGR_I1: retransmission; will wait 20s for response
003 "cisco" #1: Informational Exchange message must be encrypted

Well, that seems worse, so perhaps that is not the case here.

Paul

[Whit Blauvelt]

Post by Whit Blauvelt
Thanks Paul. If that's the fix, it has implications I need to handle, since
# ipsec auto --up cisco
024 need --listen before --initiate

Not embedded. It's a lightly-loaded quad-core Opteron. That message has only
occurred a couple of times. Guess if I'm automating startup I need a few
seconds delay after "ipsec setup --start" anyhow?

Thanks,
Whit

[Michael H. Warfield]

Hey Paul,

Post by Paul Wouters

Post by Avesh Agarwal

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals
sent by openswan end. Verify your cisco side settings (encryption
lago, hash algo and DH groups) with the ones you set with openswan
and see if there is any mismatch.

Thanks Avesh. I'm looking. But I can't see the mismatch yet. The Cisco (I'm
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
phase2=esp
phase2alg=3DES-SHA1;modp1024

The specs also did not mention whether to use Main Mode or Aggressive Mode.
If this fails, try adding aggrmode=yes

AFAICT, with those Cisco ASA's that's going to be a given. Certainly,
that's all vpnc supports and that's the designated client for them.

Recursing back to earlier discussions around this, the whole single
proposal thing seems problematical and a theme in a number of these
calls, once you get into aggressive mode. We now know that we can, in
fact, generate multiple proposals, provided the DH group is at least
kept constant, since that's what vpnc is doing. Fixing that would seem
to cover a wealth of sins with these Cisco boxes. Any hope for that?
I'm looking at some other aggressive mode and config server issues but I
stuck my nose into that particular stretch of code in pluto and it
looked a little on the intimidating side to to just roll my sleeves up
and dig into.

Post by Paul Wouters
Paul
_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Paul Wouters]

On Tue, 9 Mar 2010, Michael H. Warfield wrote:

[aggressive mode]

Post by Michael H. Warfield
We now know that we can, in
fact, generate multiple proposals, provided the DH group is at least
kept constant, since that's what vpnc is doing.

Note that "some implementation can do this" is not the same as being RFC
compliant. What is needed is the check with the proper RFC's to see if
this is indeed valid, and if so, update to code.

Post by Michael H. Warfield
Fixing that would seem
to cover a wealth of sins with these Cisco boxes. Any hope for that?

Though we'd gladly accept patches, I think people would rather put their
energy into IKEv2, then into fixing IKEv1 Aggressive Mode.

Michael (Richardson), can you perhaps tell us more about why Openswan
claims there can only be one proposal in Aggressive Mode?

Paul

[Michael Richardson]

We now know that we can, in fact, generate multiple proposals,
provided the DH group is at least kept constant, since that's
what vpnc is doing.

Paul> Note that "some implementation can do this" is not the same as
Paul> being RFC compliant. What is needed is the check with the
Paul> proper RFC's to see if this is indeed valid, and if so, update
Paul> to code.

Fixing that would seem to cover a wealth of sins with these Cisco
boxes. Any hope for that?

Paul> Though we'd gladly accept patches, I think people would rather
Paul> put their energy into IKEv2, then into fixing IKEv1 Aggressive
Paul> Mode.

Paul> Michael (Richardson), can you perhaps tell us more about why
Paul> Openswan claims there can only be one proposal in Aggressive
Paul> Mode?

The ISAKMP SA is created in exchange 1 in aggressive mode.
You have to send the exponent during that exchange, so you have to know
what DH group you are using before you start.

This is why you can not have multiple DH groups in aggressive mode, and
I'd say historically, that meant that you can only have one proposal,
since different DH groups was really the only parameter in historical
(Freeswan 1.xx) code.

The only other option was MD5 vs SHA1 then, and I think you have to also
pick which hash to use since you have to know which PRF to use to
generate keys as well (and in IKEv1, the hash negotiated is really the PRF).

Maybe in concept, you can propose 3DES or AES128 in aggressive mode.
I'd have to spend some time thinking about why that might not be
acceptable.

Frankly --- why not put in a support request to CISCO and make them do
some testing, or explain why their product isn't compliant with the RFP
you sent out?

[Paul Wouters]

Post by Michael Richardson
The ISAKMP SA is created in exchange 1 in aggressive mode.
You have to send the exponent during that exchange, so you have to know
what DH group you are using before you start.
This is why you can not have multiple DH groups in aggressive mode, and
I'd say historically, that meant that you can only have one proposal,
since different DH groups was really the only parameter in historical
(Freeswan 1.xx) code.
The only other option was MD5 vs SHA1 then, and I think you have to also
pick which hash to use since you have to know which PRF to use to
generate keys as well (and in IKEv1, the hash negotiated is really the PRF).
Maybe in concept, you can propose 3DES or AES128 in aggressive mode.
I'd have to spend some time thinking about why that might not be
acceptable.
Frankly --- why not put in a support request to CISCO and make them do
some testing, or explain why their product isn't compliant with the RFP
you sent out?

Thanks, I've slightly rewritten this text and added it to the ipsec.conf
man page of the aggrmode= option.

Paul

[Michael H. Warfield]

Post by Michael Richardson

We now know that we can, in fact, generate multiple proposals,
provided the DH group is at least kept constant, since that's
what vpnc is doing.

Paul> Note that "some implementation can do this" is not the same as
Paul> being RFC compliant. What is needed is the check with the
Paul> proper RFC's to see if this is indeed valid, and if so, update
Paul> to code.

Fixing that would seem to cover a wealth of sins with these Cisco
boxes. Any hope for that?

Paul> Though we'd gladly accept patches, I think people would rather
Paul> put their energy into IKEv2, then into fixing IKEv1 Aggressive
Paul> Mode.
Paul> Michael (Richardson), can you perhaps tell us more about why
Paul> Openswan claims there can only be one proposal in Aggressive
Paul> Mode?
The ISAKMP SA is created in exchange 1 in aggressive mode.
You have to send the exponent during that exchange, so you have to know
what DH group you are using before you start.
This is why you can not have multiple DH groups in aggressive mode, and
I'd say historically, that meant that you can only have one proposal,
since different DH groups was really the only parameter in historical
(Freeswan 1.xx) code.

The Cisco vpnclient and the OSS vpnc offer up 24 proposals in the first
exchange, all with the same DH group. The server picks one. Offering
all these others would cover a lot of complaints I'm seeing on this list
where the response is "you need to have the correct proposal". A lot of
people can't readily get at that information.

Post by Michael Richardson
The only other option was MD5 vs SHA1 then, and I think you have to also
pick which hash to use since you have to know which PRF to use to
generate keys as well (and in IKEv1, the hash negotiated is really the PRF).

There are a full set of AES (128, 192, 256), 3DES, and DES proposals
offered plus SHA1 and MD5. All combinations.

Post by Michael Richardson
Maybe in concept, you can propose 3DES or AES128 in aggressive mode.
I'd have to spend some time thinking about why that might not be
acceptable.

The ASA's seem perfectly happy with it and that's what vpnc and the
Cisco clients emit.

Post by Michael Richardson
Frankly --- why not put in a support request to CISCO and make them do
some testing, or explain why their product isn't compliant with the RFP
you sent out?

Frankly, because I know exactly what I'm going to get back in response
(this is not my first go around with them and I know several Cisco
security people and engineers). "Well, the Cisco client on Linux is
vpnclient and the OpenSource flavor of that is vpnc. Why don't you use
one of these instead of such a broken client?" "Because neither
vpnclient nor vpnc support multiple connections and neither will coexist
with OpenSwan due to the conflicts with pluto over IKE. And vpnclient,
per se, is so unstable that it warfs up a hairball if you even look at
it wrong." "Well, how about Racoon? I hear that will work." Gag...
I've got all the Racoon information and yes, that will work as well.
But racoon embodies all that everyone complains about with IPSec...
That it takes a rocket scientist to configure and it's obtuse and
confusing and there's no uniform package to make it just work (one of my
co-workers has a big hair-ball hack-and-a-half set of a scripts to shim
Racoon to get all the pieces for Mac's to play right).

Regards,
Mike

[Avesh Agarwal]

Post by Michael H. Warfield
Hey Paul,

Post by Paul Wouters

Post by Avesh Agarwal

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

Exactly what it says that your cisco does not like the proposals
sent by openswan end. Verify your cisco side settings (encryption
lago, hash algo and DH groups) with the ones you set with openswan
and see if there is any mismatch.

Thanks Avesh. I'm looking. But I can't see the mismatch yet. The Cisco (I'm
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
phase2=esp
phase2alg=3DES-SHA1;modp1024

The specs also did not mention whether to use Main Mode or Aggressive Mode.
If this fails, try adding aggrmode=yes

AFAICT, with those Cisco ASA's that's going to be a given. Certainly,
that's all vpnc supports and that's the designated client for them.
Recursing back to earlier discussions around this, the whole single
proposal thing seems problematical and a theme in a number of these
calls, once you get into aggressive mode. We now know that we can, in
fact, generate multiple proposals, provided the DH group is at least
kept constant, since that's what vpnc is doing. Fixing that would seem
to cover a wealth of sins with these Cisco boxes. Any hope for that?

Mostly I have noticed that "encryption-hash" algo proposal is not the
problem when communicating with Cisco boxes, because in general,
administrators configure more than one "encryption-hash" proposals to
choose from. So mostly the mismatch is DH group in phase 2 (quick mode)
that can not be negotiated as per the RFC, and a client must configure
exactly what the server wants.

Sometime this may not be a problem, when the server is initiating the
phase2 so that client knows which DH group the server is expecting (it
seems like something how vpnc does). However, in Openswan, if client
initiates first phase, most probably the client initiates the phase 2
too, and then Openswan client has to make a choice (or guess based on
first phase DH group) what server might expect. If somehow, the server
has configured "different" DH groups for phase 1 and phase 2, mostly
you will get "NO_PROPOSAL_CHOSEN" message.

One way to deal with this may be to "retry" with different DH group if
the first one fails, or to wait little bit so that server can initiate
the phase 2.

In summary, I feel that this is not an Openswan issue, but the way
standard works.

My 2 cents.

Avesh

Post by Michael H. Warfield
I'm looking at some other aggressive mode and config server issues but I
stuck my nose into that particular stretch of code in pluto and it
looked a little on the intimidating side to to just roll my sleeves up
and dig into.

Post by Paul Wouters
Paul
_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Craig Constantine]

Post by Avesh Agarwal
Is this DH group 2? Also I think "esp" is being obsolete, so dont
phase2=esp phase2alg=3DES-SHA1;modp1024

Whit,

Avesh and I are saying the same thing about specifying the modpNBITS.

I'm using Ubuntu 9.10 server 64bit. I could only make the config work
with "A-B-C" (as in my previous message). The man pages say "A-B;C" as
Avesh has shown. But mine does not work with the semicolon, I get an
error about parsing of the config file failing when I try to start ipsec.

Also, Avesh makes a good point about the esp deprecation... All my
configs use "ike=..." and "phase2alg=..." and I here I recall the man
page being correct about which config keys are aliases to which others,
and which are deprecated.

-craig

[Avesh Agarwal]

Post by Craig Constantine

Post by Avesh Agarwal
Is this DH group 2? Also I think "esp" is being obsolete, so dont
phase2=esp phase2alg=3DES-SHA1;modp1024

Whit,
Avesh and I are saying the same thing about specifying the modpNBITS.
I'm using Ubuntu 9.10 server 64bit. I could only make the config work
with "A-B-C" (as in my previous message). The man pages say "A-B;C" as
Avesh has shown.
But mine does not work with the semicolon, I get an
error about parsing of the config file failing when I try to start ipsec.

That is because you are probably using some old (well not so old)
version. It was fixed recently, I think, in 2.6.23.

Regards
Avesh

Post by Craig Constantine
Also, Avesh makes a good point about the esp deprecation... All my
configs use "ike=..." and "phase2alg=..." and I here I recall the man
page being correct about which config keys are aliases to which others,
and which are deprecated.
-craig
_______________________________________________
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Craig Constantine]

Post by Avesh Agarwal

But mine does not work with the semicolon, I get an error about
parsing of the config file failing when I try to start ipsec.

That is because you are probably using some old (well not so old)
version. It was fixed recently, I think, in 2.6.23.
Regards Avesh

Yes, Ubuntu 9.10 (not sure what version of Buntu Whit is usiong) is at
openswan 2.6.22.

I wasn't taking issue with what you wrote; I recall Whit mentioning he's
using Ubuntu, and I thought it would be helpful to warn him of the
pitfall that I fell into...

-c

[Avesh Agarwal]

Post by Craig Constantine

Post by Avesh Agarwal

But mine does not work with the semicolon, I get an error about
parsing of the config file failing when I try to start ipsec.

That is because you are probably using some old (well not so old)
version. It was fixed recently, I think, in 2.6.23.
Regards Avesh

Yes, Ubuntu 9.10 (not sure what version of Buntu Whit is usiong) is at
openswan 2.6.22.
I wasn't taking issue with what you wrote; I recall Whit mentioning
he's using Ubuntu, and I thought it would be helpful to warn him of
the pitfall that I fell into...

I was just informing you about it and nothing else.

Regards
Avesh

Post by Craig Constantine
-c

[Whit Blauvelt]

Post by Craig Constantine
Yes, Ubuntu 9.10 (not sure what version of Buntu Whit is usiong) is at
openswan 2.6.22.

Don't want to repeat myself every message, but I compiled from soure of
2.6.24 as I said before.

- Whit

[Whit Blauvelt]

Post by Avesh Agarwal
That is because you are probably using some old (well not so old)
version. It was fixed recently, I think, in 2.6.23.
Regards
Avesh

Ah, but Avesh, I'm using 2.6.24, as I mentioned up thread.

Best,
Whit

[Whit Blauvelt]

Craig,

Thanks. Hadn't looked at "man ipsec.conf". Unfortunately, when I get rid of
the esp= and replace it with phase2= and phase2alg= lines as suggested, I
end up with:

# ipsec auto --up cisco
000 initiating all conns with alias='cisco'
021 no connection named "cisco"

This is bizarre, since the ipsec.conf file is so little changed - just those
few lines. It now looks like:

version 2.0

# basic configuration
config setup
klipsdebug="none"
plutodebug="all"
uniqueids=yes
protostack=netkey

conn cisco
type=tunnel
left=xx.xx.xx.114 #your IP
leftsubnet=192.168.1.0/24
leftnexthop=xx.xx.xx.97
leftid=@<fqdn>
right=yy.yy.yy.222 # IP address of Cisco ASA 5510
rightsubnet=zz.zz.zz.192/26 # LAN behind Cisco
rightid=yy.yy.yy.222
keyingtries=0
pfs=yes
auto=add
phase2=esp
phase2alg=3DES-SHA1-modp1024
ike=3DES-SHA1
authby=secret

I am on 64bit Ubuntu as you are (although 8.04).

Regards,
Whit

Post by Craig Constantine

Post by Avesh Agarwal
Is this DH group 2? Also I think "esp" is being obsolete, so dont
phase2=esp phase2alg=3DES-SHA1;modp1024

Whit,
Avesh and I are saying the same thing about specifying the modpNBITS.
I'm using Ubuntu 9.10 server 64bit. I could only make the config
work with "A-B-C" (as in my previous message). The man pages say
"A-B;C" as Avesh has shown. But mine does not work with the
semicolon, I get an error about parsing of the config file failing
when I try to start ipsec.
Also, Avesh makes a good point about the esp deprecation... All my
configs use "ike=..." and "phase2alg=..." and I here I recall the
man page being correct about which config keys are aliases to which
others, and which are deprecated.
-craig

[Whit Blauvelt]

Post by Avesh Agarwal

Post by Whit Blauvelt
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
phase2=esp
phase2alg=3DES-SHA1;modp1024

Thanks again. Whether that's DH group2 ... probably, but it's getting
through phase I, so could that be the problem?

Are you suggesting I have the Cisco admin not use esp?

After adding the two lines you suggest I get:

ipsec_setup: duplicate key 'phase2' in conn cisco while processing def cisco
ipsec_setup: duplicate key 'phase2alg' in conn cisco while processing def cisco
ipsec_setup: while loading 'cisco': duplicate key 'phase2alg' in conn cisco while processing def cisco

What these are duplicating is not clear, since there is only one
specification of either "phase2" and "phase2alg" in the ipsec.con.

At that point

# ipsec auto --up cisco
000 initiating all conns with alias='cisco'
021 no connection named "cisco"

So whatever the "duplicate key" message means, it's a fatal problem.

Best,
Whit

[Avesh Agarwal]

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
IPsec Phase I: pre-g2-3des-sha-86400s
IPsec Phase II: pfs2-esp-3des-sha-28800s

Is this DH group 2? Also I think "esp" is being obsolete, so dont use
phase2=esp
phase2alg=3DES-SHA1;modp1024

Thanks again. Whether that's DH group2 ... probably, but it's getting
through phase I, so could that be the problem?
Are you suggesting I have the Cisco admin not use esp?
ipsec_setup: duplicate key 'phase2' in conn cisco while processing def cisco
ipsec_setup: duplicate key 'phase2alg' in conn cisco while processing def cisco
ipsec_setup: while loading 'cisco': duplicate key 'phase2alg' in conn cisco while processing def cisco
What these are duplicating is not clear, since there is only one
specification of either "phase2" and "phase2alg" in the ipsec.con.
At that point
# ipsec auto --up cisco
000 initiating all conns with alias='cisco'
021 no connection named "cisco"

I believe that you have not removed "esp". Please remove "esp" and try
again.

Regards
Avesh

Post by Whit Blauvelt
So whatever the "duplicate key" message means, it's a fatal problem.
Best,
Whit

[Whit Blauvelt]

Post by Avesh Agarwal

Post by Whit Blauvelt
# ipsec auto --up cisco
000 initiating all conns with alias='cisco'
021 no connection named "cisco"

I believe that you have not removed "esp". Please remove "esp" and
try again.

If you're suggesting I haven't removed the "esp=" line, well, I have. Or are
you suggesting I also remove the "phase2=esp" line?

[Avesh Agarwal]

Post by Whit Blauvelt

Post by Avesh Agarwal

Post by Whit Blauvelt
# ipsec auto --up cisco
000 initiating all conns with alias='cisco'
021 no connection named "cisco"

I believe that you have not removed "esp". Please remove "esp" and
try again.

If you're suggesting I haven't removed the "esp=" line, well, I have. Or are
you suggesting I also remove the "phase2=esp" line?

[Whit Blauvelt]

Could you please enable plutodebug=all and check "ipsec barf" what
kind of error it shows. Because that should not happen, and that may
be just because of some typo somewhere. Also dont forget to disable
plutodebug once you know the error.

Appreciate your patience. I've had plutodebug=all set, but had forgotten
about the "ipsec barf" command. Unfortunately that puts out so much stuff,
I'm not sure where to look - and imagine it would be abusive to post the
whole output here, plus it's got scores of instances of IP info I'd have to
obfuscate.

Meanwhile, I've got on variant on a ipsec.conf file that gets farther along.
This is with simply:

phase2=esp
phase2alg=3DES-SHA1

That's in place of esp=3DES-SHA1. (Which should be precisely the same thing,
right?)

Result looks better, but it's not fully there yet:

# ipsec auto --up cisco
104 "cisco" #1: STATE_MAIN_I1: initiate
003 "cisco" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
106 "cisco" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "cisco" #1: received Vendor ID payload [Cisco-Unity]
003 "cisco" #1: received Vendor ID payload [XAUTH]
003 "cisco" #1: ignoring unknown Vendor ID payload [a8f33953453506b058872decc58a71b1]
003 "cisco" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
108 "cisco" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "cisco" #1: received Vendor ID payload [Dead Peer Detection]
004 "cisco" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "cisco" #2: STATE_QUICK_I1: initiate
004 "cisco" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xa50df37c <0xc4054af2 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}

However, it's failing to create an ipsec0 interface, as freeswan would have
done by that point, IIRC.

Regards,
Whit

[Avesh Agarwal]

Post by Whit Blauvelt

Could you please enable plutodebug=all and check "ipsec barf" what
kind of error it shows. Because that should not happen, and that may
be just because of some typo somewhere. Also dont forget to disable
plutodebug once you know the error.

Appreciate your patience. I've had plutodebug=all set, but had forgotten
about the "ipsec barf" command. Unfortunately that puts out so much stuff,
I'm not sure where to look - and imagine it would be abusive to post the
whole output here, plus it's got scores of instances of IP info I'd have to
obfuscate.
Meanwhile, I've got on variant on a ipsec.conf file that gets farther along.
phase2=esp
phase2alg=3DES-SHA1
That's in place of esp=3DES-SHA1. (Which should be precisely the same thing,
right?)
# ipsec auto --up cisco
104 "cisco" #1: STATE_MAIN_I1: initiate
003 "cisco" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
106 "cisco" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "cisco" #1: received Vendor ID payload [Cisco-Unity]
003 "cisco" #1: received Vendor ID payload [XAUTH]
003 "cisco" #1: ignoring unknown Vendor ID payload [a8f33953453506b058872decc58a71b1]
003 "cisco" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
108 "cisco" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "cisco" #1: received Vendor ID payload [Dead Peer Detection]
004 "cisco" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "cisco" #2: STATE_QUICK_I1: initiate
004 "cisco" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xa50df37c<0xc4054af2 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}

It seems OK.

Post by Whit Blauvelt
However, it's failing to create an ipsec0 interface, as freeswan would have
done by that point, IIRC.

With netkey, there wont be ipsec0. You will have to use KLIPS for that.

Regards
Avesh

Post by Whit Blauvelt
Regards,
Whit

[Whit Blauvelt]

Post by Avesh Agarwal
With netkey, there wont be ipsec0. You will have to use KLIPS for that.

What you say is mentioned at
http://wiki.openswan.org/index.php/Openswan/Netkey, but it doesn't describe
or link to a description of how to work with Netkey. Where might I find
that? There's nothing in the docs with the source tar. And Netkey/Openswan
is failing to set up anything by way of routes for the subnet at the other
end of the tunnel at all.

The suggested compile command for klips fails me at the moment, since my
/lib/modules/2.6.24-19-server directory lacks a /build subdir at the moment.
Not sure how to get that in place. Installing Ubuntu's "linux-kernel-devel"
package doesn't do it. Anyone know what's needed to compile klips on Ubuntu
8.04?

Thanks,
Whit

[Whit Blauvelt]

Hi,

Can someone either explain or point me to what openswan/netkey
expects/requires by way of a default route? I'm asking because my setup
doesn't use a single, simple routing table. I have rules sending stuff
through six different tables. Setting a default route in "main" would break
the rest of the setup.

I finally found a description of netkey's requirements regarding iptables at
"http://lists.openswan.org/pipermail/users/2008-January/013810.html". That
wasn't at all easy to find. If it's right it should be incorporated in the
docs that come with openswan, and the wiki. The firewall.html doc in the tar
is from freeswan days - which of course presumes klips.

Anyway, I'm getting the hint the iptables stuff won't be enough by itself,
unless I also have a workaround in place for whatever openswan/netkey
expects to be doing that's dependent on a default route being set - which in
its simple form isn't on option that maps onto my router/firewall's
necessary configuration for everything else it does (5 interfaces, most with
multiple IPs, dual homed on internet, multiple LANs, etc.). So when I see
openswan's complaining it can't find that default route, what I need is a
hint for how to fix whatever it's depending on having a default route to do,
without breaking my configuration by throwing a default route into table
"main".

Went over and looked at Strongswan, and that's far, far less documented.
Scarey. Has the world gone so strongly over to using either appliances or
OpenVPN that Linux IPsec is just fading away?

Best,
Whit

[Tuomo Soini]

Post by Whit Blauvelt
Hi,
Can someone either explain or point me to what openswan/netkey
expects/requires by way of a default route? I'm asking because my setup
doesn't use a single, simple routing table. I have rules sending stuff
through six different tables. Setting a default route in "main" would break
the rest of the setup.

openswan-2.6.x doesn't need default route with netkey. But that means
you can't use %defaultroute anywhere in your config. That's only
limitation. I have multi-isp setup without default route in main table
and vpn works well.

On current version (2.6.24) you get clear warning about default route
not being detected. In case of multiple default routes pluto can't
really know which one is correct one to use.

Whole %defaultroute stuff is for simple setups, especially road warriors
with dynamic ip.

[Whit Blauvelt]

Post by Tuomo Soini
openswan-2.6.x doesn't need default route with netkey. But that means
you can't use %defaultroute anywhere in your config. That's only
limitation. I have multi-isp setup without default route in main table
and vpn works well.

Thanks Toumo. I'm not using %defaultroute.

Post by Tuomo Soini
On current version (2.6.24) you get clear warning about default route
not being detected. In case of multiple default routes pluto can't
really know which one is correct one to use.

I'm using 2.6.24. I got the warning. It's only partially useful though since
it doesn't suggest any solution aside from setting a default route - which
isn't a compatible solution for my config. You suggest I need to help pluto
here somehow. I've looked briefly at pluto, it's quite complex. How should I
instruct it, in a config where there's no default route for it to deduce
things from in the routing table, what route to use? What does it need set,
where, to work? To be clear, I need this to go out on an external IP that is
dedicated to IPsec, on an interface with multiple IPs. Nothing else will be
defaulting to this IP. Other stuff does go out, by various IPs, on this
interface. It's handling the initial negotiation now on it, just not the
subnet routing.

Post by Tuomo Soini
Whole %defaultroute stuff is for simple setups, especially road warriors
with dynamic ip.

That's cool. We used it for road warriors with FreeSWAN, before we
discovered that OpenVPN made them all a lot happier. What we need now is a
site-to-site setup from a complex system to a stock Cisco. It's in
site-to-site stuff that IPsec still has unique advantages over SSL VPN
methods. I'm sure that step or steps I need to complete this are simple,
just unknown to me and hard to find documented.

Also the startup of Openswan appears a bit fragile, in terms of going wrong
with configuation directive combinations that ought not break it, and
perhaps timing issues on startup. But that stuff can be worked around. What
I need to know is, when that warning about not finding a default route comes
up, what steps to take to compensate for the situation not being the one
Openswan expects, by default, to find.

Thanks,
Whit

[Paul Wouters]

Post by Whit Blauvelt
Can someone either explain or point me to what openswan/netkey
expects/requires by way of a default route?

There are a few reasons why openswan might need to know a default route

1) when using left/right=%defaultroute to bind to the proper interface
for the IKE daemon
2) For KLIPS, where the IPsec stack actually obtains packets via routing,
and thus routing matters (it uses two "half routes" to grab all packets)
(NETKEY grabs packets differently, and should not be depending on routing)
3) I belive some corner cases require NETKEY to know the default gateway
and routing too. I believe only when using 0.0.0.0/0 subnets (eg "extruded
network"). Perhaps when using left/rightsourceip=. See _updown.netkey

I *think* a non-specified nexthop setting assumes a left/rightnexthop=%defaultroute,
which then might again imply needing a default route.

Post by Whit Blauvelt
Went over and looked at Strongswan, and that's far, far less documented.
Scarey. Has the world gone so strongly over to using either appliances or
OpenVPN that Linux IPsec is just fading away?

Nobody pays for documentation. I'd gladly accept donations in the form of money
or students or time to remedy this. The man pages should be up to date (we do
spend the time on that) and there is a wealth of information in the ***@openswan.org
mailing list archive - though by now often with dead links too.

Paul

[Whit Blauvelt]

Paul,

Post by Paul Wouters
There are a few reasons why openswan might need to know a default route
1) when using left/right=%defaultroute to bind to the proper interface
for the IKE daemon
2) For KLIPS, where the IPsec stack actually obtains packets via routing,
and thus routing matters (it uses two "half routes" to grab all packets)
(NETKEY grabs packets differently, and should not be depending on routing)
3) I belive some corner cases require NETKEY to know the default gateway
and routing too. I believe only when using 0.0.0.0/0 subnets (eg "extruded
network"). Perhaps when using left/rightsourceip=. See _updown.netkey
I *think* a non-specified nexthop setting assumes a left/rightnexthop=%defaultroute,
which then might again imply needing a default route.

What I need to know is not why Openswan _might_ need to know a default
route, but how to give it what it needs _without_ having a default route in
my system configuration main table. So I need to know:

1. What routing is required for it (by way of non-default routes and rules)

2. What stuff in other places gets set based on default routing assumptions,
that needs to be set otherwise for a non-default route configuration

[Tuomo Soini]

Post by Whit Blauvelt
What I need to know is not why Openswan _might_ need to know a default
route, but how to give it what it needs _without_ having a default route in

%defaultroute is not needed if you don't specify %defaultroute in
config. Default for *nexthop=%direct, not %defaultroute.

Trust me. I don't have defaultroute on my main routing table and pluto
just works.

[Whit Blauvelt]

Tuomo,

Thanks, but I am not, and have not, used %defaultroute. I don't want to.
That is not, I believe, connected with my question Openswan not working in a
situation where there has not been a default route statement in the main
routing table, and Openswan's complaining on startup that it can't determine
the default route. If all Openswan uses a default route from main routing
table for is to fill in %defaultroute, why does it even complain, with no
%defaultroute in ipsec.conf?

There is no use of "%defaultroute" in my ipsec.conf. There has not been. Yet
pluto is not just working. I want to find the way to fix it that depends
neither on %defaultroute nor on having a default route in my main routing
table.

Best,
Whit

Post by Tuomo Soini

Post by Whit Blauvelt
What I need to know is not why Openswan _might_ need to know a default
route, but how to give it what it needs _without_ having a default route in

%defaultroute is not needed if you don't specify %defaultroute in
config. Default for *nexthop=%direct, not %defaultroute.
Trust me. I don't have defaultroute on my main routing table and pluto
just works.
--
Foobar Linux services
[phone]
Foobar Oy <http://foobar.fi/>

[Tuomo Soini]

Post by Whit Blauvelt
Tuomo,
Thanks, but I am not, and have not, used %defaultroute. I don't want to.
That is not, I believe, connected with my question Openswan not working in a
situation where there has not been a default route statement in the main
routing table, and Openswan's complaining on startup that it can't determine
the default route. If all Openswan uses a default route from main routing
table for is to fill in %defaultroute, why does it even complain, with no
%defaultroute in ipsec.conf?

Because startup scripts don't know if you were using %defaultroute in
config or not at the point where default route is checked.

Post by Whit Blauvelt
There is no use of "%defaultroute" in my ipsec.conf. There has not been. Yet
pluto is not just working. I want to find the way to fix it that depends
neither on %defaultroute nor on having a default route in my main routing
table.

I don't say it's simple to get ipsec working with multiple default
routes. First of all. you must make sure that correct routing table with
only one default route is used when source ip is one used by openswan.

[Whit Blauvelt]

Post by Tuomo Soini

Post by Whit Blauvelt
There is no use of "%defaultroute" in my ipsec.conf. There has not been. Yet
pluto is not just working. I want to find the way to fix it that depends
neither on %defaultroute nor on having a default route in my main routing
table.

I don't say it's simple to get ipsec working with multiple default
routes. First of all. you must make sure that correct routing table with
only one default route is used when source ip is one used by openswan.

The problem doesn't look to me to be at the level of which routing table is
used. I've got a well-proven, if complex, implementation there between the
rules and the routes. The real question may be one of understanding just
which routing rule needs to be created specifically for the tunnel - if one
does at all, considering this is netkey and it's using the somewhat
mysterious and almost totally undocumented xfrm feature of iproute2. By some
accounts stuff handled by xfrm may not need routes set too, since it has
similar functionality. But I can't find a full definition of their overlap
and interaction.

So that's what I need to find or create a good map of: Given the public IPs
and private subnets involved, what's the required end result in terms of
xfrms, rules, routes and iptables tricks to get packets using the tunnel? I
understand that this works automatically, for a simple system, with a single
IP on a single public interface, with the default route as defined in the
routing table. But for a complex system, with multiple IPs per interface,
more than two interfaces, and no default route assigned whatsoever in the
main routing table, what every automated tricks Openswan and company use are
failing to put everything in place.

If I had a good definition of what all needs to be put in place, I could
code up a script to fix it. Since this is site-to-site, not road warrior,
and just needs to be a static setup (well, except for failover to the second
public line when needed), it doesn't need all the automated magic. I've no
problem with hard coding it, if the result is once that's done it just
works.

Best,
Whit

[Paul Wouters]

Post by Whit Blauvelt

Could you please enable plutodebug=all and check "ipsec barf" what
kind of error it shows. Because that should not happen, and that may
be just because of some typo somewhere. Also dont forget to disable
plutodebug once you know the error.

Appreciate your patience. I've had plutodebug=all set, but had forgotten
about the "ipsec barf" command. Unfortunately that puts out so much stuff,

Try: ipsec auto --add cisco
to find out why the conn did not load.

You should be okay with using esp= and ike= and not phase2= and phase2_algs.

Paul

[Whit Blauvelt]

Post by Paul Wouters
Try: ipsec auto --add cisco
to find out why the conn did not load.

Think it not loading is only an occassional glitch, unrelated to other
problems.

Post by Paul Wouters
You should be okay with using esp= and ike= and not phase2= and phase2_algs.

Yeah, I know. But it turns out:

phase2=esp
phase2alg=3DES-SHA1
ike=3DES-SHA1

works connecting to the Cisco, while

esp=3DES-SHA1
ike=3DES-SHA1

fails. Most odd.

Best,
Whit

[Whit Blauvelt]

Okay, I now see that xfrm is used by netkey, and xfrm is totally new to me.
I can see that Openswan sets up the following on my system:

# ip xfrm policy
src zz.zz.zz.192/26 dst 192.168.1.0/24
dir in priority 2342
tmpl src yy.yy.yy.222 dst xx.xx.xx.114
proto esp reqid 16389 mode tunnel
src 192.168.1.0/24 dst zz.zz.zz.192/26
dir out priority 2342
tmpl src xx.xx.xx.114 dst yy.yy.yy.222
proto esp reqid 16389 mode tunnel
src zz.zz.zz.192/26 dst 192.168.1.0/24
dir fwd priority 2342
tmpl src yy.yy.yy.222 dst xx.xx.xx.114
proto esp reqid 16389 mode tunnel

Where:

xx.xx.xx.114 is left public IP
192.168.1.0/24 is left subnet
yy.yy.yy.222 is right public IP
zz.zz.zz.192/26 is right subnet

Is this about what I should be seeing, given that I'm trying to find what's
required to get the not-working-yet tunnel going? There are policies here to
tunnel in and out, and a policy to forward in - but not a policy to forward
from the local subnet to the remote one. Should there be one?

What does it need to match up with in terms of routes set by the routing
tables? Anything?

I find some old discussion of xfrm on the list, for instance here:

http://lists.openswan.org/pipermail/users/2006-August/010473.html

but it looks like Openswan has evolved since then. At least the policies I
get are more complex statements. That post does usefully suggest that
whatever's not getting set up in my case, probably because I don't use a
default route in the basic way for Openswan to deduce stuff from, can be set
up through a script, if only I can complete my own deduction of what the end
state must be for the tunnel to work.

If this gets solved, I'll write up at least a basic Openswan-on-Ubuntu to
Cisco recipe, because both Ubuntu and Ciscos are pretty damn common, so
solving this would be useful to many. I checked the StrongSwan mailing list
to see how people are doing connecting that to Ciscos, and it doesn't look
good there. Mostly problem reports that get ignored or at best half
answered. Maybe Cisco's IPsec is still so broken that it's not fully
compatible with anything but another Cisco. But I know I should be getting
farther than I am. And even if we're stuck buying a Cisco for our end, it
would be useful to have Openswan as a backup - or else we'll really need a
second Cisco for failover, too. Even a < 100% reliable Openswan backup would
be enough in that department, avoiding a single point of failure there.

Best,
Whit

[Whit Blauvelt]

Just to make understanding "ip xfrm" more fun, there's nothing more than the
raw syntax on the iproute2 man page for it (as compared to other commands,
which get some explanation), and there's damn little discussion of it on the
web at all. Even lartc.org (Linux Advanced Routing & Traffic Control -
pretty much the standard reference) has no mention of "xfrm" at all.

Ah, joy. So here we have barely documented use of a nearly undocumented
feature.

Whit

[Paul Wouters]

Post by Whit Blauvelt
Just to make understanding "ip xfrm" more fun, there's nothing more than the
raw syntax on the iproute2 man page for it (as compared to other commands,
which get some explanation), and there's damn little discussion of it on the

And it took years of complaining from like 2000 (at OLS) until like 2005 before
it even got into the man page.....

Post by Whit Blauvelt
web at all. Even lartc.org (Linux Advanced Routing & Traffic Control -
pretty much the standard reference) has no mention of "xfrm" at all.

lartc.org got pretty much abandoned years ago by its maintainer. And they never
had anything good on ipsec because of a strong bias towards racoon only.

don't forget "ip xfrm state".

Paul

[Whit Blauvelt]

Post by Paul Wouters
don't forget "ip xfrm state".

Useful. That looks to confirm that the ends of the tunnel are in place. So
I'd guess it's the policy aspect that I need to learn how to debug.

Whit

[Paul Wouters]

Post by Avesh Agarwal
phase2=esp
phase2alg=3DES-SHA1
ike=3DES-SHA1
works connecting to the Cisco, while
esp=3DES-SHA1
ike=3DES-SHA1
fails. Most odd.

Could you confirm that with some good tests to ensure the cisco did
not keep any state or something? Those configs should be fully
equivalent.

Paul

[Whit Blauvelt]

Post by Paul Wouters

Post by Avesh Agarwal
phase2=esp
phase2alg=3DES-SHA1
ike=3DES-SHA1
works connecting to the Cisco, while
esp=3DES-SHA1
ike=3DES-SHA1
fails. Most odd.

Could you confirm that with some good tests to ensure the cisco did
not keep any state or something? Those configs should be fully
equivalent.

You may well be right about the Cisco, somehow. Now the second form does
work. Yet before there was no joy until going from the first to the second.
The Cisco is totally out of my control, so can't say nothing's changed
there, or directly probe its state.

Whit

[Whit Blauvelt]

Hi all,

Just an note that now it's working happily. Need to do more testing. Will
write up for wiki or someplace when I've got to the point where I feel I
have a hold on it.

Whit

[tiago]

Post by Whit Blauvelt
Hi all,
Just an note that now it's working happily. Need to do more testing. Will
write up for wiki or someplace when I've got to the point where I feel I
have a hold on it.
Whit
_______________________________________________
Users <at> openswan.org
http://lists.openswan.org/mailman/listinfo/users
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

Hi Whit Blauvelt.
what did you do? can you share?

im still having troubles

# ipsec auto --up vpn
112 "vpn" #1: STATE_AGGR_I1: initiate
003 "vpn" #1: Informational Exchange message must be encrypted



# tail -f /var/log/auth.log
pluto[19573]: | **parse ISAKMP Message:
pluto[19573]: | initiator cookie:
pluto[19573]: | 32 33 16 da 2a fa 01 7d
pluto[19573]: | responder cookie:
pluto[19573]: | 0c fd 88 5f 75 c1 7c 3c
pluto[19573]: | next payload type: ISAKMP_NEXT_N
pluto[19573]: | ISAKMP version: ISAKMP Version 1.0 (rfc2407)
pluto[19573]: | exchange type: ISAKMP_XCHG_INFO
pluto[19573]: | flags: none
pluto[19573]: | message ID: 00 00 00 00
pluto[19573]: | length: 100
pluto[19573]: | processing version=1.0 packet with exchange
type=ISAKMP_XCHG_INFO (5)
pluto[19573]: | ICOOKIE: 32 33 16 da 2a fa 01 7d
pluto[19573]: | RCOOKIE: 0c fd 88 5f 75 c1 7c 3c
pluto[19573]: | state hash entry 5
pluto[19573]: | p15 state object not found
pluto[19573]: | ICOOKIE: 32 33 16 da 2a fa 01 7d
pluto[19573]: | RCOOKIE: 00 00 00 00 00 00 00 00
pluto[19573]: | state hash entry 9
pluto[19573]: | v1 peer and cookies match on #2, provided msgid 00000000
vs 00000000
pluto[19573]: | v1 state object #2 found, in STATE_AGGR_I1
pluto[19573]: | processing connection vpn
pluto[19573]: "vpn" #2: Informational Exchange message must be encrypted
pluto[19573]: | * processed 0 messages from cryptographic helpers
pluto[19573]: | next event EVENT_RETRANSMIT in 20 seconds for #2

[Craig Constantine]

Post by Whit Blauvelt
Thanks Avesh. I'm looking. But I can't see the mismatch yet. The
pfs2-esp-3des-sha-28800s

I'm not working with Cisco, but I wound up specifying the size too...

ike=3des-sha1-modp1024

(or modp512, modp2048, etc) to get one of my SA's connected.

-craig

[Ondrej Valousek]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000066">
Some comparison like that would interest me, too.<br>
I am basically RedHat guy, so whatever RedHat unveils for their
enterprise Linux, I go for it. Unfortunately this 'tactics' is no use
here either as in RHEL-5 you can find both OpenSwan and Kame.<br>
So I would decide based on quality of support / documentation the
mailing lists of both provide.<br>
For Openswan is the support bit troublesome as Paul seems to be the
only person willing to respond/help.<br>
I would wonder how is the situation with Kame....<br>
<br>
Ondrej<br>
<br>
Whit Blauvelt wrote:
<blockquote cite="mid:***@transpect.com" type="cite">
<pre wrap="">Hi,

Apologies for asking such a general question. We were using FreeSWAN
internally some years back, then switched to OpenVPN, which has been great
for that. But now we're needing to return to IPsec to tunnel from our Linux
firewall to a remote Cisco 5510. The current state of documentation for
Linux IPsec options is sparse and disorganized. So my questions are quite
basic:

For a Linux-Cisco IPsec tunnel, are each of these equally compatible with
the Cisco?

- OpenSWAN
- KAME (ipsec-tools)
- OpenBSD's isakmpd

For Ubuntu 8.04 (with kernel 2.6.24-19-server, and no X), which of those
options installs and works most smoothly? (I note that Ubuntu seems to be
largely ignoring bugs filed against OpenSWAN - see
<a class="moz-txt-link-rfc2396E" href="https://bugs.launchpad.net/ubuntu/+source/openswan/+bugs">"https://bugs.launchpad.net/ubuntu/+source/openswan/+bugs"</a>.)

At the Cisco end they prefer as defaults (but will alter if required):

Phase 1 - pre-g2-3des-sha-86400s
Phase 2 - pfs2-esp-3des-sha-28800s
and a PSK (not cert)

Are there known gotchas there for Linux? For OpenSWAN? I'm recalling
FreeSWAN having some problems with pfs; does that remain an issue?

Looking at the OpenSWAN wiki, I see for instance a comparison of Linux IPsec
options without KAME or isakmpd included. Googling on the various
combinations, I find of plenty of problem reports and partial recipes, but
little in the way of complete accounts of success. It's obvious from the
volume on this mailing list that OpenSWAN is still a viable option. It's
fully possible I've missed answers to exactly the questions here - but my
eyes glaze over after sampling so many dozens of threads. If answers are
forthcoming, I'll try to integrate them into the OpenSWAN wiki, so at least
next time someone like me won't have to address the list for such basic
stuff.

Best,
Whit
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:***@openswan.org">***@openswan.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a>
Building and Integrating Virtual Private Networks with Openswan:
<a class="moz-txt-link-freetext" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
</blockquote>
<br>
</body>
</html>

[Tuomo Soini]

Post by Ondrej Valousek
Some comparison like that would interest me, too.
I am basically RedHat guy, so whatever RedHat unveils for their
enterprise Linux, I go for it. Unfortunately this 'tactics' is no use
here either as in RHEL-5 you can find both OpenSwan and Kame.
So I would decide based on quality of support / documentation the
mailing lists of both provide.
For Openswan is the support bit troublesome as Paul seems to be the only
person willing to respond/help.
I would wonder how is the situation with Kame....

That's not entirely true but Paul often answers questions faster than
others do - so we don't need to worry.

I'd guess Openswan is the way to go, especially if you are interested in
ikev2 and other new stuff.