Dennis Pedersen (trm) writes:
>
> Uhm, you can also use a email add and a password
> [EMAIL PROTECTED] thekeything
> There are a bit about certificates in a kame newsletter, try looking on the
> site :)
>
> How did you solve the setkey setup if the ip adress is dynamic, do you have
> an example?
That's the problem.
See:
http://www.google.com/url?sa=U&start=1&q=http://archives.neohapsis.com/archives/freebsd/2000-12/0009.html&e=922
Normally, you use SPDUPDATE messages to the kernel to update the security
policy.
o Client side -- normally you would use this in the CLIENT racoon.conf:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
remote IP.OF.MY.OFFICE-GW
{
[...]
my_identifier address;
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
... to identify yourself using your IP address. Since it's dynamic,
we use this instead:
my_identifier user_fqdn "[EMAIL PROTECTED]" ;
(could also be an X.509 ASN.1 identifier with a certificate payload
-- haven't tried it yet with racoon...)
o On the office GW:
In psk.txt, you add:
[EMAIL PROTECTED] MyPreSharedKeySecret
Then in the racoon.conf, you define a remote anonymous as follows:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
remote anonymous {
[...]
passive on;
generate_policy on;
my_identifier address;
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Idea: the passive on tells the office GW to listen to requests and
never initiate negotiation. Perfect since you don't know the IP address
in advance.
generate_policy is there to fix that: it will generate a policy (SP)
in the SPD dynamically if it the authentication info + PSK (pre shared
key) or cert ID matches -- as racoon.conf(5) says:
generate_policy (on | off);
This directive is for the responder. Therefore you
should set passive on in order that racoon(8) only
becomes a responder. If the responder does not have any
policy in SPD during phase 2 negotiation, and the direc-
tive is set on, then racoon(8) will choice the first pro-
posal in the SA payload from the initiator, and generate
policy entries from the proposal. It is useful to nego-
tiate with the client which is allocated IP address
dynamically.
Unfortunately, this doesn't work.
Running racoon -F you will see the server (GW) side complain
with something in the form (don't have it in front of me):
X_SPDUPDATE: no such file or directory
... and after a short while the phase 1 will time out, with no
phase 2 negotiated.
And that's it :( So it looks like KAME either doesn't fully implement
this or racoon doesn't -- I'm not really sure which, and haven't
had time to try with isakmpd yet (ports/net/isakmpd).
Any ideas ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
