Isakmp sa dying mikrotik что это

l2tp+ipsec на Mikrotik

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

Посмотрите, пожалуйста, что не так то может быть… почему в какой то момент обмен прекращается и тунель падает.

20:50:30 l2tp,ppp,info l2tp-out1: initializing. 20:50:30 l2tp,ppp,info l2tp-out1: connecting. 20:50:34 l2tp,debug tunnel 23 entering state: wait-ctl-reply 20:50:34 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:34 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:34 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:34 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:34 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:34 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:34 l2tp,debug,packet Firmware-Revision=0x1 20:50:34 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:34 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:34 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:34 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:34 ipsec,info initiate new phase 1 (Identity Protection): x.x.x.x[500]y.y.y.y[500] 20:50:35 ipsec,info ISAKMP-SA established x.x.x.x[500]-y.y.y.y[500] spi:6b3ca18216094489:bb61fc83b8ced6b1 20:50:35 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:35 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:35 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:35 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:35 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:35 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:35 l2tp,debug,packet Firmware-Revision=0x1 20:50:35 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:35 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:35 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:35 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:36 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:36 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:36 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:36 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:36 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:36 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:36 l2tp,debug,packet Firmware-Revision=0x1 20:50:36 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:36 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:36 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:36 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:38 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:38 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:38 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:38 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:38 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:38 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:38 l2tp,debug,packet Firmware-Revision=0x1 20:50:38 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:38 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:38 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:38 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:42 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:42 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:42 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:42 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:42 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:42 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:42 l2tp,debug,packet Firmware-Revision=0x1 20:50:42 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:42 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:42 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:42 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:50 l2tp,debug,packet sent control message to y.y.y.y:1701 from x.x.x.x:1701 20:50:50 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0 20:50:50 l2tp,debug,packet (M) Message-Type=SCCRQ 20:50:50 l2tp,debug,packet (M) Protocol-Version=0x01:00 20:50:50 l2tp,debug,packet (M) Framing-Capabilities=0x1 20:50:50 l2tp,debug,packet (M) Bearer-Capabilities=0x0 20:50:50 l2tp,debug,packet Firmware-Revision=0x1 20:50:50 l2tp,debug,packet (M) Host-Name="MikroTik(mini)" 20:50:50 l2tp,debug,packet Vendor-Name="MikroTik" 20:50:50 l2tp,debug,packet (M) Assigned-Tunnel-ID=23 20:50:50 l2tp,debug,packet (M) Receive-Window-Size=4 20:50:58 l2tp,debug tunnel 23 received no replies, disconnecting 20:50:58 l2tp,debug tunnel 23 entering state: dead 20:50:58 l2tp,debug session 1 entering state: dead 20:50:58 l2tp,ppp,debug l2tp-out1: CCP close 20:50:58 l2tp,ppp,debug l2tp-out1: BCP close 20:50:58 l2tp,ppp,debug l2tp-out1: IPCP close 20:50:58 l2tp,ppp,debug l2tp-out1: IPV6CP close 20:50:58 l2tp,ppp,debug l2tp-out1: MPLSCP close 20:50:58 l2tp,ppp,info l2tp-out1: terminating. - session closed 20:50:58 l2tp,ppp,debug l2tp-out1: LCP lowerdown 20:50:58 l2tp,ppp,debug l2tp-out1: LCP down event in initial state 20:50:58 l2tp,ppp,info l2tp-out1: disconnected 

провайдеры местечковые, названия нет смысла озвучивать

Isakmp sa dying mikrotik что это

Wed Aug 28, 2019 3:43 pm

I’m really struggling with this. I connect with no problem and then after some time, it starts to «dying» out and disconnect.

What can I do to keep the connection going? or did I miss something?

