[ previous ] [ next ] [ threads ]
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  isakmpd - no joy...
 Date:  Wed, 14 Jan 2004 21:15:32 +0100
Hi folks,

I've been able to verify that isakmpd is indeed able to install 
policies as required - it's possible to connect with a dynamic IP 
address and have it auto-install two entries in the SPD. But 
apparently, even though the port description argues the converse, 
racoon can do that too (generate_policy on; haven't tried it though). 
Now, there's still a problem I wished isakmpd would solve: 
authentication. In a situation with dynamic client IP addresses, these 
cannot be used for client identification. I was hoping that I could 
(ab)use USER_FQDN as a means of telling the server which client is 
connecting (and therefore which shared secret to verify, which 
encryption algorithms to use for P1, etc.). While the isakmpd.conf 
manpage makes one believe that USER_FQDN should be supported, it isn't 
- it's wrapped in an #ifdef notyet in ipsec.c. I haven't read enough 
about the IKE protocol to know if it is possible at all (i.e. if the 
USER_FQDN is transmitted before the client must be authenticated).

It all boils down to this: we can make dynamic IPsec work, but all 
clients with dynamic IP addresses will have to use the same P1/P2 
settings and - sad but true - the same shared secret. The only way out 
is with certificates, but that is sure to give people headaches and 
flood the mailing list. ;) If memory serves me right, at least ZyXEL 
products have the same limitation (dynamic clients must share the same 
policy), so maybe that's just the way it is.

If anybody has some more insight about racoon/isakmpd/dynamic IPsec to 
share, please do (has anybody ever seen it working with multiple dyn. 
clients and different shared secrets without non-standard stuff like 
Cisco or Checkpoint?). Otherwise I'll just implement the single-policy 
"kludge". Still better than nothing.