Date: Fri, 25 Jan 2013 14:13:45 +0100 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: Richard Kojedzinszky <krichy@cflinux.hu> Cc: freebsd-net@freebsd.org Subject: Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question Message-ID: <20130125131344.GA3356@zeninc.net> In-Reply-To: <alpine.BSF.2.00.1301250047180.84300@pi.nmdps.net> References: <20130121165355.E2D61F41@hub.freebsd.org> <20130122104420.GA3111@zeninc.net> <alpine.BSF.2.00.1301221332190.48971@pi.nmdps.net> <alpine.BSF.2.00.1301250047180.84300@pi.nmdps.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 25, 2013 at 12:48:04AM +0100, Richard Kojedzinszky wrote:
> 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?
It may be related...
Looks like one of the peers considers A as a single IP
(IPSECDOI_ID_IPV4_ADDR == 1), where the other considers it as the
network "A/32" (IPSECDOI_ID_IPV4_ADDR_SUBNET == 4).
The most strange thing is that the same setup works with two Linux, so
it may be related to something in kernel side, sent to racoon via
PFKey....
However, that should not change anything when IPsec stack searches for
an SPD then an SA: A will always be matched there, either as an IP or
as a /32 subnet...
I'll have a look ASAP at the debug you sent in your other mail, hope
there will be interesting informations there....
Yvan.
> 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?20130125131344.GA3356>