From: F. S. <fre...@la...> - 2006-01-11 17:59:48
|
Wednesday, January 11, 2006, 2:23:32 PM, Paul Winder wrote: Which version of ipsec-tools are you using, exactly, BTW ? I'm trying to reproduce your problem with the latest stable (0.6.4), and it seems to work : 2006-01-11 18:30:26: INFO: begin Aggressive mode. 2006-01-11 18:30:26: DEBUG: new cookie: 7e4e8584aa6613e7 2006-01-11 18:30:26: DEBUG: use ID type of KEY_ID How are you starting the tunnel ? >> Now, this is a different matter. The pre-shared-key has to be searched >> for in the psk.txt file. Since keyids can be anything including binary >> data, we don't currently make a lookup in this file with that. Thus, >> you have to use the peer's ip address. > Huh.... I have a locally developed IKE daemon which runs in an embedded > OS which sends out keyid and these *are* looked up in the psk.txt file. > Also the ID received (an IP address - but not the responders hosts real > IP address) is not used to look up in pskey.txt. I always get this > fallback message What kind of ID are you receiving ? Could I have the bit of the log around the NOTIFY: message you posted ? Well, actually, I just took a look at the matching code, and it certainly needs improvements ; if I understand it correctly, it looks for the content of the ID field without any regard to its type - worse, it's making a lookup based on the raw contents of the ID field, that is IDTYPE + ID... ? (It's in oakley.c, oakley_skeyid : iph1->authstr = getpskbyname(iph1->id_p); Knowing that iph1->ip_p contains "peer's ID minus general header"...) And there isn't any mechanism to escape the keys in that file... Eeew. So, yes, you're right, I don't think you'll ever see anything else than that fallback message with this... :| I'll try to investigate the case some more if I manage to build a testing setup here. Fred -- I am subversion I never was a part of you Burn Secret desire I never was a part of you Burn I am your future I never was a part of you Burn Swallow down all that fire (Nine Inch Nails, Burn) |