Mikrotik + Azure IPSec. Отваливается соединение

Question

[alex_dredd]

Добрый день. Есть микротик CCR1016-12G. Прошивка на нем последняя - 6.15. И есть облачная сеть в Microsoft Azure. Соединение между 2я этими узлами должно происходить посредством ipsec туннеля. Туннель на микроте настраивал по этой статье: blogs.technet.com/b/rharper/archive/2012/11/15/cre... .
Туннель даже поднимается и появляется пинг с компов в облаке на наземные компы, которые за микротиком. А потом начинается мистика: каждую 44ю секунду каждой минуты пинг пропадает и не появляется до момента, пока не передернешь туннель. После переподключения опять работает до 44й секунды следующей минуты.
В логах появляется такое(первые 3 строки - это момент, когда туннель поднялся и пинг появился; далее события, во время которых туннель отваливается):

Jun/13/2014 15:46:06 ipsec IPsec-SA established: ESP/Tunnel 23.100.56.172[0]->77.222.151.182[0] spi=191848165(0xb6f5ee5)
Jun/13/2014 15:46:06 ipsec IPsec-SA established: ESP/Tunnel 77.222.151.182[0]->23.100.56.172[0] spi=2567954844(0x990fe19c)
Jun/13/2014 15:46:43 ipsec,debug,packet ==========
Jun/13/2014 15:46:44 ipsec,debug,packet 380 bytes message received from 23.100.56.172[500] to 77.222.151.182[500]
Jun/13/2014 15:46:44 ipsec,debug,packet df08daf3 04b87d45 58c60aa1 918151bf 08102001 00000002 0000017c 42eb3ac6
Jun/13/2014 15:46:44 ipsec,debug,packet 760c06f1 28310427 8d3f87f6 a73ea5b6 31e593de a305849d 8fb640c0 ec66c595
Jun/13/2014 15:46:44 ipsec,debug,packet bd0a6148 7681a30e df8539fd 2587c20a 5c6c8e9a ab9968f9 10d4b6fe fcfb5ced
Jun/13/2014 15:46:44 ipsec,debug,packet ae1fa737 bdd644ea e0932506 9fab04ca 0139dd8d 403ad91f e19acb34 e459a958
Jun/13/2014 15:46:44 ipsec,debug,packet a5832dbb 13529726 42135255 f73aa9a0 fdd6715b 36fa1111 edb52369 0f8ba9a2
Jun/13/2014 15:46:44 ipsec,debug,packet 5a6e30b8 6321f8f0 54a6f49e c4a0a70e ec9be50e a35a417b 1f136375 60cc12ca
Jun/13/2014 15:46:44 ipsec,debug,packet 83c272db 1d04bb08 4dff1727 c084ca50 3c2665ae b15d1133 f3e5e77e 4959a94a
Jun/13/2014 15:46:44 ipsec,debug,packet 097f09db d530c275 2ff59ba1 88997820 16941761 91bed59b 0074c795 699ba5ac
Jun/13/2014 15:46:44 ipsec,debug,packet 67be07e9 39317fbd 286195a2 71d0a36f 3196b398 15353db3 963db178 38e97090
Jun/13/2014 15:46:44 ipsec,debug,packet 8bc2056b 9eb4d285 9a2316ce 2ee07541 4ffd44f0 644dcc6d 8f7630f9 8b91f45d
Jun/13/2014 15:46:44 ipsec,debug,packet be4683d7 20f4a01c 3bca626e 4e19368f 56aa788a 0ad5ade4 f4c1f94f d2d5a32c
Jun/13/2014 15:46:44 ipsec,debug,packet 13e3e7c7 70e4848a 95a7835d 9c9b0a45 07f36f6e 8b0228f9 b3eedeef
Jun/13/2014 15:46:44 ipsec,debug,packet compute IV for phase2
Jun/13/2014 15:46:44 ipsec,debug,packet phase1 last IV:
Jun/13/2014 15:46:44 ipsec,debug,packet 034a528a eeb1f224 3263f871 0192ecd3 00000002
Jun/13/2014 15:46:44 ipsec,debug,packet hash(sha1)
Jun/13/2014 15:46:44 ipsec,debug,packet encryption(aes)
Jun/13/2014 15:46:44 ipsec,debug,packet phase2 IV computed:
Jun/13/2014 15:46:44 ipsec,debug,packet bff8bc15 75a7a8c5 00bcdd5f 702e7b5d
Jun/13/2014 15:46:44 ipsec,debug,packet ===
Jun/13/2014 15:46:44 ipsec,debug respond new phase 2 negotiation: 77.222.151.182[500]<=>23.100.56.172[500]
Jun/13/2014 15:46:44 ipsec,debug,packet encryption(aes)
Jun/13/2014 15:46:44 ipsec,debug,packet IV was saved for next processing:
Jun/13/2014 15:46:44 ipsec,debug,packet 9c9b0a45 07f36f6e 8b0228f9 b3eedeef
Jun/13/2014 15:46:44 ipsec,debug,packet encryption(aes)
Jun/13/2014 15:46:44 ipsec,debug,packet with key:
Jun/13/2014 15:46:44 ipsec,debug,packet ad90d294 a8543b21 3367d5ad 7422aa91
Jun/13/2014 15:46:44 ipsec,debug,packet decrypted payload by IV:
Jun/13/2014 15:46:44 ipsec,debug,packet bff8bc15 75a7a8c5 00bcdd5f 702e7b5d
Jun/13/2014 15:46:44 ipsec,debug,packet decrypted payload, but not trimed.
Jun/13/2014 15:46:44 ipsec,debug,packet 01000018 1992aaa6 cc183dc8 c27f2eb7 5b7fbe8e c66a9331 0a0000e8 00000001
Jun/13/2014 15:46:44 ipsec,debug,packet 00000001 02000038 01030401 2a0b334c 0000002c 010c0000 80040001 80060100
Jun/13/2014 15:46:44 ipsec,debug,packet 80050005 80010001 00020004 00000e10 80010002 00020004 061a8000 02000038
Jun/13/2014 15:46:44 ipsec,debug,packet 02030401 2a0b334c 0000002c 010c0000 80040001 80060100 80050002 80010001
Jun/13/2014 15:46:44 ipsec,debug,packet 00020004 00000e10 80010002 00020004 061a8000 02000038 03030401 2a0b334c
Jun/13/2014 15:46:44 ipsec,debug,packet 0000002c 010c0000 80040001 80060080 80050002 80010001 00020004 00000e10
Jun/13/2014 15:46:44 ipsec,debug,packet 80010002 00020004 061a8000 00000034 04030401 2a0b334c 00000028 01030000
Jun/13/2014 15:46:44 ipsec,debug,packet 80040001 80050002 80010001 00020004 00000e10 80010002 00020004 061a8000
Jun/13/2014 15:46:44 ipsec,debug,packet 05000034 d97938f4 f579cdc9 07c87ce7 564c24e5 71389ac6 2e7fd2b3 cbac1cc7
Jun/13/2014 15:46:44 ipsec,debug,packet 7d27a799 3865bc6b d23dd681 d0b96088 ce123108 05000010 04000000 0a000000
Jun/13/2014 15:46:44 ipsec,debug,packet ffffff00 00000010 04000000 c0a80300 ffffff00 00000000 00000000 00000000
Jun/13/2014 15:46:44 ipsec,debug,packet padding len=1
Jun/13/2014 15:46:44 ipsec,debug,packet skip to trim padding.
Jun/13/2014 15:46:44 ipsec,debug,packet decrypted.
Jun/13/2014 15:46:44 ipsec,debug,packet df08daf3 04b87d45 58c60aa1 918151bf 08102001 00000002 0000017c 01000018
Jun/13/2014 15:46:44 ipsec,debug,packet 1992aaa6 cc183dc8 c27f2eb7 5b7fbe8e c66a9331 0a0000e8 00000001 00000001
Jun/13/2014 15:46:44 ipsec,debug,packet 02000038 01030401 2a0b334c 0000002c 010c0000 80040001 80060100 80050005
Jun/13/2014 15:46:44 ipsec,debug,packet 80010001 00020004 00000e10 80010002 00020004 061a8000 02000038 02030401
Jun/13/2014 15:46:44 ipsec,debug,packet 2a0b334c 0000002c 010c0000 80040001 80060100 80050002 80010001 00020004
Jun/13/2014 15:46:44 ipsec,debug,packet 00000e10 80010002 00020004 061a8000 02000038 03030401 2a0b334c 0000002c
Jun/13/2014 15:46:44 ipsec,debug,packet 010c0000 80040001 80060080 80050002 80010001 00020004 00000e10 80010002
Jun/13/2014 15:46:44 ipsec,debug,packet 00020004 061a8000 00000034 04030401 2a0b334c 00000028 01030000 80040001
Jun/13/2014 15:46:44 ipsec,debug,packet 80050002 80010001 00020004 00000e10 80010002 00020004 061a8000 05000034
Jun/13/2014 15:46:44 ipsec,debug,packet d97938f4 f579cdc9 07c87ce7 564c24e5 71389ac6 2e7fd2b3 cbac1cc7 7d27a799
Jun/13/2014 15:46:44 ipsec,debug,packet 3865bc6b d23dd681 d0b96088 ce123108 05000010 04000000 0a000000 ffffff00
Jun/13/2014 15:46:44 ipsec,debug,packet 00000010 04000000 c0a80300 ffffff00 00000000 00000000 00000000

