Date: Wed, 30 Jan 2002 16:48:13 +0100 From: Phil Regnauld <regnauld@catpipe.net> To: Dennis Pedersen <trm@daydreamer.dk> Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipsec, racoon, win2000, certifications, how-to? Message-ID: <20020130164813.N13412@vinyl.catpipe.net> In-Reply-To: <006801c1a73f$ca34f110$0301a8c0@dpws>; from trm@daydreamer.dk on Sun, Jan 27, 2002 at 03:34:55PM %2B0100 References: <20020127182146.M18351-100000@localhost> <006801c1a73f$ca34f110$0301a8c0@dpws>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Pedersen (trm) writes: > > Uhm, you can also use a email add and a password > something@domain.com 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 "userxyz@company.com" ; (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: userxyz@company.com 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 majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020130164813.N13412>