13:09:12 ipsec,info ISAKMP-SA dying 10x.xx.xx.xx[4500]-100.xx.xx.xx[4219
3b7:xxxxxxxxxc5ff0c
13:21:12 ipsec,info ISAKMP-SA deleted 10x.xx.xx.xx[4500]-100.xx.xx.xx[42
743b7:xxxxxxxxxc5ff0c rekey:1

Thank you for the help!

Forum Veteran
Posts: 906 Joined: Thu Dec 11, 2014 8:53 am

Re: L2TP —> Dying!

Wed Aug 28, 2019 4:04 pm

Isn’t there anything between the dying and deleted messages? If that is an L2TP client, then it should initiate a new ISAKMP-SA when the old one is dying. If it is L2TP server then it should receive a new ISAKMP-SA request from the client. Do you actually experience any issues with the tunnel not working after these messages or are just wondering about them?

Frequent Visitor
Topic Author
Posts: 62 Joined: Tue Apr 29, 2014 12:58 pm

Re: L2TP —> Dying!

Wed Aug 28, 2019 5:48 pm

I don’t understand why! Here is the log

14:48:01 ipsec,info purging ISAKMP-SA 1xx.xx.xx.xx[4500]1xx.xx.xx.xx[11659] spi=59bd8xxc0a02160c:2181ecxxxx57. 14:48:01 ipsec,info ISAKMP-SA deleted 10x.xx.xx.xx[4500]-1xx.xx.xx.xx[11659] spi:59bd8xxc0a02160c:2181ec3xxxxc57 r ekey:1 15:34:03 ipsec,info ISAKMP-SA dying 10x.xx.xx.xx[500]-41.xx.xx.xxx[500] spi:26273c7cb26a2c4b:dxxxxx73c0253 15:46:03 ipsec,info ISAKMP-SA deleted 10x.xx.xx.xx[500]-41.xx.xx.xx[500] spi:26273c7cb26a2c4b:dxxxxx73c0253 rekey:1 15:46:28 l2tp,ppp,info : terminating. - hungup 15:46:28 l2tp,ppp,info,account skynet logged out, 3624 497254 xxxxxxxxx 15:46:28 l2tp,ppp,info : disconnected 16:49:57 ipsec,info respond new phase 1 (Identity Protection): 1xx.xx.xx.xx[500]xx.xx.xxx.xx[500] 16:49:58 ipsec,info ISAKMP-SA established 1xx.xx.xx.xx[500]-4xx.xx.xx.xx[500] spi:eaxxxxxxx4:0aa11562e395c5fe 16:49:59 l2tp,info first L2TP UDP packet received from 4xx.xx.xx.xx 16:49:59 interface,info detect UNKNOWN 16:49:59 l2tp,ppp,info,account skynet logged in, 10.xx.xx.12 16:49:59 l2tp,ppp,info : authenticated 16:49:59 l2tp,ppp,info : connected 16:50:05 interface,info detect WAN 

Что нужно настроить что бы проходит трафик из ipsec за mikrotik?

Настраиваю ipsec Mikritik-DFL260e.
Сетка за DFL видна со стороны сетки за микротом, а вот сетка за микротом не видна (кроме самого микрота).
Я понимаю что дело где то в маршутизации на микроте «зарыто», однако не доходит где именно.
Товарищи спецы, подскажите пожалуйста.

• Вопрос задан более трёх лет назад
• 1677 просмотров

22 комментария

Простой 22 комментария

Ну вы бы как-то побольше информации дали, а то у вас сейчас получается — «Чиню volskwagen, топливо заливаю все нормально, но не заводится»

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский, я просто не знаю что уточнить.
Фаервол пуст (очистил для чистоты эксперимента)
НАТ:
1)accept srcnat src.add(сетка микрота) dst.add(сетка дфл-а)
2) маскарад для внутренней сети для доступа в нэт

192.168.7.0 — сетка за микротом
192.168.0.0 — сетка за дфл-ом

Правило 192.168.0.0/24 ether1-wan можно убрать, оно все равно не работает (приватные сети не должны маршрутизироваться через Интернет), маршуртизаюцию у вас выполняют ipsec policy (в таблице Route List, они как маршрут не отображаются и в interfaces не появляются тоже), вот их бы показать

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский,

Со стороны микротика у вас все хорошо, искать проблему нужно со стороны Dlink, возможно он натирует пакеты идущие в сеть микротика и они не попадают под политики ipsec

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский,
Это вся маршрутизация на д-линке.
И ещё, если бы проблемы были в д-ликовских пакетах, я так понимаю пакеты бы не проходили и на внутренний ip микрота из летки длинка. Или я ошибаюсь?

С dlink’ом к сожалению не подскажу, никогда его не видел и не щупал
Сейчас, в целях эксперимента, в симуляторе накидал вашу сетку, но между двумя микротами
Вот с таким конфигом все работает на ура с обеих сторон

/interface ethernet set [ find default-name=ether2 ] disable-running-check=no name=LAN set [ find default-name=ether3 ] disable-running-check=no name=MGMT set [ find default-name=ether1 ] disable-running-check=no name=WAN /ip ipsec peer add address=100.64.1.2/32 local-address=100.64.0.2 name=peer1 /ip address add address=100.64.0.2/30 interface=WAN network=100.64.0.0 add address=192.168.7.1/24 interface=LAN network=192.168.7.0 /ip firewall nat add action=accept chain=srcnat ipsec-policy=out,ipsec add action=masquerade chain=srcnat log=yes out-interface=WAN /ip ipsec identity add peer=peer1 secret=%123456789% /ip ipsec policy add dst-address=192.168.0.0/24 sa-dst-address=100.64.1.2 sa-src-address=100.64.0.2 src-address=192.168.7.0/24 tunnel=yes /ip route add distance=1 gateway=100.64.0.1

