[freebsd] IPsec VPN and NAT

[Golub Mikhail]

Доброе утро.

Есть две сети с одинаковой адресацией сетей за шлюзами.
Задача - объединить их через ipsec.
Чтобы проверить работу схемы сделал сети отличающимися.

Имеется FreeBSD 10.1
Два интерфейса (em0 - outside, em1 - inside).
Используется pf.

Хочу с одной стороны сделать NAT для адресов локальной сети перед тем, как
завернуть их в туннель.
Для построения ipsec использую или strongswan или ipsec-tools (с одной
стороны stronswan, а с другой - racoon).
С одной стороны сеть 192.168.44.0/24,с другой - 192.168.45.0/24.
Хочу чтобы с другой стороны сеть 192.168.44.0/24 не фигурировала. Т.е. делаю
binat в сеть 192.168.46.0/24
Туннель должен быть между сетями 192.168.46.0/24 (после бината) с одной
стороны и сетью 192.168.45.0/24 с другой стороны.

В OpenBSD пишут, что должно работать.
http://undeadly.org/cgi?action=article&sid=20090127205841

Работает у кого-то описанная (похожая) в статье схема?

P.S. В ядре:
options IPSEC
options IPSEC_NAT_T
device crypto
device enc
device pf
device pflog
device pfsync

net.inet.ip.forwarding=1

ifconfig enc0 up

binat on enc0 from 192.168.44.0/24 to 192.168.45.0/24 -> 192.168.46.0/24


--
Голуб Михаил

[Eugene Grosbein]

On 21.04.2015 14:14, Golub Mikhail wrote:

> Есть две сети с одинаковой адресацией сетей за шлюзами.
> Задача - объединить их через ipsec.
> Чтобы проверить работу схемы сделал сети отличающимися.
>
> Имеется FreeBSD 10.1
> Два интерфейса (em0 - outside, em1 - inside).
> Используется pf.
>
> Хочу с одной стороны сделать NAT для адресов локальной сети перед тем, как

Не взлетит: http://dadv.livejournal.com/202710.html

[Andrey V. Elsukov]

pfil(9) на интерфейсе enc(4) вызывается из кода IPSec, так что эта
заметка не особо подходит. Другое дело что некотрое время в этом коде
было много багов, так или иначе связанных.

--
WBR, Andrey V. Elsukov

[Golub Mikhail]

В pfsence 2.2 (вчера скачанном) работает.
Там тоже FreeBSD 10.1 ...
Тот же strongswan, тот же pf ...

[Alexandr Krivulya]

22.04.2015 09:11, Golub Mikhail пишет:

> В pfsence 2.2 (вчера скачанном) работает.
> Там тоже FreeBSD 10.1 ...
> Тот же strongswan, тот же pf ...

net.inet.ipsec.filtertunnel=1 ?

[Golub Mikhail]

Нет.
Я проверял этот параметр.

В pfsense установлен дефолтный:
net.inet.ipsec.filtertunnel: 0

Скопировал конфиги, пытаюсь повторить ...

[Golub Mikhail]

У pfsense ядро с патчами.

У них есть несколько параметров, которых нет в стандартном ядре:
net.inet.ip.pfil.inbound: pf
net.inet.ip.pfil.outbound: pf
net.inet6.ip6.pfil.inbound: pf
net.inet6.ip6.pfil.outbound: pf

Может еще какие.

[Golub Mikhail]

Добрый день.

Задал вопрос на форуме - был один ответ, что никак подобное не сделать.
Но все же ...
Никто не делал подобное на FreeBSD?

Хочу на FreeBSD 10.1 натировать сеть в сеть средствами pf перед
заворачиванием в ipsec-туннель (например, локалку 192.168.1.0/24 в
172.16.1.0/24)
pfsense такое делает (а там 10.1-RELEASE-p9 FreeBSD).
В pfsense есть два параметра:
net.inet.ip.pfil.inbound: pf
net.inet.ip.pfil.outbound: pf

На 10.1, 9.3, 8.4, 7* - таких oid-ов нет.

> -----Original Message-----
> From: owner-...@uafug.org.ua [mailto:owner-...@uafug.org.ua]
> On Behalf Of Golub Mikhail
> Sent: Wednesday, April 22, 2015 12:51 PM
> To: fre...@uafug.org.ua
> Subject: RE: [freebsd] IPsec VPN and NAT
>

[Eugene Grosbein]

On 23.04.2015 18:27, Golub Mikhail wrote:
> Добрый день.
>
> Задал вопрос на форуме - был один ответ, что никак подобное не сделать.
> Но все же ...
> Никто не делал подобное на FreeBSD?
>
> Хочу на FreeBSD 10.1 натировать сеть в сеть средствами pf перед
> заворачиванием в ipsec-туннель (например, локалку 192.168.1.0/24 в
> 172.16.1.0/24)
> pfsense такое делает (а там 10.1-RELEASE-p9 FreeBSD).
> В pfsense есть два параметра:
> net.inet.ip.pfil.inbound: pf
> net.inet.ip.pfil.outbound: pf
>
> На 10.1, 9.3, 8.4, 7* - таких oid-ов нет.

Для pf - только выпрашивать патчи у pfSence, видимо.
При использовании natd вместо pfnat такое можно сделать штатно, без патчей.
При использовании ipfw nat - помогает патч, ссылку на описание я кидал.

[Anton Sayetsky]

См. тред "natd не натит", который я создавал несколько месяцев назад. Вроде бы такая же проблема. Решил с помощью natd.

23 апреля 2015 г., 14:27 пользователь Golub Mikhail <ua...@gmn.org.ua> написал:

