Date: Thu, 17 May 2018 19:28:22 +0200 From: Andreas Scherrer <ascherrer@gmail.com> To: freebsd-net@freebsd.org Subject: Re: Site-to-site IPSec VPN using if_ipsec and racoon Message-ID: <CABRZWDKCyrg4QAn8p8xZquV3s0G1JLqoQDAJ9ej6G9LtVVSMLA@mail.gmail.com> In-Reply-To: <9a64e1e8-2258-379e-9ed0-4c8d8bf0aea9@yandex.ru> References: <951ef6f6-95d8-8832-1e7a-59fc90434029@gmail.com> <9a64e1e8-2258-379e-9ed0-4c8d8bf0aea9@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Andrey
Thank you for your reply. I was able to find a configuration that
establishes the IPSec tunnel now!
It was a bit of a trial and error and I have tried/changed several things;
so I am not 100% sure what the minimum set of changes required would have
been, but I think I understand that it comes down to the SPD entries. That
is also the main reason I am writing this, maybe it will help someone at
some point.
When if_ipsec is used, automatic entries in the SPD are made (for 0.0.0.0/0
<-> 0.0.0.0/0 via ipsecX). That works, because everything that ends up on
ipsecX should be encrypted.
But I am not using if_ipsec (or even FreeBSD) on the "remote" side. It is
libreswan running on Linux/Raspbian there. And libreswan does not have (and
also cannot have) an SPD entry for 0.0.0.0/0 <-> 0.0.0.0/0. So the two
ends could never complete phase 1...
I ended up still manually creating *additional* ("more specific" and
matching with what I have in libreswan) SPD entries on FreeBSD using setkey
and now things work.
Thank you!
andreas
On 13 May 2018 at 02:02, Andrey V. Elsukov <bu7cher@yandex.ru> wrote:
> On 13.05.2018 02:37, Andreas Scherrer wrote:
> > My interpretation of [2]'s statement:
> >
> > "If no security association is found, the packet is put on hold and the
> > IKE daemon is asked to negotiate an appropriate one."
> >
> > is that it should somehow be automagic. But in my current configuration,
> > that does not happen. I never see FreeBSD initiate any IKE traffic
> > (500/udp) and 'setkey -D' always reports "No SAD entries.".
>
> Hi,
>
> You need to run racoon in debug mode and then, I think, you will see how
> ACQUIRE happens, and why it doesn't work.
>
> > Can anybody point me in the right direction (be it more documentation or
> > a working config example)? That would be awesome.
>
> Recently there was the discussion about it, and a config that worked for
> one tunnel was published:
> https://lists.freebsd.org/pipermail/freebsd-net/2018-April/050271.html
>
> You can read the entire topic to get additional info.
>
> > Best regards
> > andreas
> >
> > Ps.: I have tried the "old" approach which I know better using 'gif'
> > interfaces. With that I have managed to get racoon negotiate SAs for the
> > same tunnel (i.e. with libreswan on the RPi). Unfortunately I cannot
> > wrap my head around the routing with that approach (no 'gif' on
> > Raspbian). And the documentation also mentions this as a limitation of
> > 'gif' [3]: "you cannot usually use gif to talk with IPsec devices that
> > use IPsec tunnel mode"
>
> You can use gif+IPsec in transport mode from one side, and IPsec device
> with tunnel mode from other side. Technically this is the same. But I
> don't know how hard configure this using IKE.
>
> --
> WBR, Andrey V. Elsukov
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABRZWDKCyrg4QAn8p8xZquV3s0G1JLqoQDAJ9ej6G9LtVVSMLA>