Можете попробовать использовать GRE over IPSEC, тогда появится интерфейс который можно нормально использовать в маршрутизации и не будет плясок с ipsec policy

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский, к сожалению не знаю как gre на длинке делать.
А не может быть проблема что у меня ip 7.1 привязан к бриджу в котором все локальные порты? Хотя я думаю вряд ли. Но не знаю уже в какую сторону копать.

Иоанн @ioangrozniy Автор вопроса
Виктор Бельский, Стесняюсь спросить local-address=100.64.0.2почему он локальный?
Бридж не влияет на это.
А скиньте сюда вывод команд

ip ipsec export
ip firewall export
ip route export
ip ipsec installed-sa print

100.64.0.2 — это заменитель реальных wan адресов, они рекомендованы к использованию провайдерами и в примерах конфигураций. У вас он 195.239.xxx.xxx
Он локальный т. к. это wan адрес выданный провайдером нашему роутеру и с него будет идти коннект к удаленному пиру

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский,
1)
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc \
lifetime=1h pfs-group=none
/ip ipsec peer
add address=77.@.@.@/32 dh-group=modp1024 \
enc-algorithm=aes-128 local-address=195.@.@.@ \
mode-config=request-only secret=@@@@@
/ip ipsec policy
add dst-address=192.168.0.0/24 sa-dst-address=\
77.@.@.@ sa-src-address=195.@.@.@ \
src-address=192.168.7.0/24 tunnel=yes

2)
/ip firewall nat
add action=accept chain=srcnat comment NAT avoid
add action=masquerade chain=srcnat log=yes out-i
ether1-wan src-address=192.168.7.0/24
/ip firewall service-port
set sip disabled=yes
3)
/ip route
add check-gateway=ping distance=1 gateway=195.@.@@
add distance=1 dst-address=192.168.0.0/24 gateway=ether1-wan
4)
Flags: H — hw-aead, A — AH, E — ESP
0 HE spi=0x1E084EF src-address=77.@.@.@ dst-address=195.@.@
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
enc-key-size=128
auth-key=»@@@@@@@@@@@@@»
enc-key=»@@@@@@@@@@@@@@@»
addtime=mar/26/2019 16:07:42 expires-in=54m19s add-lifetime=4
current-bytes=78156 current-packets=1175 replay=128

1 HE spi=0x7D391470 src-address=195.@.@.@ dst-address=77.247.
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
enc-key-size=128
auth-key=»@@@@@@@@@@@@@@@@@»
enc-key=»@@@@@@@@@@@@@@@@@@@»
addtime=mar/26/2019 16:07:42 expires-in=54m19s add-lifetime=4
current-bytes=846636 current-packets=1076 replay=128

Ну со стороны микротика все хорошо и проблем тут быть не должно. Для красоты, удалите все-таки add distance=1 dst-address=192.168.0.0/24 gateway=ether1-wan, оно не нужно тут и глаз режет =)

Проверяйте настройки на длинке, смотрите не ошиблись ли где в адресации сети за микротиком, правильная ли маска

Иоанн @ioangrozniy Автор вопроса

Мне одно не понятно, почему я по тоннелю подключаюсь к микроту?
Я так понимаю если пакеты были бы кривые они были бы кривые для всех?
А при пинге такая фигня:

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский, а вот что пишет длинк при пинге
2019-03-26
13:33:30 Info CONN
600002 allow_all ICMP lan
fwVaz2Test-ipsec 192.168.0.100
192.168.7.240
conn_close
close
conn=close connsrcid=1 conndestid=1 origsent=240 termsent=0 conntime=24
2019-03-26
13:33:07 Info CONN
600001 allow_all ICMP lan
fwVaz2Test-ipsec 192.168.0.100
192.168.7.240
conn_open
conn=open connsrcid=1 conndestid=1
2019-03-26
13:32:58 Info CONN
600002 allow_all ICMP lan
fwVaz2Test-ipsec 192.168.0.100
192.168.7.1
conn_close
close
conn=close connsrcid=1 conndestid=1 origsent=240 termsent=240 conntime=12
2019-03-26
13:32:47 Info CONN
600001 allow_all ICMP lan
fwVaz2Test-ipsec 192.168.0.100
192.168.7.1
conn_open
conn=open connsrcid=1 conndestid=1
Всё одинаково. Только с 7.1 получает ответку, а с 7.240 нет. 240 — существует 100%, 1- адрес бриджа

Ну на скрине видно, что пакеты к 7.240 нормально доходят до микротика и походу следуют далее (обведенные цифры это скорость и кол-во переданной информации)
С самого микротика 7.240 пингуется?

Иоанн @ioangrozniy Автор вопроса

С самого микротика 7.240 пингуется?

Да
0 192.168.7.240 56 128 0ms
ioangrozniy, ну попробуйте добавить в nat, в целях эксперимента