[Andrey V. Elsukov]

On 23.04.2015 14:27, Golub Mikhail wrote:
> Добрый день.
>
> Задал вопрос на форуме - был один ответ, что никак подобное не сделать.
> Но все же ...
> Никто не делал подобное на FreeBSD?
>
> Хочу на FreeBSD 10.1 натировать сеть в сеть средствами pf перед
> заворачиванием в ipsec-туннель (например, локалку 192.168.1.0/24 в
> 172.16.1.0/24)
> pfsense такое делает (а там 10.1-RELEASE-p9 FreeBSD).
> В pfsense есть два параметра:
> net.inet.ip.pfil.inbound: pf
> net.inet.ip.pfil.outbound: pf
>
> На 10.1, 9.3, 8.4, 7* - таких oid-ов нет.

Судя по названию, эти оиды регулируют порядок или необходимость запуска
pfil хуков на input/output. Т.е. к сути дела не имеют.
А есть у вас возможность попробовать head/?

По сути вам нужно включить filtertunnel, настроить filter_mask так,
чтобы исходящий пакет отправлялся в NAT до инкапсуляции, а входящий
после отрезания внешнего заголовка (см. if_enc(4)).

В политике ipsec вам нужно указать туннельный режим с неотначенными
адресами в качестве адресов матчинга src_range/dst_range и endpoint
адресами туннеля. Эти же endpoint адреса туннеля должны быть указаны в
соответствующих SA.

При такой конфигурации secpolicy отправляет ваши неотначенные пакеты на
обработку в ipsec, тот отправляет их в pfil, который должен выполнить
трансляцию, после возвращения из pfil к пакету будет прилеплен новый IP
заголовок с endpoint адресами тунеля из SA. Далее он шифруется и уходит
в сеть. На принимающей стороне пакет благодаря обратной SA дешифруется,
ему отрезается внешний IP заголовок и уже этот оттранслированный пакет
приходит в хост систему.

На вид как-то вот так это должно работать в head/.

[Golub Mikhail]

> > Хочу на FreeBSD 10.1 натировать сеть в сеть средствами pf перед
> > заворачиванием в ipsec-туннель (например, локалку 192.168.1.0/24 в
> > 172.16.1.0/24)
> > pfsense такое делает (а там 10.1-RELEASE-p9 FreeBSD).
> > В pfsense есть два параметра:
> > net.inet.ip.pfil.inbound: pf
> > net.inet.ip.pfil.outbound: pf
> >
> > На 10.1, 9.3, 8.4, 7* - таких oid-ов нет.
>
> Судя по названию, эти оиды регулируют порядок или необходимость
> запуска pfil хуков на input/output. Т.е. к сути дела не имеют.

Экспериментально проверил, что имеют (могу ошибаться).
Когда выполнил команду - пакеты в ipsec-туннель перестали заворачиваться.
sysctl net.inet.ip.pfil.inbound=""

> А есть у вас возможность попробовать head/?

Скачал вчера, пробую.

> По сути вам нужно включить filtertunnel, настроить filter_mask так,
> чтобы исходящий пакет отправлялся в NAT до инкапсуляции, а входящий
> после отрезания внешнего заголовка (см. if_enc(4)).

В pfsense net.inet.ipsec.filtertunnel=0

[Andrey V. Elsukov]

On 24.04.2015 08:09, Golub Mikhail wrote:
>>> В pfsense есть два параметра:
>>> net.inet.ip.pfil.inbound: pf
>>> net.inet.ip.pfil.outbound: pf
>>>
>>> На 10.1, 9.3, 8.4, 7* - таких oid-ов нет.
>>
>> Судя по названию, эти оиды регулируют порядок или необходимость
>> запуска pfil хуков на input/output. Т.е. к сути дела не имеют.
>
> Экспериментально проверил, что имеют (могу ошибаться).
> Когда выполнил команду - пакеты в ipsec-туннель перестали заворачиваться.
> sysctl net.inet.ip.pfil.inbound=""

Могу предположить, что таким образом вы убрали пакетный фильтр с
обработки входящих пакетов.
Пару лет назад andre@ кажется предлагал подобные патчи, где можно было
через sysctl выбирать порядок в котором будут вызываться фильтры. Но
тогда они не нашли сторонников, или реализация была неочень. В pfsense
видимо нашли.

>> А есть у вас возможность попробовать head/?
>
> Скачал вчера, пробую.
>
>> По сути вам нужно включить filtertunnel, настроить filter_mask так,
>> чтобы исходящий пакет отправлялся в NAT до инкапсуляции, а входящий
>> после отрезания внешнего заголовка (см. if_enc(4)).
>
> В pfsense net.inet.ipsec.filtertunnel=0

У них там и реализация AES-GCM есть в ipsec, и strongswan патченный для
этого. Ещё и ipsec можно включать через sysctl. eri@ ещё полгода назад
хотел это всё в базу внедрить. Даже от FF был грант прошлой осенью про
IPSec. Но что-то не задалось у него...

[Golub Mikhail]

Скачал вчера FreeBSD-11.0-CURRENT-amd64-20150421-r281832-disc1.iso
Сегодня установил.
Что касается IPSEC, то в ядре его нет.
Ладно, пересобрал ядро.

Вот это все опции, что добавил в конфиг от GENERIC:

options IPSEC
options IPSEC_NAT_T
device crypto
device enc
device pf
device pflog

В системе правил pf нет (просто pf в ядро включил).