Буду рад, если сможете помочь.

Answer 1

[Клёвый Админ]

Коллега, покажите секцию Ipsec из MT (убрав приватные данные, разумеется), похоже таймаут чего либо или же ошибка в конфигурации \ баг.

Так же самостоятельно проверьте msdn.microsoft.com/library/azure/jj156075.aspx#BKM... все параметры по первой колонке.

Comments

[alex_dredd]

Azure_IP - IP адрес шлюза Ажура
EXT_IP - наш внешний реальный айпишник
10.0.0.0/24 - Внутренняя сеть ажура, в которой находятся виртуалки
192.168.0.0, 192.168.3.0, 192.168.10.0, 192.168.1.0 - внутренние сети предприятия
Не обращайте внимания, что все задизейблено - я временно все отключил, чтоб он в логах не гадил.

[admin@MikroTik] > ip ipsec export verbose 
# jun/16/2014 11:50:39 by RouterOS 6.15
# software id = RH2I-QMHR
#
/ip ipsec mode-config
set (unknown) name=request-only send-dns=yes
/ip ipsec policy group
set default name=default
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha1 disabled=yes enc-algorithms=3des,aes-128-cbc,aes-256-cbc lifetime=8h name=default pfs-group=modp1024
/ip ipsec peer
add address=AZURE_IP/32 auth-method=pre-shared-key dh-group=modp1024 disabled=yes dpd-interval=17m4s dpd-maximum-failures=5 enc-algorithm=aes-128 exchange-mode=main generate-policy=no hash-algorithm=sha1 lifebytes=0 lifetime=8h local-address=\
    0.0.0.0 my-id-user-fqdn=EXT_IP nat-traversal=yes passive=no port=500 proposal-check=obey secret=qtCthIBfb8xzr3d9hW2vFJNRJbudDq5v send-initial-contact=yes
