Date: Fri, 25 Jan 2013 00:48:04 +0100 (CET) From: Richard Kojedzinszky <krichy@cflinux.hu> To: VANHULLEBUS Yvan <vanhu@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question Message-ID: <alpine.BSF.2.00.1301250047180.84300@pi.nmdps.net> In-Reply-To: <alpine.BSF.2.00.1301221332190.48971@pi.nmdps.net> References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> <alpine.BSF.2.00.1301221332190.48971@pi.nmdps.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Yvan,
I've found a strange line in racoon's output:
Either family (2 - 2), types (4 - 1) of ID from initiator differ or
matching sainfo has no id_i defined for the peer. Not filling iph2->sa_src
and iph2->sa_dst.
This is missing in linux's instance. Could this be a clue for my problem?
Thanks in advance,
Kojedzinszky Richard
On Tue, 22 Jan 2013, Richard Kojedzinszky wrote:
> Dear Yvan,
>
> I've recompiled racoon with NATT, but as you've said, only pure Internet is
> between A and B without NAT, and thus it did not solve my problem.
>
> I've attached racoon's output from
> # racoon -ddd -F
> on the freebsd's side.
>
> I can confirm, that setkey -D and -DP's output were full, so only the two
> entries existed for the SA's and policices.
>
> I've tried a simple road-warrior setup, with transport mode, thus only
> traffic between A and B was protected, but that worked.
> My server's racoon.conf is simple:
> --
> path certificate "/usr/local/etc/racoon/certs";
>
> remote anonymous {
> exchange_mode main,aggressive;
> # nat_traversal off;
>
> certificate_type x509 "A.crt "A.key";
> ca_type x509 "ca.crt";
> my_identifier asn1dn;
> peers_identifier asn1dn;
> proposal_check strict ;
>
> lifetime time 24 hour;
>
> proposal {
> encryption_algorithm aes256;
> hash_algorithm sha1;
> authentication_method rsasig;
> dh_group 2;
> }
>
> generate_policy on ;
> passive on ;
>
> dpd_delay 60;
> }
>
> sainfo anonymous {
> lifetime time 4 hour;
>
> encryption_algorithm aes128 ;
> authentication_algorithm hmac_md5 ;
> compression_algorithm deflate;
> }
>
> log debug ;
> --
>
> And the client's is the same except the generate_policy and passive
> statements.
>
> Thanks in advance,
>
> Kojedzinszky Richard
>
> On Tue, 22 Jan 2013, VANHULLEBUS Yvan wrote:
>
>> Hi.
>>
>>
>> On Mon, Jan 21, 2013 at 05:53:49PM +0100, krichy@cflinux.hu wrote:
>>> Dear users,
>>>
>>> I've a working tunnel setup between two linux hosts.
>>>
>>> One end (A) has a fix address, while the other (B) has a dynamic one.
>>> A is my server, B is my home router. Behind B, I've a private network.
>>> What I've setup is that my private network reaches A through an IPSEC
>>> tunnel.
>> [....]
>>> Now, I've decided to switc to freebsd on server side, and the same
>>> configuration on the server simply does not work. It installs the
>>> policies, and the tunnels, but it seems, that when a reply packet is
>>> leaving the server, it tries to initiate a new tunnel. If I've "passive
>>> on" on my server's remote section, then I've the following error:
>>>
>>> Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B.
>>> Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication.
>>>
>>> If I disable passive mode, then racoon tries to establish another tunnel,
>>> but for some reason it does not succeed also. But I think, as in linux
>>> it should work with passive on.
>>>
>>> FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4.
>>>
>>> racoon on linux is:
>>> # racoon -V
>>> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net)
>>>
>>> Compiled with:
>>> - OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/)
>>> - Dead Peer Detection
>>> - IKE fragmentation
>>> - NAT Traversal
>>> - Monotonic clock
>>>
>>>
>>> racoon on freebsd is:
>>> # racoon -V
>>> @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net)
>>>
>>> Compiled with:
>>> - OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/)
>>> - Dead Peer Detection
>>> - IKE fragmentation
>>> - Hybrid authentication
>>> - Monotonic clock
>>
>> You have NAT-T compiled/enabled on Linux side, but not on FreeBSD side
>> (probably because it is not activated as a kernel option).
>> If you have "something that does NAT" on the wire between A and B, it
>> is probably the origin of your problem.
>>
>> However, as it seems that there is only "Internet" between A and B,
>> I'll suppose that the issue is somewhere else...
>>
>>
>>> Unfortunately I've no idea.
>>>
>>> Before the first packet, on the server:
>>> # setkey -D
>>> No SAD entries.
>>>
>>> After an icmp packet sent from my private network to A:
>>> # setkey -D
>>> A B
>>> esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000)
>>> E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213
>>> A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5
>>> seq=0x00000000 replay=4 flags=0x00000000 state=mature
>>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013
>>> diff: 135(s) hard: 14400(s) soft: 11520(s)
>>> last: hard: 0(s) soft: 0(s)
>>> current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
>>> allocated: 0 hard: 0 soft: 0
>>> sadb_seq=1 pid=93091 refcnt=1
>>> B A
>>> esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000)
>>> E: rijndael-cbc 8bd59c29 9800d10f 8f9d7e84 a720aa9c
>>> A: hmac-md5 188070e2 a3220772 78efcb06 3457db62
>>> seq=0x00000037 replay=4 flags=0x00000000 state=mature
>>> created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013
>>> diff: 135(s) hard: 14400(s) soft: 11520(s)
>>> last: Jan 21 17:04:50 2013 hard: 0(s) soft: 0(s)
>>> current: 5720(bytes) hard: 0(bytes) soft: 0(bytes)
>>> allocated: 55 hard: 0 soft: 0
>>> sadb_seq=0 pid=93091 refcnt=1
>>> # setkey -DP
>>> 10.0.0.0/24[any] A[any] any
>>> in ipsec
>>> esp/tunnel/B-A/require
>>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:03:39 2013
>>> lifetime: 14400(s) validtime: 0(s)
>>> spid=25 seq=1 pid=5232
>>> refcnt=1
>>> A[any] 10.0.0.0/24[any] any
>>> out ipsec
>>> esp/tunnel/A-B/require
>>> created: Jan 21 17:03:39 2013 lastused: Jan 21 17:04:50 2013
>>> lifetime: 14400(s) validtime: 0(s)
>>> spid=26 seq=0 pid=5232
>>> refcnt=1
>>>
>>> Everything seems fine, as well it is in linux, howewer, the attached log
>>> shows that the kernel or racoon does not try to use the new tunnel,
>>> instead it wants another one.
>>
>> Looks good.....
>>
>> Could you run racoon (on server's side) in debug mode (-dd) and send
>> the few lines that talk about trying to negociate a new tunnel ?
>> (Be careful, such racoon's debug contains sensitive informations)
>>
>> What I'd like to have is the profil of the tunnel that kernel asks for
>> negociation.
>>
>> Also, can you confirm that your setkey -DP output is the whole full
>> output ?
> Yes, it was the full.
>>
>>
>>> Is it a bug in freebsd, or a feature in linux? Do somebody have experience
>>> with such a setup?
>>
>> Afaik, none of them, I use such setup and it works....
>> The only difference in my configuration is that I have a network
>> behind both peers, but it should also work in your case.
>>
>>
>> Yvan.
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1301250047180.84300>