Есть несколько виртуалок - FreeBSD 9.3 (racoon), 10.1 (strongswan), 11.0
(strongswan), pfsense 2.2.2 (strongswan)
У всех по две сетевухи. На вторых сетевых разная адресация и разные
виртуальные свичи.
ipsec-туннели построены меджу этими 4-мя хостами в разных комбинациях.
Везде все хорошо - в плане туннели поднимаются, пакеты в туннелях ходят
между разными хостами.
Кроме FreeBSD 11.0
Здесь туннели поднимаются со всеми хостами.
Но пакеты в туннеле ходят только с pfsense.
strongswan был установлен пакаджем. Поставил из портов - ситуация не
изменилась.

До натирования дело не дошло.

> -----Original Message-----
> From: Andrey V. Elsukov [mailto:bu7...@yandex.ru]
> Sent: Friday, April 24, 2015 8:41 AM
> To: Golub Mikhail; fre...@uafug.org.ua
> Subject: Re: [freebsd] IPsec VPN and NAT
>

[Andrey V. Elsukov]

On 24.04.2015 12:44, Golub Mikhail wrote:
> Скачал вчера FreeBSD-11.0-CURRENT-amd64-20150421-r281832-disc1.iso
> Сегодня установил.
> Что касается IPSEC, то в ядре его нет.
> Ладно, пересобрал ядро.

Ну это во всех версиях так :)

> Вот это все опции, что добавил в конфиг от GENERIC:
> options IPSEC
> options IPSEC_NAT_T
> device crypto
> device enc
> device pf
> device pflog
>
> В системе правил pf нет (просто pf в ядро включил).
>
> Есть несколько виртуалок - FreeBSD 9.3 (racoon), 10.1 (strongswan), 11.0
> (strongswan), pfsense 2.2.2 (strongswan)
> У всех по две сетевухи. На вторых сетевых разная адресация и разные
> виртуальные свичи.
> ipsec-туннели построены меджу этими 4-мя хостами в разных комбинациях.
> Везде все хорошо - в плане туннели поднимаются, пакеты в туннелях ходят
> между разными хостами.
> Кроме FreeBSD 11.0
> Здесь туннели поднимаются со всеми хостами.
> Но пакеты в туннеле ходят только с pfsense.
> strongswan был установлен пакаджем. Поставил из портов - ситуация не
> изменилась.
>
> До натирования дело не дошло.

А как настраиваются туннели?
Вот здесь в test plan у меня есть пара конфигов для тестирования в
ручном режиме: https://reviews.freebsd.org/D2304

[Golub Mikhail]

> -----Original Message-----
> From: Andrey V. Elsukov [mailto:bu7...@yandex.ru]
> Sent: Friday, April 24, 2015 5:48 PM
> To: Golub Mikhail; fre...@uafug.org.ua
> Subject: Re: [freebsd] IPsec VPN and NAT
>

> On 24.04.2015 12:44, Golub Mikhail wrote:
> > Скачал вчера FreeBSD-11.0-CURRENT-amd64-20150421-r281832-disc1.iso
> > Сегодня установил.
> > Что касается IPSEC, то в ядре его нет.
> > Ладно, пересобрал ядро.
>
> Ну это во всех версиях так :)

Надеялся, может добавили :)

> А как настраиваются туннели?

FreeBSD 9.3-RELEASE-p13 (racoon)
ext 10.7.0.43, int 192.168.45.0/24
spdadd 192.168.44.0/24 192.168.45.0/24 any -P in ipsec
esp/tunnel/10.7.0.12-10.7.0.43/require;
spdadd 192.168.45.0/24 192.168.44.0/24 any -P out ipsec
esp/tunnel/10.7.0.43-10.7.0.12/require;

FreeBSD 10.1-RELEASE-p9
ext 10.7.0.12, int 192.168.44.0/24
Здесь используется strongswan
conn 10.7.0.43
ikelifetime=86400s
keylife=3600s

ike=aes256-sha-modp1536,aes256-sha-modp1024,aes256-md5-modp1536,aes256-md5-m
odp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1
024
esp=aes256-sha1,aes256-md5,3des-sha1,3des-md5
compress=yes
type=tunnel
left=10.7.0.12
leftid=10.7.0.12
leftsubnet=192.168.44.0/24
right=10.7.0.43
rightid=10.7.0.43
rightsubnet=192.168.45.0/24
auto=route

Туннель поднимается, пакеты бегают в туннеле.

FreeBSD 11.0-CURRENT
ext 10.7.0.41, int 192.168.48.0/24
strongswan-5.3.0_1
Конфиг туннеля к pfsense (зеркальная копия, взятая с pfsense)
conn 10.7.0.57
fragmentation = yes
keyexchange = ikev1
reauth = yes
forceencaps = no
mobike = no
rekey = yes
installpolicy = yes
type = tunnel
dpdaction = restart
dpddelay = 10s
dpdtimeout = 60s
auto = route
left = 10.7.0.41
right = 10.7.0.57
leftid = 10.7.0.41
ikelifetime = 86400s
lifetime = 3600s
ike = 3des-sha1-modp1024!
esp = 3des-sha1!
leftauth = psk
rightauth = psk
rightid = 10.7.0.57
aggressive = no
rightsubnet = 192.168.47.0/24
leftsubnet = 192.168.48.0/24

На FreeBSD 11.0-CURRENT туннель работает (поднимается и внутри него проходят
пакеты) только с pfsense.
На 10.7.0.12 (даже попробовал такой же конфиг как на pfsense) туннель
поднимается, но внутри тишина.

[Andrey V. Elsukov]

On 27.04.2015 09:14, Golub Mikhail wrote:
>>> Что касается IPSEC, то в ядре его нет.
>>> Ладно, пересобрал ядро.
>>
>> Ну это во всех версиях так :)
>
> Надеялся, может добавили :)