ip firewall nat add action=masquerade chain=srcnat dst-address=192.168.7.240

и проверить

Иоанн @ioangrozniy Автор вопроса
Виктор Бельский, ха, а пошло
поменял на 192.168.7.0/24 пингует всю сетку

Иоанн @ioangrozniy Автор вопроса

Я только не понял почему приходится ставить маску, что бы пакеты прошли за внутренний интерфейс микрота?
Я так понимаю это костыль. А вот в чём засада так и не понятно?

Сморите в firewall клиентов или в их таблицу маршрутизации. Последнее правило подменяет ip из сети 192.168.0.0/24 на адрес микротика — 192.168.7.1 и клиенты его пропускают, а вот из сети 192.168.0.0/24 не горят желанием

Иоанн @ioangrozniy Автор вопроса

Виктор Бельский, спасибо огромное, так долго мучался, а не дошло, что дело в брендмауэре виндовом. Спасибо за подсказку.
Может вы напишите это сообщение в ответах, а я поставлю его как решение? Тут я не могу отметить решением.

Пожалуйста ) Сейчас напишу
Решения вопроса 1
Во всем виновато правило firewall на клиентах, блокирующее подключение из второй сети.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ответы на вопрос 1

Внимание! Изменился адрес почты!

Если вопрос касается «чистого» IPSec, то:
— в нем нет маршрутизации, как таковой. Вся информация заложена в SAD и SPD. SPD — это закладка Policies в окне IPSec, SAD — закладка Installed SAs, она формируется динамически.
Что здесь нужно помнить:
IPSec проходит файрволл два раза. Для четкого понимания, как это все фурычет — всегда рекомендую вот эту картинку.
Разберем на пример моего домашнего роутера (RB450G), где 1.1.1.1 — мой внешний IP, 2.2.2.2 — внешний IP удаленной сети. Моя подсетка — 10.54.2.0/24, удаленная — 10.54.1.0/24
Самое первое — это настройка политик (policy). Именно политика решает — нужно данный пакет шифровать или нет?

/ip ipsec proposal add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1 /ip ipsec policy add comment="To Cat's Home main VPN" dst-address=10.54.1.0/24 proposal=proposal1 sa-dst-address=\ 2.2.2.2 sa-src-address=1.1.1.1 src-address=10.54.2.0/24 tunnel=yes

Что сделали:
Добавили proposal1, в котором в качестве алгоритма шифрования выбран ASES256 со счетчиком Галуа . Поскольку он самоаутентифицирующийся, отдельного алгоритма аутентификации задавать не надо. Замена ключей шифрования через каждый час.
Задали политику, согласно которой все пакеты в сеть 10.,54.1.0/24 от 10.54.2.0/24 будут превращены в пакеты протокола ESP от IP 1.1.1.1 до IP 2.2.2.2. Собственно это и есть наша «таблица маршрутизации».

/ip ipsec peer add address=2.2.2.2/32 auth-method=rsa-signature certificate=\ "RB2011 cert (SHA256) with key" comment="To Cat's Home main VPN" dpd-interval=\ disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h nat-traversal=no \ proposal-check=strict remote-certificate="RB450G cert (SHA256)"

Что сделали:
Добавили пира — удаленный сервер. Аутентификация по сертификатам, шифрование AES256, повторный обмен ключами через 2 ч.
Теперь нужно настроить файрволл. Потому что как нарисовано на картинке, пакеты IPSec проходят его два раза.
Предположим я на компе с адресом 10.54.2.1 набираю команду «ping 10.54.1.1».
Пакет проходит таблицы mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если у Вас строгая фильтрация и нет правила, разрешающего трафик от 10.54.2.0/24 на 10.54.1.0/24, он и помрет), mangle postrouting, nat postrouting и уже готов отправиться на default gateway, но в этот момент ведро проверяет его по SPD — а не надо ли его зашифровать и переотправить? Ага, пакет подпадает под политику, значит мы его шифруем и преобразовываем. И пакет icmp от 10.54.2.1 на 10.54.1.1 шифруется и упаковывается в пакет esp от 1.1.1.1 на 2.2.2.2!
Вот здесь надо не забыть подстраховаться от NAT. Дело в том, что когда пакет проходил nat postrouting, общее правило

/ip firewall nat add action=src-nat chain=srcnat out-interface=ether6 to-addresses=1.1.1.1

заменило IP источника, чтобы «обратный адрес» был уникальным и теперь пакет не подходит под политику. А не подходит под политику — не будет зашифрован, а пойдет по общим правилам маршрутизации. А default gateway роутера повертит пакет, повертит — да и скажет «ты кто такой? Давай, до свидания».
Чтобы избежать этого, нужно указать не трогать пакеты, к которым применима политика IPSec — пусть проходят за NAT неизменными, все равно их шифровать:

