From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 23:48:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5585B3F4; Thu, 24 Jan 2013 23:48:15 +0000 (UTC) (envelope-from krichy@cflinux.hu) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B984FE9C; Thu, 24 Jan 2013 23:48:14 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 3202C265; Fri, 25 Jan 2013 00:48:05 +0100 (CET) Date: Fri, 25 Jan 2013 00:48:04 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: VANHULLEBUS Yvan Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question In-Reply-To: Message-ID: References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 23:48:15 -0000 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" >