Возможно к выходу 11.0 оно будет в GENERIC.

> На FreeBSD 11.0-CURRENT туннель работает (поднимается и внутри него проходят
> пакеты) только с pfsense.
> На 10.7.0.12 (даже попробовал такой же конфиг как на pfsense) туннель
> поднимается, но внутри тишина.

а device enc есть в ядре? tcpdump на нём говорит о чём-то? Ну и на
всякий случай, gif(4)-ов нет нигде?

[Golub Mikhail]

> Возможно к выходу 11.0 оно будет в GENERIC.

Было бы круто :)

> а device enc есть в ядре?

есть.

> tcpdump на нём говорит о чём-то?

Мертвая тишина.

> Ну и на всякий случай, gif(4)-ов нет нигде?

Нет.

FreeBSD на vmware (на всякий случай сообщаю).

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:50:56:88:0b:92
inet 10.7.0.41 netmask 0xffffff00 broadcast 10.7.0.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:50:56:88:0b:2a
inet 192.168.48.1 netmask 0xffffff00 broadcast 192.168.48.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
pflog0: flags=0<> metric 0 mtu 33160
groups: pflog
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo

options IPSEC
options IPSEC_NAT_T
device crypto
device enc
device pf
device pflog

Я сам понять не могу, почему в туннеле с pfsense пакеты бегают, а на другие
хосты туннели поднимаются, а пакетов нет.
Хотя между этими (другими) хостами (FreeBSD 10.1 и 9.3) все работает без
нареканий.

[Slawa Olhovchenkov]

самая вероятная причина -- в ключах.

[Golub Mikhail]

> самая вероятная причина -- в ключах.

Рядом :)
Сети перепутал ...
192.168.44, 192.168.48 ...