/ip ipsec policy
add action=encrypt disabled=yes dst-address=10.0.0.0/24 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=default protocol=all sa-dst-address=AZURE_IP sa-src-address=EXT_IP src-address=192.168.1.0/24 src-port=any \
    tunnel=yes
add action=encrypt disabled=yes dst-address=10.0.0.0/24 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=default protocol=all sa-dst-address=AZURE_IP sa-src-address=EXT_IP src-address=192.168.10.0/24 src-port=any \
    tunnel=yes
add action=encrypt disabled=yes dst-address=10.0.0.0/24 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=default protocol=all sa-dst-address=AZURE_IP sa-src-address=EXT_IP src-address=192.168.3.0/24 src-port=any \
    tunnel=yes
add action=encrypt disabled=yes dst-address=192.168.0.0/16 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=default protocol=all sa-dst-address=EXT_IP sa-src-address=AZURE_IP src-address=10.0.0.0/24 src-port=any \
    tunnel=yes
add action=encrypt disabled=yes dst-address=10.0.0.0/24 dst-port=any ipsec-protocols=esp level=require priority=0 proposal=default protocol=all sa-dst-address=AZURE_IP sa-src-address=77.222.151.182 src-address=192.168.0.0/24 src-port=any \
    tunnel=yes

[Клёвый Админ]

Проверил, идей нет =( Думаю нужно смотреть все логи debug режима или же делать иное соединение VPN.

[alex_dredd]

да в том-то и дело, что другое соединение не прокатит. Ажур только это поддерживает

[Клёвый Админ]

@alex_dredd я имел в виду, что ВПН уже из виртуалки, а не из облака, и дальше уже смаршрутизировать его.

[alex_dredd]

@ifaustrue идея уже появилась такая: берем в аренду виртуалку где-то в Европе, поднимаем там windows 2012 server, на нем строим IPSec в ажур. Там же строим pptp или l2tp сервер, куда будут поднимать сессии наши микроты.

[Клёвый Админ]

@alex_dredd а в ажуре если сразу виртуалку арендовать не вариант? Ни никсах она дешёвая и проца есть мало будет.

[alex_dredd]

Они заявляют, что у них маршрутизатор работать не будет. Не поддерживают они такую историю.

[Клёвый Админ]

@alex_dredd да херня какая то =) Я просто так поднимал (правда с "той" стороны был керио). Делаешь там сеть, одна виртуалка видит другую, и маршрут до твоей локальной сети, от целевой виртуальной машины лежит через ту что является VPN GW. Я никаких подводных камней не встретил =)

На крайний вариант ВПН можно бросить от Windows VM до Linux VM, а дальше уже до MK. Прото этот сценарий всё равно проще чем городить внешний VPS и бросать трафик через него =)

Answer 2

[Diman89]

А откатиться на, скажем, 6.12 пробовали? Вроде как в новых что-то поломанным было?

Comments

[alex_dredd]

Пробовал на 6.12, 6.13, 6.14