Доброе время суток. Суть проблемы в следующем: есть туннель PPTP, клиент — микротик, сервером является довольно экзотический Watchguard Firebox. При установлении udp(sip) соединения через туннель происходит нечто странное, в Reply Dst. Address этого соединения прописывается не ip из подсети VPN, а ip присвоенный wan интерфейсу, ну и само собой ответа на пакеты не приходит. Если руками сбросить это UDP соединение в микротике, то на новом соединении адрес подставляется правильный и всё работает до следующего реконнекта. Пробовал обновить прошивку до 5.21(последняя вроде как) до этого была 5.17 всё то же самое.
Я понимаю что поздновато пишу, но вдруг кому-то пригодится. :)
В микротике нужно в firewall nat перед правилом masquerade создать правило accept:
пример ip firewall nat add src-address=192.168.88.0/24 dst-address=192.168.0.0/24 action=accept
причем это правило должно быть обязательно перед правилом ната (маскарадинга). Смысл в том, что пакеты идущие из локальной сети 192.168.88.0/24 в сеть впн 192.168.0.0.24 не будут доходить до правил ната, т.к. он будут просто проходить по правилу accept.
Ну думаю что дело в микротике. Только что сделал тест, подключился по pptp с микротика, сделал этот маршрут дефолтным и подключился к asterisk, софт-фоном Zoiper.
вот что дает по подключению:
sip: ХХХ@192.168.25.250:5060
и звонки проходят нормально. адрес 192.168.25.Х как раз адрес которых получил микротик по pptp от сервера.
Сервер pptp на CentOS.
Скорее всего у Вас проблема с Вашим «экзотическим Watchguard Firebox».
Да, кстати, если клиент за NAT-ом, то записит от настроек клиента какой адрес выдаеться астериску, при keep-alive и биндинге портов, можно отдавать адрес реальный, и астериск не будет знать и внутреннем адресе, в противном случае, он получает и наружный адрес, и адрес локальный, за NAT.
посмотрите sip show peer номер
и будет видно.
Во-первых маршрут у меня это не дефолтный, дефолтным является полученый wan'ом шлюз, но соответственно подсеть 192.168.0.0/24 доступна только через pptp. Во-вторых у меня сначала тоже работает, пока соединение не переподключится допустим из-за сбоя в сети. В-третьих у меня ещё и pptp идет через NAT, не знаю как у вас.
ну дефолтный или нет не имеет значения, ведь для 192.168.0.0/24 он заворачивается на pptp, а значит дефолтный для этой сети.
нет, pptp у меня идет с реального адреса, но в Вашем случае это не должно играть никакой роли.
Дело то не в астериске, клиент делает udp-сессию в которой обратный адрес указан не тот, самое странное, что если вручную это соединение сбросить, то клиент ещё раз создаст уже нормальную сессию.
Тут как бы вообще клиент делает соединение, он понятия не имеет где этот адрес и посылает запрос на шлюз, который уже видит, что адрес из подсети, которая находится за pptp вот на этом этапе я вижу, что микротик поставил не тот адрес. Прикладываю изображение, красным выделил правильный адрес, вместо него ставится адрес WAN интерфейса, при том что остальные адреса не меняются.
Была описанная в вопросе проблема. Детально описал настройки астера и микротиков в цетральном и удаленных офисах у себя на странице _blog.erofeevonline.ru
Если коротко, то суть такова:
1. Правильно создаем клиентов (local и remote address)
2. Прописываем маршруты на удаленных микротиках
3. На центральном отрубаем Sip helper
4. Смотрим в настройки удаленного роутера IP-->Firewall--NAT нет ли там маскарада в сторону центрального. Если есть, то это и будет проблемным местом. Значит удаленный роутер подменяет адрес клиента своим внешним.
Простой