Так что, на 11-ке работает ipsec.
Когда "сгруппировал" конфиг - left* и rigth* - увидел, что сети указал
наоборот :(
Да и в логе запись "no matching CHILD_SA config found" указала, где искать
ошибку.

Вернусь теперь к вопросу NAT-а перед отправкой пакетов в туннель.

[Golub Mikhail]

> Вернусь теперь к вопросу NAT-а перед отправкой пакетов в туннель.

С одной стороны туннеля FreeBSD 10.1, с другой - FreeBSD 11.

Сторона А: 10.1
10.7.0.12, 192.168.44.0/24
Сеть правой стороны изменена на "rightsubnet = 192.168.58.0/24"

Сторона Б: 11
10.7.0.41, 192.168.48.0/24
И здесь делаю NAT:
binat on enc0 from 192.168.48.0/24 to 192.168.44.0/24 -> 192.168.58.0/24

И конфиг strongswan меняю (так же как делает pfsense при натировании своей
сети):
leftsubnet = 192.168.58.0/24|192.168.48.0/24

Если инициировать поднятие туннеля со стороны 10.7.0.12, то поднимается.
И пакеты приходят на 11-ку (это tcpdump на enc0, запущен пинг "ping -S
192.168.44.1 192.168.58.1"):
10:54:02.598841 (authentic,confidential): SPI 0xca32dbb7: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 18402, seq
0, length 64 (ipip-proto-4)
10:54:03.608758 (authentic,confidential): SPI 0xca32dbb7: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 18402, seq
1, length 64 (ipip-proto-4)
10:54:04.638694 (authentic,confidential): SPI 0xca32dbb7: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 18402, seq
2, length 64 (ipip-proto-4)
10:54:05.693931 (authentic,confidential): SPI 0xca32dbb7: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 18402, seq
3, length 64 (ipip-proto-4)

А дальше ситуация аналогичная как было и на 10.1, и на 9.3 - ответов нет,
так как нет преобразования пакетов, пришедших по туннелю.

[Andrey V. Elsukov]

On 28.04.2015 11:04, Golub Mikhail wrote:
> А дальше ситуация аналогичная как было и на 10.1, и на 9.3 - ответов нет,
> так как нет преобразования пакетов, пришедших по туннелю.

А покажите что у вас в это время выводят:
setkey -DP
setkey -D
sysctl net.enc
sysctl net.inet.ipsec.filtertunnel

[Golub Mikhail]

> А покажите что у вас в это время выводят:
> setkey -DP

# setkey -DP
192.168.44.0/24[any] 192.168.58.0/24[any] any
in ipsec
esp/tunnel/10.7.0.12-10.7.0.41/unique:1
created: Apr 28 11:18:06 2015 lastused: Apr 28 11:18:07 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=30 seq=1 pid=1163
refcnt=1
192.168.58.0/24[any] 192.168.44.0/24[any] any
out ipsec
esp/tunnel/10.7.0.41-10.7.0.12/unique:1
created: Apr 28 11:18:06 2015 lastused: Apr 28 11:18:06 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=29 seq=0 pid=1163
refcnt=1


> setkey -D
# setkey -D
10.7.0.41 10.7.0.12
esp mode=tunnel spi=3466152788(0xce994b54) reqid=1(0x00000001)
E: 3des-cbc bf9ec33d 53859abb 2a2087de 546f7227 ee5afb1e 2922bea7
A: hmac-sha1 53c494bf 12d12838 9bd58ab4 4077ca67 d8f71d68
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Apr 28 11:18:06 2015 current: Apr 28 11:18:42 2015
diff: 36(s) hard: 3600(s) soft: 3258(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=1164 refcnt=1
10.7.0.12 10.7.0.41
esp mode=tunnel spi=3231614895(0xc09e87af) reqid=1(0x00000001)
E: 3des-cbc 532e220a 301a3006 96daf523 4e08ea9b 0ebfc8f8 5e0ea3ac
A: hmac-sha1 2e100505 f55bfef6 413a191b d5dae343 563e06e8
seq=0x00000001 replay=4 flags=0x00000000 state=mature
created: Apr 28 11:18:06 2015 current: Apr 28 11:18:42 2015
diff: 36(s) hard: 3600(s) soft: 3260(s)
last: Apr 28 11:18:07 2015 hard: 0(s) soft: 0(s)
current: 84(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=0 pid=1164 refcnt=1


> sysctl net.enc
# sysctl net.enc
net.enc.out.ipsec_bpf_mask: 3
net.enc.out.ipsec_filter_mask: 1
net.enc.in.ipsec_bpf_mask: 1
net.enc.in.ipsec_filter_mask: 1

> sysctl net.inet.ipsec.filtertunnel
# sysctl net.inet.ipsec.filtertunnel
net.inet.ipsec.filtertunnel: 0

[Andrey V. Elsukov]

On 28.04.2015 11:21, Golub Mikhail wrote:
> net.enc.out.ipsec_filter_mask: 1

Здесь нужно чтобы pfil вызывался до того, как IPSec прилепит свой IP
хидер, т.е. значение 1 нас устраивает.

> net.enc.in.ipsec_filter_mask: 1

Чтобы pfil вызывался, когда внешний IP заголовок уже будет отрезан и
трансляция выполнялась с адресами 192.xxxx, нужно установить в 2.

>> sysctl net.inet.ipsec.filtertunnel
> # sysctl net.inet.ipsec.filtertunnel
> net.inet.ipsec.filtertunnel: 0

Чтобы pfil вызывался из кода IPSec это нужно в 1 установить.

[Golub Mikhail]

> > net.enc.in.ipsec_filter_mask: 1
>
> Чтобы pfil вызывался, когда внешний IP заголовок уже будет отрезан и
> трансляция выполнялась с адресами 192.xxxx, нужно установить в 2.

Сделал.
# sysctl net.enc.in.ipsec_filter_mask=2
net.enc.in.ipsec_filter_mask: 1 -> 2

> >> sysctl net.inet.ipsec.filtertunnel
> > # sysctl net.inet.ipsec.filtertunnel
> > net.inet.ipsec.filtertunnel: 0
>
> Чтобы pfil вызывался из кода IPSec это нужно в 1 установить.

# sysctl net.inet.ipsec.filtertunnel=1
net.inet.ipsec.filtertunnel: 0 -> 1


Итого:

net.enc.out.ipsec_bpf_mask: 3
net.enc.out.ipsec_filter_mask: 1
net.enc.in.ipsec_bpf_mask: 1

net.enc.in.ipsec_filter_mask: 2

net.inet.ipsec.filtertunnel: 1

Ситуация не изменилась.
11:38:04.901422 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
0, length 64 (ipip-proto-4)
11:38:05.903056 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
1, length 64 (ipip-proto-4)
11:38:06.913052 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
2, length 64 (ipip-proto-4)
11:38:07.933118 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
3, length 64 (ipip-proto-4)

[Andrey V. Elsukov]

On 28.04.2015 11:39, Golub Mikhail wrote:
> Ситуация не изменилась.
> 11:38:04.901422 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
> 10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
> 0, length 64 (ipip-proto-4)
> 11:38:05.903056 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
> 10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
> 1, length 64 (ipip-proto-4)
> 11:38:06.913052 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
> 10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
> 2, length 64 (ipip-proto-4)
> 11:38:07.933118 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
> 10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 65250, seq
> 3, length 64 (ipip-proto-4)

А можете ещё сделать bpf_mask=3 для входящих пакетов? Для каждого
входящего пакета тогда будет по две записи.

[Golub Mikhail]

> А можете ещё сделать bpf_mask=3 для входящих пакетов? Для каждого
> входящего пакета тогда будет по две записи.

Сделал.
# sysctl net.enc.in.ipsec_bpf_mask=3
net.enc.in.ipsec_bpf_mask: 1 -> 3

Картина не поменялась, в смысле ответов так и нет.

# ipsec status
Routed Connections:
10.7.0.12{1}: ROUTED, TUNNEL, reqid 1
10.7.0.12{1}: 192.168.58.0/24 === 192.168.44.0/24
Security Associations (1 up, 0 connecting):
10.7.0.12[1]: ESTABLISHED 24 minutes ago,
10.7.0.41[10.7.0.41]...10.7.0.12[10.7.0.12]
10.7.0.12{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c2e51929_i
c355fdbf_o
10.7.0.12{2}: 192.168.58.0/24 === 192.168.44.0/24

Дамп:
12:01:27.221212 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 21475, seq
82, length 64 (ipip-proto-4)
12:01:27.221219 (authentic,confidential): SPI 0xc2e51929: IP 192.168.44.1 >
192.168.58.1: ICMP echo request, id 21475, seq 82, length 64
12:01:28.241035 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 21475, seq
83, length 64 (ipip-proto-4)
12:01:28.241039 (authentic,confidential): SPI 0xc2e51929: IP 192.168.44.1 >
192.168.58.1: ICMP echo request, id 21475, seq 83, length 64
12:01:29.251052 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 21475, seq
84, length 64 (ipip-proto-4)
12:01:29.251056 (authentic,confidential): SPI 0xc2e51929: IP 192.168.44.1 >
192.168.58.1: ICMP echo request, id 21475, seq 84, length 64
12:01:30.260935 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 21475, seq
85, length 64 (ipip-proto-4)
12:01:30.260938 (authentic,confidential): SPI 0xc2e51929: IP 192.168.44.1 >
192.168.58.1: ICMP echo request, id 21475, seq 85, length 64
12:01:31.271012 (authentic,confidential): SPI 0xc2e51929: IP 10.7.0.12 >
10.7.0.41: IP 192.168.44.1 > 192.168.58.1: ICMP echo request, id 21475, seq
86, length 64 (ipip-proto-4)
12:01:31.271022 (authentic,confidential): SPI 0xc2e51929: IP 192.168.44.1 >
192.168.58.1: ICMP echo request, id 21475, seq 86, length 64

[Andrey V. Elsukov]

On 28.04.2015 12:03, Golub Mikhail wrote:
>> А можете ещё сделать bpf_mask=3 для входящих пакетов? Для каждого
>> входящего пакета тогда будет по две записи.

Да. Жаль что в BPF пакет отправляется до pfil, не видно отнатился он или
нет... :)
Предлагаю перейти к отладке с помощью dtrace :)

# kldload dtraceall
# cat > ./ipsec.d
#!/usr/sbin/dtrace -s

fbt::ipsec_filter:entry
{
self->mbuf = (struct mbuf **)arg0;
m = *(struct mbuf **)arg0;
ip = (struct ip *)m->m_data;
printf("%s->%s", inet_ntoa(&ip->ip_src.s_addr),
inet_ntoa(&ip->ip_dst.s_addr));
}

fbt::ipsec_filter:return
/arg1 != 0/
{
printf("%d", (int)arg1);
}

fbt::ipsec_filter:return
/arg1 == 0/
{
m = *(struct mbuf **)(self->mbuf);
ip = (struct ip *)m->m_data;
printf("%s->%s", inet_ntoa(&ip->ip_src.s_addr),
inet_ntoa(&ip->ip_dst.s_addr));
}
^D

# chmod +x ipsec.d
# ./ipsec.d

[Golub Mikhail]

> Предлагаю перейти к отладке с помощью dtrace :)

Вот что получается.

# ./ipsec.d
dtrace: script './ipsec.d' matched 3 probes
CPU ID FUNCTION:NAME
0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1
0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1
0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1
0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1
0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1

[Andrey V. Elsukov]

On 28.04.2015 12:37, Golub Mikhail wrote:
>> Предлагаю перейти к отладке с помощью dtrace :)
>
> Вот что получается.
>
> # ./ipsec.d
> dtrace: script './ipsec.d' matched 3 probes
> CPU ID FUNCTION:NAME
> 0 50792 ipsec_filter:entry 10.7.0.12->10.7.0.41
> 0 50793 ipsec_filter:return 10.7.0.12->10.7.0.41
> 0 50792 ipsec_filter:entry 192.168.44.1->192.168.58.1
> 0 50793 ipsec_filter:return 192.168.44.1->192.168.58.1

Трансляции не видно, видимо проблема в PF. Я с ним не работал, не знаю
какие там есть методы отладки...

[Golub Mikhail]

> Трансляции не видно, видимо проблема в PF. Я с ним не работал, не знаю
какие там есть методы отладки...

Жаль :(
Спасибо за помощь.

[Eugene Grosbein]

Есть подозрение, что проблема в PF та же - неправильно определяется
направление прохождения пакета (in->out или out->in).
Я с PF тоже не работал. Можно спросить Глеба, gle...@freebsd.org

[Slawa Olhovchenkov]

а можно забить и попробовать ipnat.
что-то не примоню никаких преимуществ у pf nat. в отличии от ipnat.

[Golub Mikhail]

> а можно забить и попробовать ipnat.
> что-то не примоню никаких преимуществ у pf nat. в отличии от ipnat.

Не будем о преимуществах и недостатках ... :)

С ipnat не имел дела.
Поэтому о нем и не шло речи.

Как понял из беглого просмотра примеров правило должно быть где-то таким?
(если IP в IP):
map enc0 192.168.48.1/32 -> 192.168.58.1/32

P.S. Кстати, как в ipnat сделать binat? :)
Типа как в pf:

