Date: Tue, 22 Jan 2013 11:44:20 +0100 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: freebsd-net@freebsd.org Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question Message-ID: <20130122104420.GA3111@zeninc.net> In-Reply-To: <20130121165355.E2D61F41@hub.freebsd.org> References: <20130121165355.E2D61F41@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ? > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130122104420.GA3111>