add chain=srcnat comment="Does not touch IPSec ESP packets to avoid break packets checksum" \ ipsec-policy=out,ipsec log-prefix="NAT avoid" out-interface=ether6

Пошифрованный пакет ведро снова ренижектит в сетевой стек, он снова — уже в своем новом качестве — проходит mangle output, nat output, filter output (и вот тут, если нет разрешения на трафик в сторону 2.2.2.2 или на протокол esp, он и помрет), mangle postrouting, nat postrouting — и отправляется в тырнет на удаленную точку.

Предоплагаем, что с другой стороны роутер настроен таким же образом, то есть у него есть и своя SPD и свой список пиров. Что произойдет, когда пакет будет получен:
пакет пройдет mangle prerouting, nat prerouting, mangle input, filter input (и , если трафик от 1.1.1.1 или протокол esp не разрешен, то тут и помрет). и уже готов к передаче на более верхние уровни OSI, но тут ведро проверяет — а не нужно ли его расшифровать? (и вот тут, если контрольная сумма не сходится — он и помрет). Если пакет подпадает под политику — он будет расшифрован и превратится из esp-пакета от 1.1.1.1 к 2.2.2.2 в icmp пакет от 10.54.1.1 к 10.54.2.1 — и будет заново помещен в сетевой стек. И заново пойдет mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если не разрешен трафик от 10.54.2.0/24 к 10.54.1.0/24 он и помрет), mangle postrouting, nat postrouting — и наконец-то попадет на выходной интерфейс туда, где у нас подключен 10.54.2.1.
Таблица маршрутизации (та, что в ведре) — не использовалась, весь трафик для роутеров выглядит локальным 🙂

IPsec через NAT

До этого ранее выкладывал материал CISCO IPsec, поучилось длинно и нудно. �� При этом не всё удалось подробно разобрать, хотя на самом деле много интересных практических моментов было обозначено.

Одним из скомканных кусков стала работа IPsec через NAT. Решил вынести данный материал в отдельную запись.

Кроме этого продолжаю изучать интересный отечественный продукт S-Terra Gate, которое выпускается уже порядка 10 лет, но мне оно попалось в продакшене только сейчас. Первое знакомство было в статье S-Terra VPN.

Проблема NAT

Речь пойдёт конечно же про PAT (Port Address Translation), он же NAT с перегрузкой, он же маскарадинг. Когда множество частных IPv4 адресов хостов внутренней сети сопоставляется одному публичному IPv4 адресу роутера. Самая распространённая форма NAT.

Роутер с PAT подменяет IPv4 адреса в пакетах хостов на свой адрес, переписывая заголовок пакета. Поэтому когда приходят ответные пакеты, то у них у всех IPv4 адрес назначения — это адрес роутера. Как роутеру определить какой пакет какому хосту внутри сети предназначен? Сделать это можно только по порту назначения в заголовке транспортного уровня.

Но как быть если для разных хостов в заголовке транспортного уровня используется один и то же порт? Когда придут ответные пакеты, роутер просто не сможет определить для какого хоста они предназначаются. В таком случае PAT подменяет и номер исходного порта источника, ведя таблицу преобразований NAT:

If the original source port is already used, PAT assigns the first available port number starting from the beginning of the appropriate port group 0–511, 512-1023, or 1024–65535. CCNA R&S: Connecting Networks

При работе туннеля шифрованная нагрузка ESP цепляется сразу к IP заголовку. В таком пакете нет заголовка транспортного уровня и значит нет номера порта. Нет номера порта, PAT не может правильно функционировать:

По этой причине ESP не будет ходить через PAT без дополнительных инструментов. В статье CISCO IPsec таким инструментом являлось исключение трафика для IPsec VPN из ACL, который отбирает трафик для преобразования NAT.

Нет проблем это сделать, если NAT и VPN-шлюз на одном устройстве. Но что делать, если NAT встречается где-то ещё по пути следования пакета?

Обход NAT

В этом случае используется обход NAT (NAT-Traversal, NAT-T). Что говорит CISCO? Читаем тут:

NAT Traversal is a feature that is auto detected by VPN devices. There are no configuration steps for a router running Cisco IOS Release 12.2(13)T. If both VPN devices are NAT-T capable, NAT Traversal is auto detected and auto negotiated.

То есть сами VPN пиры должны уметь NAT-T на уровне прошивки. При этом согласовывание NAT-T происходит автоматически. Принцип работы NAT-T такой: пакет ESP обёртывается в UDP с номером порта 4500. Это позволяет нормально пропускать пакеты с ESP через PAT.

Согласование NAT-T имеет свои накладные расходы, заголовок UDP весит 8 байт и настолько же уменьшается полезная нагрузка:

Топология