[Slawa Olhovchenkov]

On Tue, Apr 28, 2015 at 03:50:38PM +0300, Golub Mikhail wrote:

> > а можно забить и попробовать ipnat.
> > что-то не примоню никаких преимуществ у pf nat. в отличии от ipnat.
>
> Не будем о преимуществах и недостатках ... :)
>
> С ipnat не имел дела.
> Поэтому о нем и не шло речи.
>
> Как понял из беглого просмотра примеров правило должно быть где-то таким?
> (если IP в IP):
> map enc0 192.168.48.1/32 -> 192.168.58.1/32

э, тут в твоем случае лучше внутренний интерфейс.

> P.S. Кстати, как в ipnat сделать binat? :)
> Типа как в pf:
> binat on enc0 from 192.168.48.0/24 to 192.168.44.0/24 -> 192.168.58.0/24

а по русски?

[Golub Mikhail]

> > Как понял из беглого просмотра примеров правило должно быть где- то
таким?
> > (если IP в IP):
> > map enc0 192.168.48.1/32 -> 192.168.58.1/32
>
> э, тут в твоем случае лучше внутренний интерфейс.

Внутренний - em1.
У него IP 192.168.48.1
И на нем же натить в 192.168.58.1?

> > P.S. Кстати, как в ipnat сделать binat? :)
> > Типа как в pf:
> > binat on enc0 from 192.168.48.0/24 to 192.168.44.0/24 -> 192.168.58.0/24
>
> а по русски?

