[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
- To: racoon@kame.net
- Subject: (racoon 937) Re: IPv6 with IPsec on FreeBSD 4.10-R with racoon-20040408a
- From: YAMASHITA Yutaka <yutapon@tera.ics.keio.ac.jp>
- Date: Wed, 04 May 2005 22:03:22 +0900
- Delivered-to: racoon-archive@kame.net
- Delivered-to: racoon-outgo@kame.net
- Delivered-to: racoon@kame.net
- In-reply-to: <20050224124434.K21905@ramstind.gtf.ol.no>
- Organization: Teraoka Lab., Keio University
- References: <20050224124434.K21905@ramstind.gtf.ol.no>
- Reply-to: racoon@kame.net
- Sender: owner-racoon@kame.net
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