Не регистрируется телефон через IPSec-туннель mikrotik-fortigate?

Question

[MrDZ]

Добрый день, на удаленных объектах часто не регистрируются телефоны. Сети доступны, грубо говоря пинг есть. Связь между центральным офисом и удаленными филиалами организован через ipip tunnet + ipsec.
На микротиках обнаружил в connection tracking в этот момент вижу такую картину:
SAC protocol=udp src-address=10.5.0.100:5060
dst-address=172.1.0.15:5060 reply-src-address=172.1.0.15:5060
reply-dst-address=внешний ip:5060 timeout=2m28s orig-packets=6
orig-bytes=2 955 orig-fasttrack-packets=0 orig-fasttrack-bytes=0
repl-packets=6 repl-bytes=3 489 repl-fasttrack-packets=0
repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

где 10.5.0.100 - удаленный sip телефон
172.1.0.15 - сервер телефонии в филиале

reply-dst-address= ожидаемый ответ почему-то внешний ip роутера. Временно помогает сброс сессии на микротике.
На микротике есть что то вроде sip helper , я так понимаю. enable или disable этой функции ни как не помог.
Отдельно в firewall или nat правила для телефона ни как не настраивал.

Comments

[Valentin Barbolin]

172.1.0.15 тебя не смущает использование белого ip в локальной сети?
Пинг проходит от сервера к телефону?
Похоже, что не хватает правил для IPSec в firewall.

[MrDZ]

Andrey Barbolin, ошибся в описании, считай там, где должен быть серый, он серый.
Да пинги ходят

[Valentin Barbolin]

MrDZ, Похоже, что не хватает правил для IPSec в firewall. - мокажешь firewall ? (/ip firewall export)

[MrDZ]

Andrey Barbolin
/ip firewall filter
add action=accept chain=input comment=Ping protocol=icmp
add action=accept chain=forward protocol=icmp
add action=drop chain=input dst-port=4500 protocol=udp
add action=drop chain=input protocol=udp src-port=4500
add action=accept chain=input comment="Accept connection" connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=accept chain=input comment="Allow IPsec, L2TP" dst-port=500,1701 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=input protocol=udp src-port=500,1701
add action=accept chain=input comment="allow pptp" dst-port=1723 protocol=tcp
add action=accept chain=input comment="Local network" in-interface=!ether1-gateway src-address=10.5.0.0/24
add action=accept chain=forward comment="Local to net" dst-address-list=internet_service in-interface=!ether1-gateway \
out-interface=ether1-gateway
add action=accept chain=input comment=Input_access src-address-list=RFC1918
add action=accept chain=input src-address-list=input_centraloffice
add action=drop chain=input comment="Drop incoming" in-interface=ether1-gateway
add action=accept chain=forward comment="VPN traffic" src-address-list=RFC1918
add action=accept chain=forward dst-address-list=RFC1918
add action=accept chain=forward comment=full_nat src-address-list=ip_list_full_nat
add action=reject chain=forward comment="Drop all" disabled=yes protocol=tcp reject-with=tcp-reset

/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" ipsec-policy=out,none out-interface=ether1-gateway \
src-address=10.5.0.0/24

Answer 1

[MrDZ]

Видимо nat тут при делах. Правильно ли я понимаю:
Когда микротик включают, телефонный шлюз начинает искать сервер телефонии, но найти его не может т.к. пока vpn поднимется, пока динамическая маршрутизация построится. И поэтому reply-dst-address в сессии имеет внешний ip микротика (почему эта сессия так и остаётся - другой вопрос). Сделал route type blackhole в ту сеть, наблюдаю - пока всё хорошо.

Answer 2

[Keffer]

С телефонией по L3 у микротика плохо. Да и не только у микротика к слову сказать. Для телефонии православнее всего создавать отдельный vlan и гонять его между точками по MPLS\VPLS а на конечных устройствах куда телефоны подключаются, создавать access порты в этот вилан.

Comments

[Keffer]

poisons, Это очень интересный вопрос, что там такого плохого. Ставил в свое время десятки опытов по организации телефонии и только в полностью L2 среде переставало глючить и работало 100%. В остальных случаях то регистрация отвалится, то долго регится, то звука нет (несмотря на то что нат отсутствует!) В целом этому есть объяснение, при L3 среде все соединения и пакеты от sip бегают через Connection Tracker а при L2 нет. А почему в трекере пакеты ломаются, вопрос открытый.

[Keffer]

poisons,

Даже в рамках небольшого офиса на 100 рабочих мест телефоны и АТС скорее всего при нормальном планировании сети окажутся в разных l2 сегментах.

Если админ криворукий то да, там и не такое возможно. Сам лично строил ip телефонию на овер500 аппаратов и все они прекрасно жили в одном L2 пространстве, в сетке /22 и все работало отлично, один сип\тфтп на всех, при том что филиалы территориально разнесены на значительные расстояния.

И да, ip-ip само по себе убогое, и еще в довесок ipsec периодически валится, проверено. Наилучшее решение в плане секьюрности как ни странно, это ppp с хорошим шифрованием, а именно sstp с сертификатом и поверх него mpls\vpls