Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 May 2018 16:51:07 +0300
From:      "Andrey V. Elsukov" <bu7cher@yandex.ru>
To:        peter.blok@bsd4all.org, Victor Gamov <vit@otcnet.ru>
Cc:        freebsd-net@freebsd.org
Subject:   Re: multiple if_ipsec
Message-ID:  <d4aedb31-245b-b465-8979-2263bdea0ee3@yandex.ru>
In-Reply-To: <C6EF4FCA-CBA0-4068-A582-E3C99D209D0C@bsd4all.org>
References:  <b859ed18-e511-3640-4662-4242a53d999c@otcnet.ru> <5e36ac3f-39ce-72c5-cd97-dd3c4cf551a7@yandex.ru> <30d1c5f9-56e7-c67b-43e1-e6f0457360a8@otcnet.ru> <c2cb415b-bcde-c714-9412-103e674ce673@yandex.ru> <77c37ff9-8de3-dec0-176a-2b34db136bc5@otcnet.ru> <92930ba6-828d-ecb5-ce37-36794ec80ef7@yandex.ru> <112ea6c0-1927-5f47-24c7-6888295496cf@otcnet.ru> <8d27fbd2-001d-dc46-3621-c44d8dad5522@yandex.ru> <9f94133e-bc7f-7979-72de-e6907f68a254@otcnet.ru> <C6EF4FCA-CBA0-4068-A582-E3C99D209D0C@bsd4all.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HAWhf2R19AREMOilE2Yw68DMUt4XLOWCw
Content-Type: multipart/mixed; boundary="ilGIHn5BgWENOorTeQ5TRZLoFwc6EV9PS";
 protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: peter.blok@bsd4all.org, Victor Gamov <vit@otcnet.ru>
Cc: freebsd-net@freebsd.org
Message-ID: <d4aedb31-245b-b465-8979-2263bdea0ee3@yandex.ru>
Subject: Re: multiple if_ipsec
References: <b859ed18-e511-3640-4662-4242a53d999c@otcnet.ru>
 <5e36ac3f-39ce-72c5-cd97-dd3c4cf551a7@yandex.ru>
 <30d1c5f9-56e7-c67b-43e1-e6f0457360a8@otcnet.ru>
 <c2cb415b-bcde-c714-9412-103e674ce673@yandex.ru>
 <77c37ff9-8de3-dec0-176a-2b34db136bc5@otcnet.ru>
 <92930ba6-828d-ecb5-ce37-36794ec80ef7@yandex.ru>
 <112ea6c0-1927-5f47-24c7-6888295496cf@otcnet.ru>
 <8d27fbd2-001d-dc46-3621-c44d8dad5522@yandex.ru>
 <9f94133e-bc7f-7979-72de-e6907f68a254@otcnet.ru>
 <C6EF4FCA-CBA0-4068-A582-E3C99D209D0C@bsd4all.org>
In-Reply-To: <C6EF4FCA-CBA0-4068-A582-E3C99D209D0C@bsd4all.org>

--ilGIHn5BgWENOorTeQ5TRZLoFwc6EV9PS
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 08.05.2018 14:03, peter.blok@bsd4all.org wrote:
> Hi Victor,
>=20
> I=E2=80=99m struggling wit the same issue. My sainfo doesn=E2=80=99t ma=
tch unless I
> use anonymous.
>=20
> Hi Andrey,
>=20
> What I don=E2=80=99t understand is why a =E2=80=9Ccatchall=E2=80=9D pol=
icy is added instead
> of the policy that matches the inner tunnel.

This is because the how IPsec works in BSD network stack.

In simple words - outbound traffic is matched by security policy,
inbound is matched by security association.

When a packet is going to be send from a host, the kernel checks
security policies for match. If it is matched, a packet goes into IPsec
processing. Then IPsec code using given security policy does lookup for
matched security association. And some IPsec transform happens.

When a host receives a packet, it handled by network stack first. And
if it has corresponding IPsec inner protocol (ESP, AH), it will be
handled by IPsec code. A packet has embedded SPI, it is used for
security association lookup. If corresponding SA is found, the IPsec
code will apply revers IPsec transform to the packet. Then the kernel
checks, that there is some security policy for that packet.

Now how if_ipsec(4) works. Security policies associated with interface
have configured requirements for tunnel mode with configured addresses.
Interfaces are designed for route based VPN, and when a packet is going
to be send through if_ipsec interface, its "output" routine uses
security policy associated with interface and with configured "reqid".

If there are no SAs configured with given reqid, the IPsec code will
send ACQUIRE message to IKE and it should install SAs, that will be used
for IPsec transforms.

When a host receives a packet, it handled by network stack, then by
IPsec code and when reverse transform is finished, IPsec code checks, if
packet was matched by tunnel mode SA it will be checked by if_ipsec
input routine. If addresses and reqid from SA matched to if_ipsec
configuration, it will be taken by if_ipsec interface.


> What is supposed to happen here? Is the IKE daemon supposed to update
> the policy once started.

In my understanding IKE is only supposed to install SAs for if_ipsec.
It can't change these policies, because they are immutable.

I think for proper support of several if_ipsec interfaces racoon needs
some patches. But I have not spare time to do this job.
I recommend to use strongswan, it has active developers that are
responsive and may give some help at least.

There was the link with example, but it also uses only one interface:
https://genneko.github.io/playing-with-bsd/networking/freebsd-vti-ipsec

--=20
WBR, Andrey V. Elsukov


--ilGIHn5BgWENOorTeQ5TRZLoFwc6EV9PS--

--HAWhf2R19AREMOilE2Yw68DMUt4XLOWCw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlrxq0sACgkQAcXqBBDI
oXrD1Qf7BJqf9JYJZ5oou+62z1+K0kgbCnShA6lk/Wyzt700DRybjNuKgPcK9LL9
27nOtHwQUefRFWLBquS5AQa1QQzLr2Wtg+pigcKQJfdjdAlJOcc3/JVmCzwCxvoY
D5IRJUZkAr1+e9ActAmGGwFRwh7viwwCgBvw/WLt7JZTyBNjlZw2esR41DIAXe/O
ZH5fSXXpl51aMQVtUyP4Q9NqqSQMpT/7wMggwQ2CniUzn04uvHcVmmFIEXgLoi3p
TbnfoxlmbsKUVDlxz4C4DIcynoyiImwo3xON/Rj5KrdQ4Jil8zTzciN0BrchzZiC
CHk7z0EghJ9emybqIxytuMpoWxKdcg==
=YBBO
-----END PGP SIGNATURE-----

--HAWhf2R19AREMOilE2Yw68DMUt4XLOWCw--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4aedb31-245b-b465-8979-2263bdea0ee3>