http://www.tw.openbsd.org/faq/pf/ru/nat.html

Двунаправленное отображение (отображение 1:1)
Двунаправленное отображение может быть установлено использованием правила
binat. Правило binat устанавливает один к одному отображение между
внутренним IP адресом и внешним. Это может быть полезно, например, для
предоставления веб сервера во внутренней сети со своим личным внешним IP
адресом. Соединения из Интернета на внешний адрес будут транслироваться на
внутренний адрес а соединения от веб сервера (такие как DNS запрос) будут
преобразовываться во внешний адрес. TCP и UDP порты никогда не изменяются с
binat правилом.

В данном случае адреса с сети 192.168.48.0/24 при сети назначения
192.168.44.0/24 преобразовываются в 192.168.58.0/24 (например, 192.168.48.1
в 192.168.58.1).
И обратно при поступлении пакета с сети 192.168.44.0/24 в сеть назначения
192.168.58.0/24 преобразовывается в 192.168.48.0/24.
Где-то так :)

[Slawa Olhovchenkov]

On Tue, Apr 28, 2015 at 04:19:02PM +0300, Golub Mikhail wrote:

> > > Как понял из беглого просмотра примеров правило должно быть где- то
> таким?
> > > (если IP в IP):
> > > map enc0 192.168.48.1/32 -> 192.168.58.1/32
> >
> > э, тут в твоем случае лучше внутренний интерфейс.
>
> Внутренний - em1.
> У него IP 192.168.48.1
> И на нем же натить в 192.168.58.1?

ну да. вроде должно работать.

> > > P.S. Кстати, как в ipnat сделать binat? :)
> > > Типа как в pf:
> > > binat on enc0 from 192.168.48.0/24 to 192.168.44.0/24 -> 192.168.58.0/24
> >
> > а по русски?
>
> http://www.tw.openbsd.org/faq/pf/ru/nat.html
>
> Двунаправленное отображение (отображение 1:1)
> Двунаправленное отображение может быть установлено использованием правила
> binat. Правило binat устанавливает один к одному отображение между
> внутренним IP адресом и внешним. Это может быть полезно, например, для
> предоставления веб сервера во внутренней сети со своим личным внешним IP
> адресом. Соединения из Интернета на внешний адрес будут транслироваться на
> внутренний адрес а соединения от веб сервера (такие как DNS запрос) будут
> преобразовываться во внешний адрес. TCP и UDP порты никогда не изменяются с
> binat правилом.
>
> В данном случае адреса с сети 192.168.48.0/24 при сети назначения
> 192.168.44.0/24 преобразовываются в 192.168.58.0/24 (например, 192.168.48.1
> в 192.168.58.1).
> И обратно при поступлении пакета с сети 192.168.44.0/24 в сеть назначения
> 192.168.58.0/24 преобразовывается в 192.168.48.0/24.
> Где-то так :)
>

map-block em0 from 192.168.48.0/24 to 192.168.44.0/24 -> 192.168.58.0/24

вроде как. хотя может и bimap

[Golub Mikhail]

Доброго дня всем.

Как и писал в этом обсуждении, в pfsense работает NAT перед ipsec.

И вот нашел ссылку на описание на русском.
https://forum.pfsense.org/index.php?topic=73670.0

https://forum.pfsense.org/index.php?topic=73670.msg402868#msg402868
"pf source - оригинальные и патченные под pfSense. Кстати могу выложить, если кому-то надо. В открытом доступе последние вы вряд ли уже увидите, ибо после того как некто собрал на их основе свой образ pfSense 2.2 и выложил ссылку на него на форум, "Electric Sheep Fencing" решила, что нарушены ее права на имя pfSense и удалила патчи из репозитария. Теперь нужно подписать лицензионное соглашение разработчика, чтобы иметь к ним доступ. Что дальше будет - не понятно, все в процессе."



> -----Original Message-----
> From: owner-...@uafug.org.ua [mailto:owner-...@uafug.org.ua]
> On Behalf Of Golub Mikhail
> Sent: Tuesday, April 21, 2015 10:14 AM
> To: fre...@uafug.org.ua
> Subject: [freebsd] IPsec VPN and NAT
>
> Доброе утро.
>
> Есть две сети с одинаковой адресацией сетей за шлюзами.
> Задача - объединить их через ipsec.
> Чтобы проверить работу схемы сделал сети отличающимися.
>
> Имеется FreeBSD 10.1
> Два интерфейса (em0 - outside, em1 - inside).
> Используется pf.
>
> Хочу с одной стороны сделать NAT для адресов локальной сети перед
> тем, как
> завернуть их в туннель.
> Для построения ipsec использую или strongswan или ipsec-tools (с одной
> стороны stronswan, а с другой - racoon).
> С одной стороны сеть 192.168.44.0/24,с другой - 192.168.45.0/24.
> Хочу чтобы с другой стороны сеть 192.168.44.0/24 не фигурировала. Т.е.
> делаю
> binat в сеть 192.168.46.0/24
> Туннель должен быть между сетями 192.168.46.0/24 (после бината) с
> одной
> стороны и сетью 192.168.45.0/24 с другой стороны.
>
> В OpenBSD пишут, что должно работать.
> http://undeadly.org/cgi?action=article&sid=20090127205841
>
> Работает у кого-то описанная (похожая) в статье схема?
>
> P.S. В ядре:

> options IPSEC
> options IPSEC_NAT_T
> device crypto
> device enc
> device pf
> device pflog

> device pfsync
>
> net.inet.ip.forwarding=1
>
> ifconfig enc0 up
>
> binat on enc0 from 192.168.44.0/24 to 192.168.45.0/24 -> 192.168.46.0/24
>
>
> --
> Голуб Михаил

