Смена порта это не элемент безопасности.

NM в линуксе, к сожалению, то ещё поделие - вроде бы должен упрощать жизнь пользователю и в стандартных случаях это даже так, но чуть в сторону и привет. Ещё и умудряется ломать логику конфиги прописанные руками для нетплана, нетворкд и т.п.

Нефиг его на серверах использовать.

Ахах
Нет.
И с туннелей хожу, и с локалки, и даже с туннеля через туннель.
Фаервол крутить нужно в правильном направлении

Только сменил порты- лог перестал быть красным от попыток входа.

На серверах его и быть не должно. Я про десктопы писал

А зачем на десктопе сложная маршрутизация?

Ну ВПН же всякие - такой гемор с НМ с ними. Проще 2 текстовых конфига прописать

openvpn и нет проблем)

Просто импортируешь 1 файл и подключаешься.

чтобы через офисный впн не гнать весь трафик. очевидно же.

что есть, тем и приходится пользоваться.

Галочка внизу и нет проблем.

она стоит

насколько я понимаю тут есть еще какой-то механизм, связанный именно с икев2. на этом уровне определеяется шифровать или нет и дальше уже в туннель летит. но я не знаю как такое работает и могу ошибаться

а  в качестве накопителя под dc-dc smd-индуктивность в мелком корпусе?

Так, что посмотреть? Policy ожидаемо создаётся с учётом полученного Configuration Payload с сервера.

src 172.16.0.197/32 dst 172.16.0.0/23
 dir out priority 371839
 tmpl src 172.16.16.16 dst 130.0.0.0
   proto esp spi 0x02c76d14 reqid 1 mode tunnel
src 172.16.0.0/23 dst 172.16.0.197/32
 dir fwd priority 371839
 tmpl src 130.0.0.0 dst 172.16.16.16
   proto esp reqid 1 mode tunnel
src 172.16.0.0/23 dst 172.16.0.197/32
 dir in priority 371839
 tmpl src 130.0.0.0 dst 172.16.16.16
   proto esp reqid 1 mode tunnel

Я в split-include я отдаю префикс 172.16.0.0/23.

Конечно же не каких маршрутов в RIB нет и быть не может, это policy-based IPSec setup.

zanswer@A6IE003:~$ ip route show
default via 172.16.16.254 dev enp2s0 proto dhcp metric 100
130.0.0.0 via 172.16.16.254 dev enp2s0 proto static metric 100
169.254.0.0/16 dev enp2s0 scope link metric 1000
172.16.16.0/24 dev enp2s0 proto kernel scope link src 172.16.16.16 metric 100
172.16.16.254 dev enp2s0 proto static scope link metric 100

Если ваш VPN концентратор отдаёт в Configuration Payload INTERNAL_IP4_SUBNET 0.0.0.0/0 то по очевидным причинам, установка галочки во вкладке IPv4 не поможет, если только он не будет создать классовый маршрут на основе INTERNAL_IP4_ADDRESS.

Нужно просто настраивать на линуксе с использованием xfrm-интерфейсов. Тогда будет привычнее. А так, да, считай, отдельная подсистема маршрутизации на ipsec policy мозг ломает.

route-based IPSec не поддерживается в RouterOS, нужно будет думать над policy со стороны VPN Concentrator