Соберём следующую топологию в EVE-NG: два роутера CISCO, на одном будет настроен NAT и за этим роутером S-Terra. Топология несколько притянута за уши, так как S-Terra полноценный роутер, а не просто VPN-шлюз.

Другое дело что для настройки NAT и файрволла на S-Terra придется использовать iptables. На классическом роутере CISCO такая настройка более прозрачна. Хотя не удивлюсь, если подобная схема «S-Terra за роутером» используется где-то в продакшене:

В качестве образов использую старые-добрые Dynamips c3725-adventerprisek9-mz.124-15.T14 . Версия IOS 12.4 > 12.2 и значит NAT-T данная прошивка умеет.

Сначала настраиваем сетевую связность, чтобы все устройства видели друг-друга:

• Конфигурация R1:

! ip route 0.0.0.0 0.0.0.0 1.1.1.2 ip route 192.168.1.0 255.255.255.0 10.10.10.1 !

Маршрут по умолчанию на R2 и маршрут в сеть 192.168.1.0/24.

ip route 0.0.0.0 0.0.0.0 10.10.10.2

ip route 0.0.0.0 0.0.0.0 1.1.1.1

Проверяем, всё отовсюду пингуется, PC1 пингует PC2 и наоборот.

Настройка PAT

Добавляем на R1:

interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ip nat outside ip virtual-reassembly duplex auto speed auto ! interface FastEthernet0/1 ip address 10.10.10.2 255.255.255.252 ip nat inside ip virtual-reassembly duplex auto speed auto ! ip route 0.0.0.0 0.0.0.0 1.1.1.2 ip route 192.168.1.0 255.255.255.0 10.10.10.1 ! ip nat inside source list 1 interface FastEthernet0/0 overload ! access-list 1 permit 192.168.1.0 0.0.0.255 access-list 1 permit 10.10.10.0 0.0.0.3

Под NAT должен подпадать трафик из сети 192.168.1.0/24 наружу и трафик из подсети 10.10.10.0/30 наружу, то есть и трафик туннеля тоже.

Проверяем заработал ли NAT. Пингуем с PC2 ресурсы, всё что за 1.1.1.1 теперь недоступно, пинги не проходят.

Теперь пингуем с PC1 и S-Terra адрес R2 1.1.1.2, смотрим на R1 таблицу преобразований NAT:

NAT работает. Что по поводу туннеля?

Настройка туннеля

Далее настраиваем туннель между S-Terra и R2. Конфигурация R2:

crypto isakmp policy 1  encr 3des  authentication pre-share  group 5  lifetime 86400 crypto isakmp key Str0ngP@$w0rd address 1.1.1.1 ! ! crypto ipsec transform-set SET1 esp-aes 256 esp-sha-hmac ! crypto map IPsecMap 1 ipsec-isakmp  set peer 1.1.1.1  set transform-set SET1  match address IPSEC ! ! interface FastEthernet0/0 ip address 1.1.1.2 255.255.255.0 duplex auto speed auto  crypto map IPsecMap ! ip access-list extended IPSEC  permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

Моменты которые нужно отметить:

• Под туннель подпадает трафик из сети 192.168.2.0/24 в сеть 192.168.1.0/24;
• Адрес S-Terra 10.10.10.1 будет подменятся на внешний адрес R1 при проходе через NAT, поэтому в качестве пира на R2 везде указываем 1.1.1.1;
• Из-за ограничений S-Terra, которая рассчитана на гостовые протоколы, приходится использовать несекьюрную группу 5 Диффи-Хеллмана и хеширование SHA (это настройка по умолчанию поэтому не показывается в конфигурации).

На S-Terra всё аналогично, только параметры хостов и подсетей зеркальные. Под туннель подпадает трафик из сети 192.168.1.0/24 в сеть 192.168.2.0/24. Адрес пира 1.1.1.2.

Проверка №1

Со стороны R2 туннель поднять нельзя. Если R2 первым отправит туннельный трафик, трафик будет отброшен, так как R1 не знает как обрабатывать этот трафик.

Но если S-Terra отправит туннельный трафик, то трафик уходит через PAT, попадает на R2 и далее. В таблице преобразований NAT на R1 появится запись. И когда придёт ответный трафик с R2, этот трафик подвергнется обратному преобразованию NAT и S-Terra его получит. То есть туннель поднимется и будет нормально работать в обе стороны пока существует запись в таблице преобразований.

Проверим это. Попробуем запустить пинг с PC1 на PC2. И.. ничего не работает. Включим дебаг ISAKMP на R2:

R2# debug crypto isakmp Crypto ISAKMP debugging is on

Любая ошибка как несовпадение паролей или параметров SA и тогда вывод дебага заканчивается:

*Aug 9 14:30:00.000: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 1.1.1.1) - MM_NO_STATE means that the VPN phase 1 (ISAKMP) is not even negotiated

