Прежде я использовать strongSwan с auto=add правилами: при запуске они
автоматически добавлялись, но security policy явно не задавались. Точнее
было так: на шлюзе, концентраторе-IPsec он сам ничего не предпринимал, а
только ждал входящие соединения. Клиенты же сами их инициировали. Это
опасно тем, что никто явно нигде не говорит что трафик внутри IPv6-IPsec
сети (отдельная выделенная /64 сеть) должна быть зашифрована. Если я
везде остановлю strongSwan-ы, то всё будет работать и я даже не замечу
что шифрования (+аутентификации) то и нет.
Выставление auto=route должно создавать security policy явно говорящие
что такой-то трафик обязан быть обезопасен ESP. Но соединения у меня не
срабатывали почему-то. Сегодня разобрался почему. Использовать
туннельный режим IPsec в FreeBSD проблематично. Я до конца всё так и не
понял, но самое нормальное это делать явные туннели: например
gif-интерфейсы и их обезопашивать в транспортном режиме. Если я скажу
что между fcXX и fcYY адресами должен быть транспортный ESP, то всё по
идее должно работать, но нет. Как оказалось, потому-что правило
требующее безопасности IP-пакетов между fc/8 адресами препятствует
ICMPv6 NDP сообщениям. Я мог бы руками жёстко прописать MAC-адреса IPv6
fc/8 хостов, чтобы NDP не требовался, но геморройно. В итоге пришёл к
тому что описано в wiki strongSwan-а: явно разрешить хождению NDP
пакетов.
* лучше использовать родные туннельные протоколы типа gif, создающие
отдельный сетевой интерфейс. Лично мне это легче понимать и управлять
* про туннельный режим проще забыть, так как туннель всё-равно будет
внутри gif-а. Только транспортный. Им же можно и чисто host-to-host
безопасность обеспечить
* всегда делать auto=route, так как оно явно прописывает security policy
(раз мы пишем туда правило, то значит явно хотим только ESP-трафик?)