From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-17 04:42:50
|
Hi Carlos I just completed setting up IKE daemon on SUSE and FreeBSD and it works fine for me. Please let me know what exactly is the problem. IPv4 works like a dream between these computers but Ipv6 has some problems. Is any body aware of Ipv6-icmp6 problem in Linux. The problem goes like this. We have tested Racoon with Ipv6 and it works fine except for the ICMP messages. In IPv6 ICMP messages are used for address resolution and hence if a policy is specifed like "Any to Any secure using ESP" then address resolution itself fails. As a result IKE udp messages itself may not go out. If we specify a policy like say ANY to ANY bypass all ICMP packets then ICMP traffic is not protected. As of now there is no way to specify something like "protect ICMP traffic with subtype X ". Has anybody faced problems like this? Regards Bhuvi |
From: Carlos M. <cmo...@gm...> - 2005-06-17 05:47:27
|
Hello: First, thanks for your answer.=20 Yesterday my isakmpd servers worked!! I think that the problem was in the configuration file when I made the IPSec connection. Sorry if I did not send a mail to explain. Thank you very much. c. 2005/6/17, Bhuvaneshwar HN <hnb...@no...>: > Hi Carlos > I just completed setting up IKE daemon on SUSE and FreeBSD and it works > fine for me. Please let me know what exactly is the problem. IPv4 works > like a dream between these computers but Ipv6 has some problems. Is any > body aware of Ipv6-icmp6 problem in Linux. >=20 > The problem goes like this. >=20 > We have tested Racoon with Ipv6 and it works fine except for the ICMP > messages. In IPv6 ICMP messages are used for address resolution and > hence if a policy is specifed like "Any to Any secure using ESP" then > address resolution itself fails. As a result IKE udp messages itself may > not go out. If we specify a policy like say ANY to ANY bypass all ICMP > packets then ICMP traffic is not protected. As of now there is no way to > specify something like "protect ICMP traffic with subtype X ". >=20 > Has anybody faced problems like this? >=20 > Regards > Bhuvi >=20 >=20 --=20 Carlos Moreno Losada =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D correo-e: cmo...@gm... jabber user: c_m...@bu... =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Linux user: #263092 http://counter.li.org |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-17 05:59:50
|
Thanks Carlos. Does any body encountered problem that i explained with ipv6-icmp? >>> Carlos Moreno <cmo...@gm...> 6/17/2005 11:17 AM >>> Hello: First, thanks for your answer. Yesterday my isakmpd servers worked!! I think that the problem was in the configuration file when I made the IPSec connection. Sorry if I did not send a mail to explain. Thank you very much. c. 2005/6/17, Bhuvaneshwar HN <hnb...@no...>: > Hi Carlos > I just completed setting up IKE daemon on SUSE and FreeBSD and it works > fine for me. Please let me know what exactly is the problem. IPv4 works > like a dream between these computers but Ipv6 has some problems. Is any > body aware of Ipv6-icmp6 problem in Linux. > > The problem goes like this. > > We have tested Racoon with Ipv6 and it works fine except for the ICMP > messages. In IPv6 ICMP messages are used for address resolution and > hence if a policy is specifed like "Any to Any secure using ESP" then > address resolution itself fails. As a result IKE udp messages itself may > not go out. If we specify a policy like say ANY to ANY bypass all ICMP > packets then ICMP traffic is not protected. As of now there is no way to > specify something like "protect ICMP traffic with subtype X ". > > Has anybody faced problems like this? > > Regards > Bhuvi > > -- Carlos Moreno Losada =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= correo-e: cmo...@gm... jabber user: c_m...@bu... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Linux user: #263092 http://counter.li.org ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Ravi P. <rav...@lg...> - 2005-06-17 09:43:19
|
SGksDQpXZSBmYWNlZCB0aGUgc2FtZSBwcm9ibGVtLiANCldlIGFkZGVkIGEgc3RhdGljIElQ VjYgTmVpZ2hib3IgY2FjaGUgZW50cnkgaW4gdGhlIGZyZWVic2QgbWFjaGluZQ0KKHdoaWNo IHdhcyBydW5uaW5nIHJhY29vbikgdG8gb3ZlciBjb21lIGl0Lg0KDQpyZWdhcmRzDQpSYXZp IA0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBzZWMtdG9vbHMt ZGV2ZWwtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQpbbWFpbHRvOmlwc2VjLXRvb2xz LWRldmVsLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mDQpCaHV2 YW5lc2h3YXIgSE4NClNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAwNSAxMTozMCBBTQ0KVG86 IGNtb3Jlbm84QGdtYWlsLmNvbTsgSXBzZWMtdG9vbHMtZGV2ZWxAbGlzdHMuc291cmNlZm9y Z2UubmV0DQpTdWJqZWN0OiBSZTogW0lwc2VjLXRvb2xzLWRldmVsXSBJU0FLTVAgYW5kIGtl cm5lbA0KDQpUaGFua3MgQ2FybG9zLiBEb2VzIGFueSBib2R5IGVuY291bnRlcmVkIHByb2Js ZW0gdGhhdCBpIGV4cGxhaW5lZCB3aXRoDQppcHY2LWljbXA/DQoNCj4+PiBDYXJsb3MgTW9y ZW5vIDxjbW9yZW5vOEBnbWFpbC5jb20+IDYvMTcvMjAwNSAxMToxNyBBTSA+Pj4NCkhlbGxv Og0KDQpGaXJzdCwgdGhhbmtzIGZvciB5b3VyIGFuc3dlci4gDQoNClllc3RlcmRheSBteSBp c2FrbXBkIHNlcnZlcnMgd29ya2VkISEgSSB0aGluayB0aGF0IHRoZSBwcm9ibGVtIHdhcyBp bg0KdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSB3aGVuIEkgbWFkZSB0aGUgSVBTZWMgY29ubmVj dGlvbi4NCg0KU29ycnkgaWYgSSBkaWQgbm90IHNlbmQgYSBtYWlsIHRvIGV4cGxhaW4uDQoN ClRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCmMuDQoNCg0KMjAwNS82LzE3LCBCaHV2YW5lc2h3 YXIgSE4gPGhuYmh1dmFuZXNod2FyQG5vdmVsbC5jb20+Og0KPiBIaSBDYXJsb3MNCj4gSSBq dXN0IGNvbXBsZXRlZCBzZXR0aW5nIHVwIElLRSBkYWVtb24gb24gU1VTRSBhbmQgRnJlZUJT RCBhbmQgaXQNCndvcmtzDQo+IGZpbmUgZm9yIG1lLiBQbGVhc2UgbGV0IG1lIGtub3cgd2hh dCBleGFjdGx5IGlzIHRoZSBwcm9ibGVtLiBJUHY0DQp3b3Jrcw0KPiBsaWtlIGEgZHJlYW0g YmV0d2VlbiB0aGVzZSBjb21wdXRlcnMgYnV0IElwdjYgaGFzIHNvbWUgcHJvYmxlbXMuIElz DQphbnkNCj4gYm9keSBhd2FyZSBvZiBJcHY2LWljbXA2IHByb2JsZW0gaW4gTGludXguDQo+ IA0KPiBUaGUgcHJvYmxlbSBnb2VzIGxpa2UgdGhpcy4NCj4gDQo+IFdlIGhhdmUgdGVzdGVk IFJhY29vbiB3aXRoIElwdjYgYW5kIGl0IHdvcmtzIGZpbmUgZXhjZXB0IGZvciB0aGUNCklD TVANCj4gbWVzc2FnZXMuIEluIElQdjYgSUNNUCBtZXNzYWdlcyBhcmUgdXNlZCBmb3IgYWRk cmVzcyByZXNvbHV0aW9uIGFuZCANCj4gaGVuY2UgaWYgYSBwb2xpY3kgaXMgc3BlY2lmZWQg bGlrZSAiQW55IHRvIEFueSBzZWN1cmUgdXNpbmcgRVNQIg0KdGhlbg0KPiBhZGRyZXNzIHJl c29sdXRpb24gaXRzZWxmIGZhaWxzLiBBcyBhIHJlc3VsdCBJS0UgdWRwIG1lc3NhZ2VzIGl0 c2VsZg0KbWF5DQo+IG5vdCBnbyBvdXQuIElmIHdlIHNwZWNpZnkgYSBwb2xpY3kgbGlrZSBz YXkgQU5ZIHRvIEFOWSBieXBhc3MgYWxsDQpJQ01QDQo+IHBhY2tldHMgdGhlbiBJQ01QIHRy YWZmaWMgaXMgbm90IHByb3RlY3RlZC4gQXMgb2Ygbm93IHRoZXJlIGlzIG5vIHdheQ0KdG8N Cj4gc3BlY2lmeSBzb21ldGhpbmcgbGlrZSAicHJvdGVjdCBJQ01QIHRyYWZmaWMgd2l0aCBz dWJ0eXBlIFggIi4NCj4gDQo+IEhhcyBhbnlib2R5IGZhY2VkIHByb2JsZW1zIGxpa2UgdGhp cz8NCj4gDQo+IFJlZ2FyZHMNCj4gQmh1dmkNCj4gDQo+IA0KDQoNCi0tDQpDYXJsb3MgTW9y ZW5vIExvc2FkYQ0KPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPQ0KY29ycmVvLWU6 IGNtb3Jlbm84QGdtYWlsLmNvbQ0KamFiYmVyIHVzZXI6IGNfbW9yZW5vOEBidWxtYWx1Zy5u ZXQNCj0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0NCkxpbnV4IHVzZXI6ICMyNjMw OTINCmh0dHA6Ly9jb3VudGVyLmxpLm9yZyANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTRi5OZXQgZW1haWwgaXMgc3Bv bnNvcmVkIGJ5OiBEaXNjb3ZlciBFYXN5IExpbnV4IE1pZ3JhdGlvbiBTdHJhdGVnaWVzDQpm cm9tIElCTS4gRmluZCBzaW1wbGUgdG8gZm9sbG93IFJvYWRtYXBzLCBzdHJhaWdodGZvcndh cmQgYXJ0aWNsZXMsDQppbmZvcm1hdGl2ZSBXZWJjYXN0cyBhbmQgbW9yZSEgR2V0IGV2ZXJ5 dGhpbmcgeW91IG5lZWQgdG8gZ2V0IHVwIHRvDQpzcGVlZCwgZmFzdC4gaHR0cDovL2Fkcy5v c2RuLmNvbS8/YWRfaWR0NzcmYWxsb2NfaWQ0OTImb3A9Y2xpY2sNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJcHNlYy10b29scy1kZXZlbCBt YWlsaW5nIGxpc3QNCklwc2VjLXRvb2xzLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vaXBzZWMtdG9v bHMtZGV2ZWwNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBEaXNjb3Zl ciBFYXN5IExpbnV4IE1pZ3JhdGlvbiBTdHJhdGVnaWVzDQpmcm9tIElCTS4gRmluZCBzaW1w bGUgdG8gZm9sbG93IFJvYWRtYXBzLCBzdHJhaWdodGZvcndhcmQgYXJ0aWNsZXMsDQppbmZv cm1hdGl2ZSBXZWJjYXN0cyBhbmQgbW9yZSEgR2V0IGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8g Z2V0IHVwIHRvDQpzcGVlZCwgZmFzdC4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9NzQ3 NyZhbGxvY19pZD0xNjQ5MiZvcD1jbGljaw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCklwc2VjLXRvb2xzLWRldmVsIG1haWxpbmcgbGlzdA0K SXBzZWMtdG9vbHMtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3Rz LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9pcHNlYy10b29scy1kZXZlbA0KDQoN CiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIw0KVGhpcyBFbWFpbCBNZXNzYWdlIGlzIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgTWF5IGNvbnRhaW4gQ09ORklE RU5USUFMIGFuZCBQUklWSUxFR0VEIGluZm9ybWF0aW9uLg0KTEcgU29mdCBJbmRpYSB3aWxs IG5vdCBiZSByZXNwb25pc2libGUgZm9yIGFueSB2aXJ1c2VzIG9yIGRlZmVjdHMgb3INCmFu eSBmb3J3YXJkZWQgYXR0YWNoZW1lbnRzIGVtYW5hdGluZyBlaXRoZXIgZnJvbSB3aXRoaW4N CkxHIFNvZnQgSW5kaWEgb3Igb3V0c2lkZS4gQW55IHVuYXV0aG9yaXNlZCByZXZpZXcgLCB1 c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IGludGVudGRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy IGJ5IHJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbA0KY29waWVzIG9mIHRoZSBvcmlnaW5h bCBtZXNzYWdlLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-17 12:19:40
|
Ravi Thanks for your reply. There are alternate ways to overcome this problem like what you have mentioned. I was wondering whether anybody has looked at a more comprehensive solution to overcome this problem rather then having a quickfix kind of a temporary solution. We were thinking of having filtering at the level of policy database where you can specify subtypes of icmp messages like ipv6-icmp-ND, you specify to allow subtypes of icmp messages. What does community think about it? Regards Bhuvi >>> "Ravi Prasad" <rav...@lg...> 6/17/2005 3:19 PM >>> Hi, We faced the same problem. We added a static IPV6 Neighbor cache entry in the freebsd machine (which was running racoon) to over come it. regards Ravi -----Original Message----- From: ips...@li... [mailto:ips...@li...] On Behalf Of Bhuvaneshwar HN Sent: Friday, June 17, 2005 11:30 AM To: cmo...@gm...; Ips...@li... Subject: Re: [Ipsec-tools-devel] ISAKMP and kernel Thanks Carlos. Does any body encountered problem that i explained with ipv6-icmp? >>> Carlos Moreno <cmo...@gm...> 6/17/2005 11:17 AM >>> Hello: First, thanks for your answer. Yesterday my isakmpd servers worked!! I think that the problem was in the configuration file when I made the IPSec connection. Sorry if I did not send a mail to explain. Thank you very much. c. 2005/6/17, Bhuvaneshwar HN <hnb...@no...>: > Hi Carlos > I just completed setting up IKE daemon on SUSE and FreeBSD and it works > fine for me. Please let me know what exactly is the problem. IPv4 works > like a dream between these computers but Ipv6 has some problems. Is any > body aware of Ipv6-icmp6 problem in Linux. > > The problem goes like this. > > We have tested Racoon with Ipv6 and it works fine except for the ICMP > messages. In IPv6 ICMP messages are used for address resolution and > hence if a policy is specifed like "Any to Any secure using ESP" then > address resolution itself fails. As a result IKE udp messages itself may > not go out. If we specify a policy like say ANY to ANY bypass all ICMP > packets then ICMP traffic is not protected. As of now there is no way to > specify something like "protect ICMP traffic with subtype X ". > > Has anybody faced problems like this? > > Regards > Bhuvi > > -- Carlos Moreno Losada =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= correo-e: cmo...@gm... jabber user: c_m...@bu... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Linux user: #263092 http://counter.li.org ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel ##################################################################### This Email Message is for the sole use of the intended recipient(s) and May contain CONFIDENTIAL and PRIVILEGED information. LG Soft India will not be responisible for any viruses or defects or any forwarded attachements emanating either from within LG Soft India or outside. Any unauthorised review , use, disclosure or distribution is prohibited. If you are not intentded recipient, please contact the sender by reply email and destroy all copies of the original message. #####################################################################HS^****X***'***u****(***j***{*2(+j***+kj********b**"**^****Z0F****l****m~**j*Z*****"**+**b***m*****vj+xg*z****b***w*v* z****)y*_j*a****l**gr**i*****jYhr'**=**rX***ly*h*[z******x%**H*****%***zYb**,***y*+****m****+-**.********+-**b***~*******%***z |
From: Peder C. N. <Ped...@er...> - 2005-06-17 12:29:42
|
On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > Ravi > Thanks for your reply. There are alternate ways to overcome this > problem like what you have mentioned. I was wondering whether anybody > has looked at a more comprehensive solution to overcome this problem > rather then having a quickfix kind of a temporary solution. > We were thinking of having filtering at the level of policy database > where you can specify subtypes of icmp messages like ipv6-icmp-ND, you > specify to allow subtypes of icmp messages. > > What does community think about it? I tried this solution which according to documentation should work: spdadd ::/0 ::/0 icmp6 135,0 -P in none; spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd ::/0 ::/0 icmp6 135,0 -P out none; spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 any -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 any -P in ipsec esp/transport//require ; This excludes Neighbor Solicitation and Neighbor Advertisement from the security policy. Unfortunately it did not work; for some reason that I have not been able to locate, IKE negotiation failed to complete under this configuration. NS and ND was not encrypted, though, so the policy itself works. So I took another attempt, a bit more clumsy, but it actually works quite well: spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require ; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require ; Here I specify explicitly that only TCP and UDP traffic should be encrypted. best regards -- Peder Chr. N=F8rgaard =09 Senior System Developer, M. Sc. Ericsson Telebit A/S =09 tel: +45 30 91 84 31 Skanderborgvej 232 =09 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Ped...@er... (old e-mail 2000-2003: Ped...@te...) (old e-mail 1992-2000: pc...@tb...) |
From: Ravi P. <rav...@lg...> - 2005-06-17 12:42:26
|
SGksDQpZb3VyIHN1Z2dlc3Rpb24gaXMgZ29vZC4gDQpJIGFtIHNvcnJ5IHRvIGRldmlhdGUg ZnJvbSB0aGUgc3ViamVjdC4gDQoNCkluIElLRXYxIHdlIGZpbHRlciBiYXNlZCBvbiBwcm90 b2NvbCBhbmQgcG9ydHMuIElDTVAvdjYgaGFzIG9ubHkgdHlwZQ0KYW5kIGNvZGUuIElOIElL RXYyIHRoaXMgY29tYmluYXRpb24gKHR5cGUgYW5kIGNvZGUpIGlzIGNvbnNpZGVyZWQgYXMg YQ0KcG9ydCBmb3IgSUNNUC92NiBtZXNzYWdlcy4gU28gd2hlbiB3ZSBzaGlmdCB0byBJS0V2 MiBJIHRoaW5rIHRoaXMgY2FzZQ0Kd2lsbCBiZSBoYW5kbGVkLiANCg0KUmVnYXJkcw0KUmF2 aSANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJodXZhbmVzaHdhciBI TiBbbWFpbHRvOmhuYmh1dmFuZXNod2FyQG5vdmVsbC5jb21dIA0KU2VudDogRnJpZGF5LCBK dW5lIDE3LCAyMDA1IDU6NDkgUE0NClRvOiBjbW9yZW5vOEBnbWFpbC5jb207IFJhdmkgUHJh c2FkOw0KSXBzZWMtdG9vbHMtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0 OiBSRTogW0lwc2VjLXRvb2xzLWRldmVsXSBJU0FLTVAgYW5kIGtlcm5lbA0KDQpSYXZpDQpU aGFua3MgZm9yIHlvdXIgcmVwbHkuIFRoZXJlIGFyZSBhbHRlcm5hdGUgd2F5cyB0byBvdmVy Y29tZSB0aGlzDQpwcm9ibGVtIGxpa2Ugd2hhdCB5b3UgaGF2ZSBtZW50aW9uZWQuIEkgd2Fz IHdvbmRlcmluZyB3aGV0aGVyIGFueWJvZHkNCmhhcyBsb29rZWQgYXQgYSBtb3JlIGNvbXBy ZWhlbnNpdmUgc29sdXRpb24gdG8gb3ZlcmNvbWUgdGhpcyBwcm9ibGVtDQpyYXRoZXIgdGhl biBoYXZpbmcgYSBxdWlja2ZpeCBraW5kIG9mIGEgdGVtcG9yYXJ5IHNvbHV0aW9uLg0KV2Ug d2VyZSB0aGlua2luZyBvZiBoYXZpbmcgZmlsdGVyaW5nIGF0IHRoZSBsZXZlbCBvZiBwb2xp Y3kgZGF0YWJhc2UNCndoZXJlIHlvdSBjYW4gc3BlY2lmeSBzdWJ0eXBlcyBvZiBpY21wIG1l c3NhZ2VzIGxpa2UgaXB2Ni1pY21wLU5ELCB5b3UNCnNwZWNpZnkgdG8gYWxsb3cgc3VidHlw ZXMgb2YgaWNtcCBtZXNzYWdlcy4NCg0KV2hhdCBkb2VzIGNvbW11bml0eSB0aGluayBhYm91 dCBpdD8NCg0KUmVnYXJkcw0KQmh1dmkNCg0KPj4+ICJSYXZpIFByYXNhZCIgPHJhdmkucHJh c2FkQGxnc29mdGluZGlhLmNvbT4gNi8xNy8yMDA1IDM6MTkgUE0gPj4+DQpIaSwNCldlIGZh Y2VkIHRoZSBzYW1lIHByb2JsZW0uIA0KV2UgYWRkZWQgYSBzdGF0aWMgSVBWNiBOZWlnaGJv ciBjYWNoZSBlbnRyeSBpbiB0aGUgZnJlZWJzZCBtYWNoaW5lDQood2hpY2ggd2FzIHJ1bm5p bmcgcmFjb29uKSB0byBvdmVyIGNvbWUgaXQuDQoNCnJlZ2FyZHMNClJhdmkgDQogDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlYy10b29scy1kZXZlbC1hZG1p bkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQpbbWFpbHRvOmlwc2VjLXRvb2xzLWRldmVsLWFk bWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mDQpCaHV2YW5lc2h3YXIg SE4NClNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAwNSAxMTozMCBBTQ0KVG86IGNtb3Jlbm84 QGdtYWlsLmNvbTsgSXBzZWMtdG9vbHMtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0K U3ViamVjdDogUmU6IFtJcHNlYy10b29scy1kZXZlbF0gSVNBS01QIGFuZCBrZXJuZWwNCg0K VGhhbmtzIENhcmxvcy4gRG9lcyBhbnkgYm9keSBlbmNvdW50ZXJlZCBwcm9ibGVtIHRoYXQg aSBleHBsYWluZWQgd2l0aA0KaXB2Ni1pY21wPw0KDQo+Pj4gQ2FybG9zIE1vcmVubyA8Y21v cmVubzhAZ21haWwuY29tPiA2LzE3LzIwMDUgMTE6MTcgQU0gPj4+DQpIZWxsbzoNCg0KRmly c3QsIHRoYW5rcyBmb3IgeW91ciBhbnN3ZXIuIA0KDQpZZXN0ZXJkYXkgbXkgaXNha21wZCBz ZXJ2ZXJzIHdvcmtlZCEhIEkgdGhpbmsgdGhhdCB0aGUgcHJvYmxlbSB3YXMgaW4NCnRoZSBj b25maWd1cmF0aW9uIGZpbGUgd2hlbiBJIG1hZGUgdGhlIElQU2VjIGNvbm5lY3Rpb24uDQoN ClNvcnJ5IGlmIEkgZGlkIG5vdCBzZW5kIGEgbWFpbCB0byBleHBsYWluLg0KDQpUaGFuayB5 b3UgdmVyeSBtdWNoLg0KDQpjLg0KDQoNCjIwMDUvNi8xNywgQmh1dmFuZXNod2FyIEhOIDxo bmJodXZhbmVzaHdhckBub3ZlbGwuY29tPjoNCj4gSGkgQ2FybG9zDQo+IEkganVzdCBjb21w bGV0ZWQgc2V0dGluZyB1cCBJS0UgZGFlbW9uIG9uIFNVU0UgYW5kIEZyZWVCU0QgYW5kIGl0 DQp3b3Jrcw0KPiBmaW5lIGZvciBtZS4gUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgZXhhY3Rs eSBpcyB0aGUgcHJvYmxlbS4gSVB2NA0Kd29ya3MNCj4gbGlrZSBhIGRyZWFtIGJldHdlZW4g dGhlc2UgY29tcHV0ZXJzIGJ1dCBJcHY2IGhhcyBzb21lIHByb2JsZW1zLiBJcw0KYW55DQo+ IGJvZHkgYXdhcmUgb2YgSXB2Ni1pY21wNiBwcm9ibGVtIGluIExpbnV4Lg0KPiANCj4gVGhl IHByb2JsZW0gZ29lcyBsaWtlIHRoaXMuDQo+IA0KPiBXZSBoYXZlIHRlc3RlZCBSYWNvb24g d2l0aCBJcHY2IGFuZCBpdCB3b3JrcyBmaW5lIGV4Y2VwdCBmb3IgdGhlDQpJQ01QDQo+IG1l c3NhZ2VzLiBJbiBJUHY2IElDTVAgbWVzc2FnZXMgYXJlIHVzZWQgZm9yIGFkZHJlc3MgcmVz b2x1dGlvbiBhbmQgDQo+IGhlbmNlIGlmIGEgcG9saWN5IGlzIHNwZWNpZmVkIGxpa2UgIkFu eSB0byBBbnkgc2VjdXJlIHVzaW5nIEVTUCINCnRoZW4NCj4gYWRkcmVzcyByZXNvbHV0aW9u IGl0c2VsZiBmYWlscy4gQXMgYSByZXN1bHQgSUtFIHVkcCBtZXNzYWdlcyBpdHNlbGYNCm1h eQ0KPiBub3QgZ28gb3V0LiBJZiB3ZSBzcGVjaWZ5IGEgcG9saWN5IGxpa2Ugc2F5IEFOWSB0 byBBTlkgYnlwYXNzIGFsbA0KSUNNUA0KPiBwYWNrZXRzIHRoZW4gSUNNUCB0cmFmZmljIGlz IG5vdCBwcm90ZWN0ZWQuIEFzIG9mIG5vdyB0aGVyZSBpcyBubw0Kd2F5DQp0bw0KPiBzcGVj aWZ5IHNvbWV0aGluZyBsaWtlICJwcm90ZWN0IElDTVAgdHJhZmZpYyB3aXRoIHN1YnR5cGUg WCAiLg0KPiANCj4gSGFzIGFueWJvZHkgZmFjZWQgcHJvYmxlbXMgbGlrZSB0aGlzPw0KPiAN Cj4gUmVnYXJkcw0KPiBCaHV2aQ0KPiANCj4gDQoNCg0KLS0NCkNhcmxvcyBNb3Jlbm8gTG9z YWRhDQo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09DQpjb3JyZW8tZTogY21vcmVu bzhAZ21haWwuY29tIA0KamFiYmVyIHVzZXI6IGNfbW9yZW5vOEBidWxtYWx1Zy5uZXQgDQo9 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09DQpMaW51eCB1c2VyOiAjMjYzMDkyDQpo dHRwOi8vY291bnRlci5saS5vcmcgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU0YuTmV0IGVtYWlsIGlzIHNwb25zb3Jl ZCBieTogRGlzY292ZXIgRWFzeSBMaW51eCBNaWdyYXRpb24gU3RyYXRlZ2llcw0KZnJvbSBJ Qk0uIEZpbmQgc2ltcGxlIHRvIGZvbGxvdyBSb2FkbWFwcywgc3RyYWlnaHRmb3J3YXJkIGFy dGljbGVzLA0KaW5mb3JtYXRpdmUgV2ViY2FzdHMgYW5kIG1vcmUhIEdldCBldmVyeXRoaW5n IHlvdSBuZWVkIHRvIGdldCB1cCB0bw0Kc3BlZWQsIGZhc3QuIGh0dHA6Ly9hZHMub3Nkbi5j b20vP2FkX2lkdDc3JmFsbG9jX2lkNDkyJm9wPWNsaWNrIA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklwc2VjLXRvb2xzLWRldmVsIG1haWxp bmcgbGlzdA0KSXBzZWMtdG9vbHMtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vaXBzZWMtdG9vbHMt ZGV2ZWwgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KU0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogRGlzY292ZXIg RWFzeSBMaW51eCBNaWdyYXRpb24gU3RyYXRlZ2llcw0KZnJvbSBJQk0uIEZpbmQgc2ltcGxl IHRvIGZvbGxvdyBSb2FkbWFwcywgc3RyYWlnaHRmb3J3YXJkIGFydGljbGVzLA0KaW5mb3Jt YXRpdmUgV2ViY2FzdHMgYW5kIG1vcmUhIEdldCBldmVyeXRoaW5nIHlvdSBuZWVkIHRvIGdl dCB1cCB0bw0Kc3BlZWQsIGZhc3QuIGh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkPTc0Nzcm YWxsb2NfaWQ9MTY0OTImb3A9Y2xpY2sgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSXBzZWMtdG9vbHMtZGV2ZWwgbWFpbGluZyBsaXN0DQpJ cHNlYy10b29scy1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQpodHRwczovL2xpc3Rz LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9pcHNlYy10b29scy1kZXZlbCANCg0K DQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMNClRoaXMgRW1haWwgTWVzc2FnZSBpcyBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgYW5kDQpNYXkgY29udGFpbiBDT05G SURFTlRJQUwgYW5kIFBSSVZJTEVHRUQgaW5mb3JtYXRpb24uDQpMRyBTb2Z0IEluZGlhIHdp bGwgbm90IGJlIHJlc3BvbmlzaWJsZSBmb3IgYW55IHZpcnVzZXMgb3IgZGVmZWN0cyBvcg0K YW55IGZvcndhcmRlZCBhdHRhY2hlbWVudHMgZW1hbmF0aW5nIGVpdGhlciBmcm9tIHdpdGhp bg0KTEcgU29mdCBJbmRpYSBvciBvdXRzaWRlLiBBbnkgdW5hdXRob3Jpc2VkIHJldmlldyAs IHVzZSwgZGlzY2xvc3VyZSBvcg0KZGlzdHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IGludGVudGRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbA0KY29waWVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjSFNeDQoqKioqWCoqKicqKip1KioqKigq KipqKioqeyoyKCtqKioqK2tqKioqKioqKipiKioiKipeKioqKlowRioqKipsKioqKm1+KioN CmoqWioqKioqIioqKyoqYioqKm0qKioqKnZqK3hnKnoqKioqYioqKncqdioNCnoqKioqKXkq X2oqYSoqKipsKipncioqaSoqKioqallocicqKj0qKnJYKioqbHkqaCpbeioqKioqKnglKipI KioqKiolKioqeg0KWWIqKiwqKip5KisqKioqbSoqKiorLSoqLioqKioqKioqKy0qKmIqKip+ KioqKioqKiUqKip6DQoNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQpUaGlzIEVtYWlsIE1lc3NhZ2Ug aXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGFuZCBN YXkgY29udGFpbiBDT05GSURFTlRJQUwgYW5kIFBSSVZJTEVHRUQgaW5mb3JtYXRpb24uDQpM RyBTb2Z0IEluZGlhIHdpbGwgbm90IGJlIHJlc3BvbmlzaWJsZSBmb3IgYW55IHZpcnVzZXMg b3IgZGVmZWN0cyBvcg0KYW55IGZvcndhcmRlZCBhdHRhY2hlbWVudHMgZW1hbmF0aW5nIGVp dGhlciBmcm9tIHdpdGhpbg0KTEcgU29mdCBJbmRpYSBvciBvdXRzaWRlLiBBbnkgdW5hdXRo b3Jpc2VkIHJldmlldyAsIHVzZSwgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gaXMgcHJv aGliaXRlZC4gSWYgeW91IGFyZSBub3QgaW50ZW50ZGVkDQpyZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlc3Ryb3kgYWxsDQpjb3Bp ZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyM= |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-17 13:05:45
|
Hi Peder Thanks for your quick reply >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require= ; >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require= ; >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; This works even for me but how do you do it for icmp?. Reg Bhuvi >>> "Peder Chr. Norgaard" <Ped...@er...> 6/17/2005 5:59 = PM >>> On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > Ravi > Thanks for your reply. There are alternate ways to overcome this > problem like what you have mentioned. I was wondering whether anybody > has looked at a more comprehensive solution to overcome this problem > rather then having a quickfix kind of a temporary solution. > We were thinking of having filtering at the level of policy database > where you can specify subtypes of icmp messages like ipv6-icmp-ND, you > specify to allow subtypes of icmp messages. > > What does community think about it? I tried this solution which according to documentation should work: spdadd ::/0 ::/0 icmp6 135,0 -P in none; spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd ::/0 ::/0 icmp6 135,0 -P out none; spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 any -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 any -P in ipsec esp/transport//require = ; This excludes Neighbor Solicitation and Neighbor Advertisement from the security policy. Unfortunately it did not work; for some reason that I have not been able to locate, IKE negotiation failed to complete under this configuration. NS and ND was not encrypted, though, so the policy itself works. So I took another attempt, a bit more clumsy, but it actually works quite well: spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; Here I specify explicitly that only TCP and UDP traffic should be encrypted. best regards -- Peder Chr. N=F8rgaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 30 91 84 31 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Ped...@er...=20 (old e-mail 2000-2003: Ped...@te...) (old e-mail 1992-2000: pc...@tb...) ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=3Dclick=20 _______________________________________________ Ipsec-tools-devel mailing list Ips...@li...=20 https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Peder C. N. <Ped...@er...> - 2005-06-17 13:14:46
|
On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > > Hi Peder > Thanks for your quick reply > > >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requi= re ; > >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//requir= e ; > >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requi= re ; > >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//requir= e ; > > This works even for me but how do you do it for icmp?. > Sorry, I am not sure I understand the question. Do what? With this setup no ICMPv6 is encrypted; neither Neighbor Discovery, which is the intention, nor Echo Request/Reply which may or may not be the intention. best regards -- Peder Chr. N=F8rgaard =09 Senior System Developer, M. Sc. Ericsson Telebit A/S =09 tel: +45 30 91 84 31 Skanderborgvej 232 =09 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Ped...@er... (old e-mail 2000-2003: Ped...@te...) (old e-mail 1992-2000: pc...@tb...) |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-17 13:18:20
|
Peder sorry, I thought icmp was encrypted because there was no icmp specified in = the policy. Thanks Reg Bhuvi >>> "Peder Chr. Norgaard" <Ped...@er...> 6/17/2005 6:44 = PM >>> On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > > Hi Peder > Thanks for your quick reply > > >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requi= re ; > >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//requir= e ; > >spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requi= re ; > >spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//requir= e ; > > This works even for me but how do you do it for icmp?. > Sorry, I am not sure I understand the question. Do what? With this setup no ICMPv6 is encrypted; neither Neighbor Discovery, which is the intention, nor Echo Request/Reply which may or may not be the intention. best regards -- Peder Chr. N=F8rgaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 30 91 84 31 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Ped...@er...=20 (old e-mail 2000-2003: Ped...@te...) (old e-mail 1992-2000: pc...@tb...) |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-06-27 07:58:04
|
Peder >I tried this solution which according to documentation should work: >spdadd ::/0 ::/0 icmp6 135,0 -P in none; >spdadd ::/0 ::/0 icmp6 136,0 -P out none; >spdadd ::/0 ::/0 icmp6 135,0 -P out none; >spdadd ::/0 ::/0 icmp6 136,0 -P in none; The above policy should essentially allow packets 135, 136 which are = Neighbor solicitation and neighbor advertisement. We have seen the code = and the sniffer packets, it actually bypasses these messages but the = connection does not get established because IKE negotiation failure. We are working on a Fix for this. Is there anybody working on the fix for this, please let us know. Regards Bhuvi >>> "Peder Chr. Norgaard" <Ped...@er...> 6/17/2005 = 5:59:25 PM >>> On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > Ravi > Thanks for your reply. There are alternate ways to overcome this > problem like what you have mentioned. I was wondering whether anybody > has looked at a more comprehensive solution to overcome this problem > rather then having a quickfix kind of a temporary solution. > We were thinking of having filtering at the level of policy database > where you can specify subtypes of icmp messages like ipv6-icmp-ND, you > specify to allow subtypes of icmp messages. > > What does community think about it? I tried this solution which according to documentation should work: spdadd ::/0 ::/0 icmp6 135,0 -P in none; spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd ::/0 ::/0 icmp6 135,0 -P out none; spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 any -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 any -P in ipsec esp/transport//require = ; This excludes Neighbor Solicitation and Neighbor Advertisement from the security policy. Unfortunately it did not work; for some reason that I have not been able to locate, IKE negotiation failed to complete under this configuration. NS and ND was not encrypted, though, so the policy itself works. So I took another attempt, a bit more clumsy, but it actually works quite well: spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require = ; spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require = ; Here I specify explicitly that only TCP and UDP traffic should be encrypted. best regards -- Peder Chr. N=F8rgaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 30 91 84 31 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Ped...@er...=20 (old e-mail 2000-2003: Ped...@te...) (old e-mail 1992-2000: pc...@tb...) |
From: Dietmar E. <die...@gm...> - 2005-06-27 17:42:02
Attachments:
policy.patch
|
Hi Bhuvi, I sent out mail concerning this issue on 06/02/2005 with subject "Re: [Ipsec-tools-devel] Problems with getting racoon and IPv6 Neighbor Discovery to work properly" but haven't got any response back so far. See the original message below. The corresponding patch is attached. -- Dietmar Hi, I get the same problem, while trying to make IPsec with dynamic keying work together with ND. I figured that this problem is related to racoon's phase 2 responder code. The getsp_r() call for inbound policies in get_proposal_r() [isakmp_quick.c] returns the secpolicy entry p related to a "None" Policy (spdadd ::/0 ::/0 icmp6 135,0 -P in none;), since all the selectors (dir, ul_proto, src addr and port, dst addr and port) match (wildcard). BTW, even if you get rid of the NS (135) "None" entry, since NS is send out with the solicited-node address as dest address, you still have the NA (136) "None" Entry since you don't know that you will be the responder. Later in get_proposal_r(), the policy of p is checked and if it's not IPSEC_POLICY_IPSEC, get_proposal_r() returns ISAKMP_INTERNAL_ERROR and the responder side never sends out the phase2 msg. I'm wondering why getsp_r() for inbound policies has to deal with Policies other than "IPsec" and applied the following patch, which lets the responder side work in phase2 like expected. Its actually only checking (i.e. applying cmpspidxwild() on) the "IPsec" Policies. I'm not sure, why racoon has to know about Policies other than "IPsec" (i.e "None" and "Discard) in the first place. Maybe, the import of Policies, other then "Ipsec", can be prevented? This would be another solution. Comments appriciated. -- Dietmar my setup: responder (ipsec tools head on linux kernel 2.6.11.7, address 2001:DB8::1) setkey.conf spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd 2001:DB8::1[any] 2001:DB8::2[any] any -P out ipsec esp/transport//require; spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd 2001:DB8::2[any] 2001:DB8::1[any] any -P in ipsec esp/transport//require; initiator (ipsec tools head on linux kernel 2.6.10 (modified), address 2001:DB8::2) setkey.conf spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd 2001:DB8::2[any] 2001:DB8::1[any] any -P out ipsec esp/transport//require; spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd 2001:DB8::1[any] 2001:DB8::2[any] any -P in ipsec esp/transport//require; racoon.conf for both sides: path pre_shared_key "/etc/ipsec-tools_test/psk.txt"; log debug2; remote anonymous { exchange_mode main; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo anonymous { encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; } 10.337964 2001:db8::2 -> ff02::1:ff00:1 ICMPv6 Neighbor solicitation 10.338029 2001:db8::1 -> 2001:db8::2 ICMPv6 Neighbor advertisement 10.338131 2001:db8::2 -> 2001:db8::1 ISAKMP Identity Protection (Main Mode) 10.708504 2001:db8::1 -> 2001:db8::2 ISAKMP Identity Protection (Main Mode) 10.733512 2001:db8::2 -> 2001:db8::1 ISAKMP Identity Protection (Main Mode) 10.874514 2001:db8::1 -> 2001:db8::2 ISAKMP Identity Protection (Main Mode) 10.903832 2001:db8::2 -> 2001:db8::1 ISAKMP Identity Protection (Main Mode) 11.653818 2001:db8::1 -> 2001:db8::2 ISAKMP Identity Protection (Main Mode) 11.657447 2001:db8::2 -> 2001:db8::1 ISAKMP Informational 11.660989 2001:db8::2 -> 2001:db8::1 ISAKMP Quick Mode 11.883650 2001:db8::1 -> 2001:db8::2 ISAKMP Informational 13.295089 2001:db8::1 -> 2001:db8::2 ISAKMP Quick Mode 13.301558 2001:db8::2 -> 2001:db8::1 ISAKMP Quick Mode 14.335095 2001:db8::2 -> 2001:db8::1 ESP ESP (SPI=0x0508e100) 14.335216 2001:db8::1 -> 2001:db8::2 ESP ESP (SPI=0x042ed06c) Bhuvaneshwar HN wrote: > Peder > > >>I tried this solution which according to documentation should work: > > >>spdadd ::/0 ::/0 icmp6 135,0 -P in none; >>spdadd ::/0 ::/0 icmp6 136,0 -P out none; >>spdadd ::/0 ::/0 icmp6 135,0 -P out none; >>spdadd ::/0 ::/0 icmp6 136,0 -P in none; > > > The above policy should essentially allow packets 135, 136 which are Neighbor solicitation and neighbor advertisement. We have seen the code and the sniffer packets, it actually bypasses these messages but the connection does not get established because IKE negotiation failure. > > We are working on a Fix for this. > > Is there anybody working on the fix for this, please let us know. > > Regards > Bhuvi > > >>>>"Peder Chr. Norgaard" <Ped...@er...> 6/17/2005 5:59:25 PM >>> > > On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: > > >>Ravi >>Thanks for your reply. There are alternate ways to overcome this >>problem like what you have mentioned. I was wondering whether anybody >>has looked at a more comprehensive solution to overcome this problem >>rather then having a quickfix kind of a temporary solution. >>We were thinking of having filtering at the level of policy database >>where you can specify subtypes of icmp messages like ipv6-icmp-ND, you >>specify to allow subtypes of icmp messages. >> >>What does community think about it? > > > I tried this solution which according to documentation should work: > > spdadd ::/0 ::/0 icmp6 135,0 -P in none; > spdadd ::/0 ::/0 icmp6 136,0 -P out none; > spdadd ::/0 ::/0 icmp6 135,0 -P out none; > spdadd ::/0 ::/0 icmp6 136,0 -P in none; > > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 any -P out ipsec esp/transport//require ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 any -P in ipsec esp/transport//require ; > > This excludes Neighbor Solicitation and Neighbor Advertisement from the > security policy. > > Unfortunately it did not work; for some reason that I have not been able > to locate, IKE negotiation failed to complete under this configuration. > NS and ND was not encrypted, though, so the policy itself works. > > So I took another attempt, a bit more clumsy, but it actually works quite > well: > > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require ; > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//require ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require ; > > Here I specify explicitly that only TCP and UDP traffic should be > encrypted. > > best regards > -- > Peder Chr. Nørgaard Senior System Developer, M. Sc. > Ericsson Telebit A/S tel: +45 30 91 84 31 > Skanderborgvej 232 fax: +45 89 38 51 01 > DK-8260 Viby J, Denmark > e-mail: Ped...@er... > (old e-mail 2000-2003: Ped...@te...) > (old e-mail 1992-2000: pc...@tb...) > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > |
From: Bhuvaneshwar H. <hnb...@no...> - 2005-07-26 09:09:38
|
Aidas What will happen to this case which is prevalent in the existing code, Index: ipsec-tools/src/racoon/sockmisc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/ipsec-tools/ipsec-tools/src/racoon/sockmisc.c,v retrieving revision 1.21 diff -u -p -r1.21 sockmisc.c --- ipsec-tools/src/racoon/sockmisc.c 29 Jun 2005 11:21:31 -0000 = 1.21 +++ ipsec-tools/src/racoon/sockmisc.c 18 Jul 2005 09:55:26 -0000 @@ -174,9 +174,7 @@ cmpsaddrwild(addr1, addr2) sa2 =3D (caddr_t)&((struct sockaddr_in6 *)addr2)->sin6_addr= ; port1 =3D ((struct sockaddr_in6 *)addr1)->sin6_port; port2 =3D ((struct sockaddr_in6 *)addr2)->sin6_port; - if (!(port1 =3D=3D IPSEC_PORT_ANY || - port2 =3D=3D IPSEC_PORT_ANY || - port1 =3D=3D port2)) + if ( port1 !=3D port2 ) return 1; if (memcmp(sa1, sa2, sizeof(struct in6_addr)) !=3D 0) return 1; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D with the following SPD > spdadd ::/0 ::/0 icmp6 135,0 -P in none; > spdadd ::/0 ::/0 icmp6 135,0 -P out none; > spdadd ::/0 ::/0 icmp6 136,0 -P in none; > spdadd ::/0 ::/0 icmp6 136,0 -P out none; > =20 > spdadd 3ffe::2 3ffe::33 any -P in ipsec esp/transport//require; > spdadd 3ffe::33 3ffe::2 any -P out ipsec esp/transport//require; the packet coming from 3ffe::2, which is having any in the protocol field, = which is having port zero will get compared with the port of icmp6 which = is 136 which apparently is at the beginning of the DB list in IKE .=20 port1 is 0 so .. it falls thru the comparison and finally says that a = match is found with the policy being none ;=20 this is the reason why the above configuration is not working . If we are able to order the policy list in the DB in such a way that the = policy with "any" protocol has a relatively higher priority than "non any" = protocol then the issue is resolved . this goes in conjunction with the = code in which PORT_ANY is checked at the beginning and if that is the case = then it is treated as a success match .=20 Do you think the ordering in the configuration itself is wrong?. Regards Bhuvi >>> Aidas Kasparas <a.k...@gm...> 7/22/2005 3:46:11 PM >>> Sainath, That is by design. Security Policies are more like iptables rules = and not routing table entries. "Longest netmask wins" principle do not apply here. Doing like you propose would break RFC 2401 sec. 4.4.1 pars. 4, 9, which in part states: <...> The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support (total) ordering of these entries. <...> <...> SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. <...> Therefore, neither kernel, nor isakmp daemon can allow itself reordering of SPD entries. These entries MUST be checked in order they are in SPD. But, as an admin, you're free to put these entries in "right" order. To achieve that you may employ order of insertion and priorities (note, that there are 2^32 of possible values of priorities, not only low, normal and high). Sainath Vellal wrote: >=20 > Hello , > Instead of restricting the policy check to IPSEC_POLICY_IPSEC , ( which > incidentally only selects ipsec related policies and not the "none" and > "discard " policies , I think it would be better to rearrange the policy > order in the DB ( sptree ) as { high priority , low priority } (which is > done as of now ) and then in each priority as { any , non-any > protocol } . since the protocol_any check is made at the beginning of > each comparision in getsp_r() , > rearranging the policy db in IKE to reflect this order of checking would > be good enough and consistent for the future implementations too . > =20 > problem actually is that , cmpspidxwild() is trying to extract the first > possible match of a policy ( not the best possible ) . > =20 > =20 > Below is attached a patch aimed at that . change is in inssp() function = . > =20 > my setup. > initiator : > setkey.conf > =20 > =20 > spdadd ::/0 ::/0 icmp6 135,0 -P in none; > spdadd ::/0 ::/0 icmp6 135,0 -P out none; > spdadd ::/0 ::/0 icmp6 136,0 -P in none; > spdadd ::/0 ::/0 icmp6 136,0 -P out none; > =20 > spdadd 3ffe::2 3ffe::33 any -P in ipsec esp/transport//require; > spdadd 3ffe::33 3ffe::2 any -P out ipsec esp/transport//require; > =20 > responder: > setkey.conf > =20 > =20 > spdadd ::/0 ::/0 icmp6 135,0 -P in none; > spdadd ::/0 ::/0 icmp6 135,0 -P out none; > spdadd ::/0 ::/0 icmp6 136,0 -P in none; > spdadd ::/0 ::/0 icmp6 136,0 -P out none; > =20 > spdadd 3ffe::33 3ffe::2 any -P in ipsec esp/transport//require; > spdadd 3ffe::2 3ffe::33 any -P out ipsec esp/transport//require; > =20 > racoon.conf same for both : > =20 > path pre_shared_key "/etc/racoon/psk.txt"; > remote anonymous > { > exchange_mode main,aggressive; > doi ipsec_doi; > situation identity_only; > =20 > my_identifier address; > =20 > =20 > nonce_size 16; > initial_contact on; > proposal_check obey; # obey, strict or claim > =20 > proposal { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > } > }remote ::1 [8000] > { > exchange_mode main,aggressive; > doi ipsec_doi; > situation identity_only; > =20 > =20 > nonce_size 16; > lifetime time 1 min; # sec,min,hour > =20 > proposal { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > } > } > sainfo anonymous > { > pfs_group 2; > encryption_algorithm 3des; > authentication_algorithm hmac_sha1; > compression_algorithm deflate; > } > =20 > Regards , > Sainath > =20 > =20 > =20 > =20 > Hi Bhuvi, > =20 > I sent out mail concerning this issue on 06/02/2005 with subject "Re: > [Ipsec-tools-devel] Problems with getting racoon and IPv6 Neighbor > Discovery to > work properly" but haven"t got any response back so far. > See the original message below. The corresponding patch is attached. > =20 > -- Dietmar > =20 > =20 >=20 >>>>Bhuvaneshwar HN 06/27/05 12:57 am >>> > Peder >=20 >>I tried this solution which according to documentation should work: >=20 >>spdadd ::/0 ::/0 icmp6 135,0 -P in none; >>spdadd ::/0 ::/0 icmp6 136,0 -P out none; >>spdadd ::/0 ::/0 icmp6 135,0 -P out none; >>spdadd ::/0 ::/0 icmp6 136,0 -P in none; >=20 > The above policy should essentially allow packets 135, 136 which are > Neighbor solicitation and neighbor advertisement. We have seen the code > and the sniffer packets, it actually bypasses these messages but the > connection does not get established because IKE negotiation failure. >=20 > We are working on a Fix for this. >=20 > Is there anybody working on the fix for this, please let us know. >=20 > Regards > Bhuvi >=20 >>>>"Peder Chr. Norgaard" <Ped...@er...> 6/17/2005 > 5:59:25 PM >>> > On Fri, 17 Jun 2005, Bhuvaneshwar HN wrote: >=20 >>Ravi >>Thanks for your reply. There are alternate ways to overcome this >>problem like what you have mentioned. I was wondering whether anybody >>has looked at a more comprehensive solution to overcome this problem >>rather then having a quickfix kind of a temporary solution. >>We were thinking of having filtering at the level of policy database >>where you can specify subtypes of icmp messages like ipv6-icmp-ND, you >>specify to allow subtypes of icmp messages. >> >>What does community think about it? >=20 > I tried this solution which according to documentation should work: >=20 > spdadd ::/0 ::/0 icmp6 135,0 -P in none; > spdadd ::/0 ::/0 icmp6 136,0 -P out none; > spdadd ::/0 ::/0 icmp6 135,0 -P out none; > spdadd ::/0 ::/0 icmp6 136,0 -P in none; >=20 > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 any -P out ipsec esp/transport//requir= e ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 any -P in ipsec esp/transport//require= ; >=20 > This excludes Neighbor Solicitation and Neighbor Advertisement from the > security policy. >=20 > Unfortunately it did not work; for some reason that I have not been able > to locate, IKE negotiation failed to complete under this configuration. > NS and ND was not encrypted, though, so the policy itself works. >=20 > So I took another attempt, a bit more clumsy, but it actually works = quite > well: >=20 > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requir= e ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require= ; > spdadd 3ffe:0:0:2::2 3ffe:0:0:2::3 tcp -P out ipsec esp/transport//requir= e ; > spdadd 3ffe:0:0:2::3 3ffe:0:0:2::2 udp -P in ipsec esp/transport//require= ; >=20 > Here I specify explicitly that only TCP and UDP traffic should be > encrypted. >=20 > best regards >=20 > Peder Chr. N=F8rgaard Senior System Developer, M. Sc. > Ericsson Telebit A/S tel: +45 30 91 84 31 > Skanderborgvej 232 fax: +45 89 38 51 01 > DK-8260 Viby J, Denmark > e-mail: Ped...@er...=20 > <mailto:Ped...@er...> > (old e-mail 2000-2003: Ped...@te...=20 > <mailto:Ped...@te...> ) > (old e-mail 1992-2000: pc...@tb... <mailto:pc...@tb...> ) --=20 Aidas Kasparas IT administrator GM Consult Group, UAB ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=3Dclick=20 _______________________________________________ Ipsec-tools-devel mailing list Ips...@li...=20 https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Aidas K. <a.k...@gm...> - 2005-07-26 13:30:06
|
Bhuvaneshwar HN wrote: > with the following SPD > >>spdadd ::/0 ::/0 icmp6 135,0 -P in none; >>spdadd ::/0 ::/0 icmp6 135,0 -P out none; >>spdadd ::/0 ::/0 icmp6 136,0 -P in none; >>spdadd ::/0 ::/0 icmp6 136,0 -P out none; >> >>spdadd 3ffe::2 3ffe::33 any -P in ipsec esp/transport//require; >>spdadd 3ffe::33 3ffe::2 any -P out ipsec esp/transport//require; > > > the packet coming from 3ffe::2, which is having any in the protocol > field, which is having port zero will get compared with the port of > icmp6 which is 136 which apparently is at the beginning of the DB > list in IKE . port1 is 0 so .. it falls thru the comparison and > finally says that a match is found with the policy being none ; this > is the reason why the above configuration is not working . Bhuvi, racoon is not directly involved in processing incoming packets. If 3ffe::2 (remote, I suppose) wants to send packet to 3ffe::33, then the following things should happen: 1) remote kernel (at 3ffe::2) intercepts that packet, 2) remote kernel finds no SA, 3) remote kernel asks remote racoon to get SA; 4) remote racoon contacts local racoon, they negotiate SAs; 5) remote kernel adds ipsec headers and sends packet; 6a) local kernel checks SPD, from packet's headers finds SA in local SA database, checks if crypto is ok, strips ipsec headers, reinserts packet without ipsec headers into ip packet processing machine; 6b) if anything in 6a fails, packet is droped At what stage things go wrong? Or do they go wrong, if local side wants to send something? Could you please provide list of packets and what (if any) ipsec services these packets should be aforded. I still do not understand the problem => can not suggest a cure for it. As for patch, then as is it MUST NOT be applied. Function cmpsaddrwild() is supposed to make comparisons with "wildcards", i.e. ports set to any. This functionality is needed in several places in racoon's code. And you suggest to remove that. BUT, I think we may need another socket address comparison function (which would allow only one port to be wildcard -- the one which commes from policy, and not from packet) and methodically inspect which function we use in which place. -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Dietmar E. <die...@gm...> - 2005-07-27 04:43:56
|
Hi Aidas, let me try to explain where I think something is going wrong. I have a similar setup like Bhuvi: ESP transport connection with dynamic key exchange (racoon) between Initiator (I) (3ffa::1) and Responder (R) (3ffa::2) on linux 2.6.10 kernel. (1) SPD setup without 'none' Policies for ICMPv6 Neighbor Advertisement (NA) msgs: I set the following Policies on the (I): spdadd 3ffa::1[any] 3ffa::2[any] any -P out ipsec esp/transport//require; spdadd 3ffa::2[any] 3ffa::1[any] any -P in ipsec esp/transport//require; and on (R): spdadd 3ffa::2[any] 3ffa::1[any] any -P out ipsec esp/transport//require; spdadd 3ffa::1[any] 3ffa::2[any] any -P in ipsec esp/transport//require; - tethereal log on (I): 9494.916758 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9502.948613 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 9502.949526 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9503.949385 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9504.949232 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9512.946301 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 9512.948013 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9513.947863 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 9514.947714 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation ... The Neighbor Solicitation (NS) msg is not answered by (R), i.e. (R) doesn't send out a NA msg. Racoon on (R) tries to start ISAKMP negotiation instead. That's why, I think that I need the 'none' Policy entries for NA messages to let Neighbor Discovery finish. (2) SPD setup with 'none' Policies for NA msgs: I set the following Policies on the (I): spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd 3ffa::1[any] 3ffa::2[any] any -P out ipsec esp/transport//require; spdadd 3ffa::2[any] 3ffa::1[any] any -P in ipsec esp/transport//require; and on (R): spdadd ::/0 ::/0 icmp6 136,0 -P in none; spdadd ::/0 ::/0 icmp6 136,0 -P out none; spdadd 3ffa::2[any] 3ffa::1[any] any -P out ipsec esp/transport//require; spdadd 3ffa::1[any] 3ffa::2[any] any -P in ipsec esp/transport//require; Running `ping6 -I 3ffa::1 3ffa::2` on (I) will start the key exchange. The problem arises in Quick mode on (R). - racoon log file snippet on (R): 2005-07-26 13:30:52: INFO: respond new phase 1 negotiation: 3ffa::2[500]<=>3ffa::1[500] 2005-07-26 13:30:52: INFO: begin Identity Protection mode. 2005-07-26 13:30:52: INFO: ISAKMP-SA established 3ffa::2[500]-3ffa::1[500] spi:58443a8ca54102da:0ea006c69f3eee9a 2005-07-26 13:30:53: INFO: respond new phase 2 negotiation: 3ffa::2[0]<=>3ffa::1[0] 2005-07-26 13:30:53: ERROR: policy found, but no IPsec required: 3ffa::2/128[0] 3ffa::1/128[0] proto=any dir=out 2005-07-26 13:30:53: ERROR: failed to get proposal for responder. 2005-07-26 13:30:53: ERROR: failed to pre-process packet. - tethereal log on I: 27.310408 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 27.310636 3ffa::2 -> 3ffa::1 ICMPv6 Neighbor advertisement 27.310659 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 27.331893 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 27.350278 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 27.466713 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 27.523082 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 27.525198 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 27.525974 3ffa::2 -> 3ffa::1 ISAKMP Informational 27.529070 3ffa::1 -> 3ffa::2 ISAKMP Informational 28.532784 3ffa::1 -> 3ffa::2 ISAKMP Quick Mode ... Racoon on (R) says that it found a (inbound) Policy but this Policy doesn't require IPsec and it gives up, i.e. never answers the Quick Mode msg sent out by (I). That's the check for the inbound Policy being an 'ipsec' Policy in get_proposal_r(). That's because the 'none' Policy for the NA msg is a wildcard match for racoon when it calls getsp_r() -> cmpspidxwild() in get_proposal_r(). Since getsp_r() is currently only called in get_proposal_r() (twice, once for inbound and once for outbound Policy), I changed the code in getsp_r() in such a way that when cmpspidxwild() finds a matching Policy, it must also be an 'ipsec' Policy. Otherwise getsp_r() keeps looking. With this patch I can get `ping6 -I 3ffa::1 3ffa::2` from (I) working. - tethereal log on I: 3.487791 3ffa::1 -> ff02::1:ff00:2 ICMPv6 Neighbor solicitation 3.488082 3ffa::2 -> 3ffa::1 ICMPv6 Neighbor advertisement 3.488105 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 4.319758 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 4.338714 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 4.662924 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 4.680369 3ffa::1 -> 3ffa::2 ISAKMP Identity Protection (Main Mode) 5.952744 3ffa::2 -> 3ffa::1 ISAKMP Identity Protection (Main Mode) 5.956043 3ffa::1 -> 3ffa::2 ISAKMP Informational 6.398882 3ffa::2 -> 3ffa::1 ISAKMP Informational 6.403549 3ffa::1 -> 3ffa::2 ISAKMP Quick Mode 9.204214 3ffa::2 -> 3ffa::1 ISAKMP Quick Mode 9.210071 3ffa::1 -> 3ffa::2 ISAKMP Quick Mode 10.273813 3ffa::1 -> 3ffa::2 ESP ESP (SPI=0x04836012) 10.274157 3ffa::2 -> 3ffa::1 ESP ESP (SPI=0x065e9101) ... I'm not sure that this won't break other stuff so I would like to hear from other folks what they think about this issue. So far, I only saw a workaround by making the upperspec field for the original SPD entries more specific than 'any' (e.g. tcp or udp). But this won't help for ping6. I haven't tried to put the NA msg related Policies behind the two Policies for the actual IPsec connection. But I'm afraid then the kernel will match the outbound Policy for the actual IPsec connection with the NA msg flow parameter. -- Dietmar patch against HEAD: --- ipsec-tools/src/racoon/policy.c 2004-11-17 12:03:37.000000000 -0700 +++ ipsec-tools_new/src/racoon/policy.c 2005-07-26 14:14:16.000000000 -0700 @@ -86,6 +86,7 @@ * transport mode SA negotiation. for example, 0.0.0.0/0 -> 0.0.0.0/0 * entry in policy.txt can be returned when we're negotiating transport * mode SA. this is how the kernel works. + * Consider only security table entries with IPsec policy */ #if 1 struct secpolicy * @@ -95,7 +96,7 @@ struct secpolicy *p; for (p = TAILQ_FIRST(&sptree); p; p = TAILQ_NEXT(p, chain)) { - if (!cmpspidxwild(spidx, &p->spidx)) + if (p->policy == IPSEC_POLICY_IPSEC && !cmpspidxwild(spidx, &p->spidx)) return p; } --- ipsec-tools/src/racoon/isakmp_quick.c 2005-07-20 01:01:37.000000000 -0700 +++ ipsec-tools_new/src/racoon/isakmp_quick.c 2005-07-26 14:15:23.000000000 -0700 @@ -2114,17 +2114,6 @@ plog(LLV_DEBUG, LOCATION, NULL, "suitable SP found:%s\n", spidx2str(&spidx)); - /* - * In the responder side, the inbound policy should be using IPsec. - * outbound policy is not checked currently. - */ - if (sp_in->policy != IPSEC_POLICY_IPSEC) { - plog(LLV_ERROR, LOCATION, NULL, - "policy found, but no IPsec required: %s\n", - spidx2str(&spidx)); - return ISAKMP_INTERNAL_ERROR; - } - /* set new proposal derived from a policy into the iph2->proposal. */ if (set_proposal_from_policy(iph2, sp_in, sp_out) < 0) { plog(LLV_ERROR, LOCATION, NULL, |