Наконец все ошибки из-за невнимательности отловлены, туннель поднимается и пинг с PC1 на PC2 проходит. Смотрим таблицу трансляций NAT на R1:

Запись 1 это согласование ISAKMP, запись 2 пакеты ESP обёрнутые в UDP. Роемся в дебаге на R2 и ищем там буквы про NAT:

*Aug 9 14:34::48.951: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID . *Aug 9 14:35:09.091: ISAKMP (0:0): vendor ID is NAT-T RFC 3947 . *Aug 9 14:35:33.419: ISAKMP (0:1003): NAT found, the node outside NAT

То есть NAT-T согласовывается уже на первой фазе туннеля.

Проверим SA на S-Terra и сравним результаты с результатами из записи S-Terra VPN. Там было:

NAT-T согласовался и это указано в свойствах IPsec SA. Соответственно с PC2 пинги на PC1 тоже стали проходить:

NAT Keepalive

Но запись в таблице трансляций NAT живёт ограниченное время и если нет трафика со S-Terra, то таблица трансляций очистится, значит трафик с R2 опять будет отброшен.

Однако на самом деле траффик со S-Terra будет идти постоянно. Очистим таблицу трансляций на R1 и просто подождём, никакой трафик по туннелю в это время не запускаем:

Как видно запись пересоздалась. Это работает механизм NAT-T, называемый NAT Keepalive (не путать с IKE Keepalive). Он как раз нужен чтобы предотвратить очистку таблицы трансляций.

Захватим пакеты с интерфейса S-Terra в сторону R2:

Пакеты NAT Keepalive отправляются только с устройства, которое за NAT:

The location of the NAT device is important, as the keepalives have to initiate from the peer "behind" the NAT.

Настройка связности через PAT

Тем не менее связность VPN пиров пока только в одну сторону. Что тут можно придумать?

Если дополнительно сделать на R1 статический NAT на S-Terra, то это будет взаимно-однозначное сопоставление внутреннего и внешнего адресов. А задача была чтобы S-Terra отправляла трафик именно через PAT. Не подходит.

Поэтому прокинем порты с R1 на S-Terra. Конфигурация R1:

ip nat inside source static udp 10.10.10.1 500 1.1.1.1 500 extendable ip nat inside source static udp 10.10.10.1 4500 1.1.1.1 4500 extendable

Трафик ISAKMP это UDP порт 500, а ESP после согласования NAT-T будет работать как UDP порт 4500. А что это за параметр Extendable?

"Extendable" static translations: The extendable keyword allows the user to configure several ambiguous static translations, where an ambiguous translations are translations with the same  local or global address.

Поскольку у нас 2 правила трансляции портов с одинаковыми адресами, то и нужен данный параметр.

Проверка №2

Cохраняем конфигурации и перезагружаем все устройства. Теперь пинг запускаем с PC2 на PC1. Запускаем WireShark на интерфейсе R1 в сторону R2 и смотрим что получилось:

Туннель успешно поднимается. Шифрованный трафик теперь может нормально инициироваться любой из двух сторон, что и нужно было.

Записи ESP в выводе Wireshark не должны смущать. Если такую запись развернуть, то там порт 4500 UDP (будет показано далее).

Разрешение трафика через ACL

Если настраивать на R1 CBAC-файрвол, то для согласования туннеля и прохождения шифрованного трафика нужен ACL, который будет висеть на интерфейсе в сторону R2:

R1(config)# ip access-list extended firewall_acl R1(config-ext-nacl)# permit udp host 1.1.1.2 host 1.1.1.1 eq isakmp R1(config-ext-nacl)# permit udp host 1.1.1.2 host 1.1.1.1 eq 4500 R1(config-ext-nacl)# exit R1(config)# interface FastEthernet 0/0 R1(config-if)# ip access-group firewall_acl in

Добавление второй S-Terra

Из вывода таблицы преобразований NAT было видно, что используется номер порта 4500 и всё замечательно. А что если за NAT будет 2 устройства с IPsec VPN? Как R1 различит трафик для каждого из устройств?

Добавим вторую S-Terra и посмотрим каким образом роутер R1 с этим разберётся:

Топология ещё более «притянута за уши» чем первая, но она нужна такая для проверки работы.

Дополнительная настройка

interface FastEthernet1/0 ip address 10.10.11.2 255.255.255.252 ip nat inside ip virtual-reassembly duplex auto speed auto ! ip route 192.168.3.0 255.255.255.0 10.10.11.1 ! access-list 1 permit 192.168.3.0 0.0.0.255 access-list 1 permit 10.10.11.0 0.0.0.3

Делаем интерфейс Fa1/0 внутренним для NAT, добавляем маршрут в сеть 192.168.3.0/24, добавляем в ACL1 новые правила для NAT.

