[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(racoon 937) Re: IPv6 with IPsec on FreeBSD 4.10-R with racoon-20040408a



Hi,

This may be attributeable to Neighbor Discovery.
Please observe packets carefully with tcpdump(1) and so on.

> When setting up IPsec at my home using FreeBSD 4.10-RELEASE and
> racoon-20040408a, I came across a problem with IPv6 and IPsec.
> 
> First, here is the relevant information about my setup.
> 
> I have two computers in my network, each assigned a global unicast
> address (do not worry about my abuse of these unicast addresses, my
> network is completely isolated from the Internet):
> 
> Computer A is assigned 2001:0:2:3:20a:5eff:fe47:9709, and
> Computer B is assigned 2001:0:2:3:260:8ff:fe7f:68b1
> 
> Both computers runs a 4.10-RELEASE kernel compiled with:
> 
> options INET
> options INET6
> options IPSEC
> options IPSEC_ESP
> options IPSEC_DEBUG
> 
> Both computers use racoon-20040408a, installed as a precompiled package,
> for dynamical keying.
> 
> The racoon.conf on both computers looks like this:
> 
> path include "/etc/racoon";
> path pre_shared_key "/etc/racoon/pre_shared_keys";
> 
> timer {
> 	counter 20;
> 	interval 25 sec;
> 	phase1 20 sec;
> 	phase2 20 sec;
> }
> 
> remote anonymous {
> 	exchange_mode main,aggressive,base;
> 	doi ipsec_doi;
> 	situation identity_only;
> 	my_identifier address;
> 	lifetime time 1 hour;
> 	initial_contact on;
> 	passive off;
> 	proposal_check obey;
> 	send_cert off;
> 	send_cr off;
> 	verify_cert off;
> 
> 	proposal {
> 		encryption_algorithm blowfish;
> 		hash_algorithm sha1;
> 		authentication_method pre_shared_key;
> 		dh_group 2;
> 	}
> }
> 
> sainfo anonymous {
> 	pfs_group 2;
> 	lifetime time 30 min;
> 	encryption_algorithm blowfish 448,rijndael 256,cast128,3des;
> 	authentication_algorithm hmac_sha1,hmac_md5;
> 	compression_algorithm deflate;
> }
> 
> I have trimmed the IPsec policy rules down to these ones (taken from
> computer A):
> 
> # Flush the entries.
> spdflush;
> 
> # ISAKMP between computers A and B may use ESP and AH.
> spdadd 2001:0:2:3:20a:5eff:fe47:9709[500] 2001:0:2:3:260:8ff:fe7f:68b1[500]  udp -P out ipsec esp/transport//use ah/transport//use;
> spdadd 2001:0:2:3:260:8ff:fe7f:68b1[500]  2001:0:2:3:20a:5eff:fe47:9709[500] udp -P in  ipsec esp/transport//use ah/transport//use;
> 
> # Any other traffic between computers A and B must use ESP and AH.
> spdadd 2001:0:2:3:20a:5eff:fe47:9709 2001:0:2:3:260:8ff:fe7f:68b1  any -P out ipsec esp/transport//require ah/transport//require;
> spdadd 2001:0:2:3:260:8ff:fe7f:68b1  2001:0:2:3:20a:5eff:fe47:9709 any -P in  ipsec esp/transport//require ah/transport//require;
> 
> The policy rules on computer B corresponds to the ones above.
> Similar policy rules for IPv4 works like a dream on my network, so why
> does not it work for IPv6?
> 
> With the policy rules above in effect, racoon on both computers uses
> almost infinite time when attempting to negotiate the keying for IPv6.
> I.e., racoon is getting nowhere when it tries to initiate phase 1, and
> racoon on neither computer seems to care of or even receive the
> replies from each other. There are no firewalls between my computers,
> nor does any of my computers run a firewall.
> 
> Contrast the above with these policy rules in effect:
> 
> # Flush the entries.
> spdflush;
> 
> # Traffic between computers A and B may use ESP and AH.
> spdadd 2001:0:2:3:20a:5eff:fe47:9709 2001:0:2:3:260:8ff:fe7f:68b1  any -P out ipsec esp/transport//use ah/transport//use;
> spdadd 2001:0:2:3:260:8ff:fe7f:68b1  2001:0:2:3:20a:5eff:fe47:9709 any -P in  ipsec esp/transport//use ah/transport//use;
> 
> It seems that phase 1 completes when I do not force the use of IPsec.
> 
> Should I specify "require" in my IPv6 policy rules and include policy
> rules that allow IPv6 ISAKMP to pass unencrypted, phase 1 never
> succeeds when the computer has just rebooted.
> 
> Should I boot the computer with "use" in the IPv6 policy rules and
> later change "use" to "require" while racoon is running, phase 1 has
> already completed so all that remains is phase 2. In this case there
> are obviously no need for the special ISAKMP policy rules.
> 
> Once phase 1 is done, phase 2 completes independently on whether I
> specify "use" or "require" in the policy rules. And strangely enough,
> this only happens with IPv6. As I said before, IPv4 with IPsec works
> like a charm, even with "require" and the special ISAKMP policy rules.
> 
> Personally, I can live with "use" instead of "require" in my IPv6
> policy rules, but it is unbearable for environments where this is not
> acceptable.
> 
> Hopefully someone will look into this matter and possibly fix it.
> Please contact me if I have left out any details you need to know.
> 


YAMASHITA Yutaka