[Openswan Users] Openswan as modecfgserver?
Freeman Wang
xwang at ubicom.com
Wed Sep 9 18:18:45 EDT 2009
Paul & Michael
Thanks for the help. Yes the servers pushes by default if
POLICY_MODECFG_PULL is not set while the client tries to pull and
confuses each other. I should have read demux.c first :) After adding
--modecfgpull to the server side, the two linux boxes can set up the
connection successfully.
It would be great if the gateway can assign private IP addresses from a
pool to road-warrior clients. It would be even better if the
road-warrior can join the local subnet. Could you point me some
documents/code talking about how to add policies for an address poll?
Should I assume this pool of addresses must be in a different subnet
than the local subnet behind the gateway? I thought openswan is kind of
routed implementation and can not provide a similar feature as openVPN's
tap interface.
By saying:
We already have a virtual adaptor called ipsec0.
Do you mean with KLIPS, openswan can bridge the local subnet and
road-warriors? How about NETKEY?
By the way, we moved to a cisco vpn client and found the cisco client
asks too many private modecfg attributes which openswan does not
understand. Are there any options/policies we need to turn on to
inter-op with cisco clients? Any plan to do so?
Thanks
Freeman
| arrived in modecfg_inR0
| XAUTH: HASH computed:
| 10 0f eb 33 29 82 b6 46 7c b2 a8 ad 0e 41 e3 6e
| 98 36 bf bb
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: INTERNAL_IP4_ADDRESS
| length/value: 0
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: INTERNAL_IP4_NETMASK
| length/value: 0
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: INTERNAL_IP4_DNS
| length/value: 0
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: INTERNAL_IP4_NBNS
| length/value: 0
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: INTERNAL_ADDRESS_EXPIRY
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
INTERNAL_ADDRESS_EXPIRY received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: APPLICATION_VERSION
| length/value: 40
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
APPLICATION_VERSION received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28672??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28672?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28674??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28674?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28675??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28675?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28676??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28676?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28678??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28678?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28679??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28679?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28673??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28673?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28680??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28680?? received.
| ****parse ISAKMP ModeCfg attribute:
| ModeCfg attr type: 28681??
| length/value: 0
"road-warrior-host"[1] 192.168.2.198 #1: unsupported mode cfg attribute
28681?? received.
-----Original Message-----
From: mcr at marajade.sandelman.ca [mailto:mcr at marajade.sandelman.ca] On
Behalf Of Michael Richardson
Sent: Wednesday, September 09, 2009 12:28 PM
To: Freeman Wang; users at openswan.org
Cc: Paul Wouters
Subject: Re: [Openswan Users] Openswan as modecfgserver?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:
>> It seems I can not make openswan to work with clients as a
MODECFG
>> server. Is it supposed to work?
Paul> Yes. we have testcases for it in testing/pluto/xauth*/*
>> | p15 state object #1 found, in STATE_MODE_CFG_R1
>> | processing connection road-warrior-host[1] 192.168.2.66
>> | last Phase 1 IV:~ d8 3b 77 2d~ d6 49 fe 81
>> | current Phase 1 IV:~ e4 46 51 94~ 73 5e 2b 22
>> | computed Phase 2 IV:
>> |~~ 13 5b bf cc~ e6 30 7a 93~ a5 69 37 61~ 1c 1d 10 1b
>> "road-warrior-host"[1] 192.168.2.66 #1: received MODECFG
>> message when in state S
>> TATE_MODE_CFG_R1, and we aren't xauth client
>> | * processed 0 messages from cryptographic helpers
>> ~
>> A couple of questions:
>> ~
>> 1. Why the server tried to push IP settings? Shouldn't it wait
for the
>> client to pull? What if the client side does not have modecfg
set? How
>> can I stop that from happening on the server side?
Paul> I am not sure.
a) modecfg was never standardized in IKEv1, so it's hard to say what is
what.
b) having said that, the document says that the server pushes, I think.
(the server knows the policy, not the client afterall)
c) Cisco clients and access servers do the opposite though.
There is a POLICY_MODECFG_PULL option, which you write as:
leftmodecfgpull=true/rightmodecfgpull=true
>> 2. Why the internal IP4 address the server tried to push is the
>> public IP
>> address of the remote peer instead of an 'internal' one?
I do not recall where the list of IP addresses to configure comes from.
Someone was going to write a proper interface to radius to get it all
done properly/sanely. I think that without using pools, it just pushes
the "subnet" (usually /32) which the gateway's policy is configured for.
>> 3. Does openswan support the idea of virtual adaptor? I thought
the
>> remote must be in a different subnet, but modecfg seems to allow
the
>> remote to join the local network.
We don't care.
We already have a virtual adaptor called ipsec0.
>> 4. I couldn't find anything from the document about how to fine
control
>> what is pushed to the client. Can I only push DNS stuff and avoid
passing
>> IP settings?
You would have to write some code to configure this, I think.
In general, in the client pull situation, the server only answers what
the client asked for.
>> 5. What~kind of changes I need to do to~make modecfg to work with
two
>> openswan boxes?
Paul> Perhaps Michael can answer these questions beter then me.
Though have
Paul> a look at the testcase configurations and see if those provide
Paul> further
Paul> information.
It certainly has worked.
I don't know if the current release passes the xauth-* pluto test cases.
The test cases are also detailed examples.
- --
] He who is tired of Weird Al is tired of life! |
firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking,
security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBSqgBsoCLcPvd0N1lAQKb0Qf8Dik22kX+ZurvTK/Bv6O5a3gnDr6gC3ZM
iSZo7vTLgCbu1IuhIgG0QSMjYqVQhMTqqFP3YIsLmEWkhnsVl8agW7pWusidN8+g
H1Rq14C1qkS7GdGSdYHx3tvwVVBUHTV8zb/V3eVXOjziAhdbz4e9jWKXFxT5PS1T
iib4Oh11x+YKy6d2za+BG5JJ9cyTGJrHJJLE+lvW0hvHFwlS/c12sOgAJPavv79t
gE2tsmXku0HECZhUIZQpFcTUZ3Fld0k0RRzXFwKpN1x9wHNlJIHv5PBi7In7a1DD
detf/ewyF7yNg36hNl6QkJ6heKoQYTfMuHUp8zskv+kD/q85H+LMoA==
=2FHA
-----END PGP SIGNATURE-----
More information about the Users
mailing list