На S-Terra2 всё аналогично S-Terra1. На R2:

ip access-list extended IPSEC permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 permit ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

Не нужно добавлять новую строчку для крипто-карты crypto map IPsecMap 2 ipsec-isakmp (хотя можно сделать и так), все параметры совпадают. Поэтому только добавляем ещё 1 строку в ACL IPSEC.

Проверка №3

Протестируем туннели. Запустим постоянный пинг с PC1 на PC2 и с PC3 на PC2. Пинг нормально проходит. Смотрим таблицу трансляций NAT на R1:

То есть при трансляции в пакетах порты для устройства S-Terra2 подменяются и они уже не 500 и 4500, а 1 и 1024. Потому что 500, 4500 заняты под другое устройство (S-Terra1). Стандартная работа PAT по подмене портов.

Тут ещё раз подробнее: Inside Local это исходные порты до преобразования NAT, Inside Global после преобразования. Соответственно, если посмотреть ответные пакеты, то для S-Terra1 предназначены пакеты:

А для S-Terra2 пакеты:

И тут возникает вопрос: как тогда для S-Terra2 прокидывать порты снаружи вовнутрь? Ведь при работе NAT хостами внутренней сети будет отправлено множество пакетов и комбинации портов в таблице NAT будут разными в разные моменты времени.

Значит порты, используемые для IPsec S-Terra2, могут быть произвольными в широком диапазоне. Прямого ответа на этот вопрос для данного варианта настройки туннеля у меня нет.

Хотя все параметры, включая адрес пира (1.1.1.1) совпадают, R2 видит 2 раздельных ассоциации ISAKMP.

Что ещё? Можно было бы повесить дополнительно PAT и на R2, но это полностью аналогично тому, что делалось на R1. И тут надо обратить внимание на важный момент: если NAT-T согласуется, то порт UDP 4500 используется в обе стороны. У нас за NAT только S-Terra была, а UDP 4500 используется и для S-Terra, и для R2.

NAT Virtual Interface

Последнее что нужно отметить, не сильно важное для IPsec, но просто интересное: когда был настроен NAT на R1, то появился дополнительный интерфейс — NVI.

Этот виртуальный интерфейс введён в IOS 12.3(14)T :

Recall that classic NAT first performs routing and then translation when going from an inside interface to an outside interface, and vice versa when the traffic flow is reversed. NVI, however, performs routing, translation, and routing again; NVI performs the routing operation twice, before and after translation, before forwarding the packet to an exit interface.

Нужен NVI чтобы обходить ограничения классического NAT. Например, когда на роутере настроен PAT совместно со статическим NAT: клиенты из внутренней сети не смогут попасть на Web-сервер по его внешнему адресу.

Работа NVI позволяет устранить данное ограничение.

Практика

Сейчас в связи с массовым переходом на удалёнку сильно востребованы решения для удалённого доступа. Вариантов тут много:

• PAM (Privileged Account Management) решения;
• Различные реализации VPN.

PAM есть как программные, например Thycotic Secret Server, так и программно-аппаратные в виде апплаенсов, пример решения Pulse Connect Secure. Или вот, допустим, для Check Point NGFW это Mobile Access Blade.

Смысл PAM такой: сначала через HTTPS, как правило с двойной аутентификацией, происходит подключение к WEB серверу, на странице сервера после аутентификации доступны подключения к ресурсам. Это файловые ресурсы, URLs, RDP или SSH. Учётка для подключения к PAM может быть учёткой AD или просто отдельной учётной записью без связи с AD.

Секьюрно, круто и удобно, но стоит хороших денег. Поэтому широко распространены VPN сервера для удалённого подключения. На базе IPsec, PPTP, L2TP, OpenVPN, WireGuard. Это могут быть отдельно стоящие сервера типа MS Always On VPN или VPN настроенные на маршрутизаторах и FWs.

И конечно же тут будет NAT в большинстве случаев. А куда без него? Допустим, есть какая-то реализация IPsec VPN. Какая именно не важно. И работает плохо: у клиента отвалы, проблемы с установкой соединения. VPN сервер проверен, в FW организации открыты порты UDP 500, 4500 для внешнего адреса VPN сервера. В чём же дело?

Трабла обычно со стороны клиента. Не утверждаю что всегда так, но это прям массовая штука. Обычный «серый» IP находится по факту за 2 NAT. Первый NAT на домашнем роутере, второй на оборудовании провайдера. Проблема во втором NAT (криво работает маппинг портов) и управлять им нет возможности. Что делать?

Покупать у провайдера «белый» IP. Решает в 90% случаев. На этом всё. Надеюсь было познавательно и полезно.

Share this:

• Click to share on Telegram (Opens in new window)
• Click to share on WhatsApp (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• More

• Click to print (Opens in new window)
• Click to email a link to a friend (Opens in new window)