[Eugene Grosbein]

On 11.08.2015 17:41, Golub Mikhail wrote:
> Доброго дня всем.
>
> Как и писал в этом обсуждении, в pfsense работает NAT перед ipsec.
>
> И вот нашел ссылку на описание на русском.
> https://forum.pfsense.org/index.php?topic=73670.0
>
> https://forum.pfsense.org/index.php?topic=73670.msg402868#msg402868
> "pf source - оригинальные и патченные под pfSense. Кстати могу выложить, если кому-то надо. В открытом доступе последние вы вряд ли уже увидите, ибо после того как некто собрал на их основе свой образ pfSense 2.2 и выложил ссылку на него на форум, "Electric Sheep Fencing" решила, что нарушены ее права на имя pfSense и удалила патчи из репозитария. Теперь нужно подписать лицензионное соглашение разработчика, чтобы иметь к ним доступ. Что дальше будет - не понятно, все в процессе."

Что-то мешает подписать это соглашение и получить для себя патчи?

[Golub Mikhail]

Честно - не пробовал :)

Вопрос еще в другом :)
Почему бы эти патчи не добавить в базу FreeBSD?
Ведь функционал то востребованный.
Так же как и ipsec, для которого надо пересобирать ядро.
Хотя с последним, как писали здесь, есть перспективы получить поддержку ipsec в FreeBSD 11 без пересборки ядра.

> -----Original Message-----
> From: Eugene Grosbein [mailto:egro...@rdtc.ru]
> Sent: Tuesday, August 11, 2015 1:49 PM
> To: Golub Mikhail; fre...@uafug.org.ua

[Eugene Grosbein]

On 11.08.2015 17:57, Golub Mikhail wrote:
> Честно - не пробовал :)
>
> Вопрос еще в другом :)
> Почему бы эти патчи не добавить в базу FreeBSD?
> Ведь функционал то востребованный.
> Так же как и ipsec, для которого надо пересобирать ядро.
> Хотя с последним, как писали здесь, есть перспективы получить поддержку ipsec в FreeBSD 11 без пересборки ядра.

В ядро FreeBSD не могут быть добавлены патчи не под лицензией BSD.

[Anton Sayetsky]

11 августа 2015 г., 14:08 пользователь Eugene Grosbein
<eu...@grosbein.net> написал:

С каких пор BSD license запрещает линковку с кодом под другими лицензиями?

[Anton Sayetsky]

11 августа 2015 г., 14:26 пользователь Eugene Grosbein
<eu...@grosbein.net> написал:

> On 11.08.2015 18:19, Anton Sayetsky wrote:
>
>>> В ядро FreeBSD не могут быть добавлены патчи не под лицензией BSD.
>> С каких пор BSD license запрещает линковку с кодом под другими лицензиями?
>

> Она не запрещает и причина не в лицензии, а в политике проекта.
Ну, ZFS-то кое-как впихнули в svn. (Да, знаю, что только модулем
использовать можно.)

[Eugene Grosbein]

По особому решению Core Team, а вообще эта политика подробно
расписана тут: https://www.freebsd.org/internal/software-license.html

[Anton Sayetsky]

11 августа 2015 г., 14:33 пользователь Eugene Grosbein

<eu...@grosbein.net> написал:
> On 11.08.2015 18:30, Anton Sayetsky wrote:
>> 11 августа 2015 г., 14:26 пользователь Eugene Grosbein
>> <eu...@grosbein.net> написал:
>>> On 11.08.2015 18:19, Anton Sayetsky wrote:
>>>
>>>>> В ядро FreeBSD не могут быть добавлены патчи не под лицензией BSD.
>>>> С каких пор BSD license запрещает линковку с кодом под другими лицензиями?
>>>
>>> Она не запрещает и причина не в лицензии, а в политике проекта.
>> Ну, ZFS-то кое-как впихнули в svn. (Да, знаю, что только модулем
>> использовать можно.)
>
> По особому решению Core Team, а вообще эта политика подробно
> расписана тут: https://www.freebsd.org/internal/software-license.html

Благодарю за линк - раньше как-то не натыкался.

[Eugene Grosbein]

On 11.08.2015 18:35, Anton Sayetsky wrote:

>>>>>> В ядро FreeBSD не могут быть добавлены патчи не под лицензией BSD.
>>>>> С каких пор BSD license запрещает линковку с кодом под другими лицензиями?
>>>>
>>>> Она не запрещает и причина не в лицензии, а в политике проекта.
>>> Ну, ZFS-то кое-как впихнули в svn. (Да, знаю, что только модулем
>>> использовать можно.)
>>
>> По особому решению Core Team, а вообще эта политика подробно
>> расписана тут: https://www.freebsd.org/internal/software-license.html
> Благодарю за линк - раньше как-то не натыкался.

Если интересно - ссылка эта есть в разделе 2.4 в статье
"Contributing to FreeBSD" https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/contrib-how.html

[Slawa Olhovchenkov]

On Tue, Aug 11, 2015 at 01:57:24PM +0300, Golub Mikhail wrote:

> Честно - не пробовал :)
>
> Вопрос еще в другом :)
> Почему бы эти патчи не добавить в базу FreeBSD?
> Ведь функционал то востребованный.
> Так же как и ipsec, для которого надо пересобирать ядро.
> Хотя с последним, как писали здесь, есть перспективы получить поддержку ipsec в FreeBSD 11 без пересборки ядра.

люблю я таких нелюбопытных.
https://svnweb.freebsd.org/base?view=revision&revision=285142