Проблема при работе с 2-мя WAN интерфейсами
-
Дело такое.
Имеется 2 интерфейса:
WAN для IPSec 10.0.0.0/8 соединения
И LAN подсеть 10.110.6.0/24После того как заблокировали доступ к 10.100.5.11 (SIP Server) и 10.100.5.15 (VKS Server) через WAN и дали доступ к этим адресам через другой канал, решил добавить в pfSense еще один WAN (далее WAN2) интерфейс и объеденить их для доступа через LAN.
Сделал следующее, в настройках IPSec соединения Phase2 исключил 2 адреса, 10.100.5.11 и 10.100.5.15. Поставил сетевую карту WAN2 (Static IP 10.100.44.1/20) для доступа к 10.100.5.11 и 10.100.5.15. И в LAN Rules создал правило для доступа к 10.100.5.11 и 10.100.5.15 указав Gateway от WAN2. В NAT ничего не настраивал и никаких вручную добавленных правил нет.
Всё соединяется, пинги есть но наблюдается следующее, на компьютере через софтфон Microsip подключаюсь к 10.100.5.11 SIP серверу, звонки идут собеседник поднимает трубку, но ни он ни я друг-друга не слышим, а фаервол pf Sense показывает что UDP пакеты идут через IPSec.
Что мне делать, что и как настраивать?
Firewall - LAN правило
IPSec Phase2 исключены 10.100.5.11 и 10.100.5.15. Отключил 10.0.0.0/8 и добавил 25 подсетей вместо него
То, что показывает Firewall Log
Diagnostics / States -
@Gen-X Здр
Пока сложно понять , что и как у Вас настроеноПроблема слышимости в RTP (одно или двухсторонней) обычно состоит в том , что в SIP Invite пакете содержится неверная информация о Ip адресе , через который пойдет обмен RTP пакетами . Те это проблема настройки NAT в настройках SIP сервера и/или софтфона
Обратите внимание , что по таблицам состояний нет rtp пакетов
есть только пакеты для портов 5060/5061 ( а это sip пакеты) -
Добрый
@Gen-XВо floating rules правил нет?
И в LAN Rules создал правило для доступа к 10.100.5.11 и 10.100.5.15 указав Gateway от WAN2.
Поставьте это правило выше всех. После или перезагрузите пф или сделайте Reset states.
Зы2. Покажите скрины правил fw на ВСЕХ интерфейсах.
Зы3. Чем обусловлен выбор Ipsec? На том конце что-то, что не умеет openvpn (к-ый гибче и удобнее)?
-
- то правило у меня и так выше всех стоит.
- Во floating ничего нет.
- Pf перезагружал много раз, не помогло.
- IPSec затем, что потусторонний монополист-админ захотел чтоб так было. Кстати он и разделил эти 2 адреса.
- Скрины всех правил скину завтра, как буду на работе.
-
@Gen-X Здр
еще раз
Повторюсь , если связь с SIP сервером есть ( я так понял , что она есть ) , то через Packet capture (tcpdump) посмотрите внутрь SIP пакетов , на предмет того , о чем устройства "договариваются " .
Если можете , выложите здесь pcap файл SIP обмена при вызове -
@werter
Floating
WAN
VKS
LAN
IPSec -
@Konstanti packetcapture.cap
pcap файл SIP обмена при вызове -
@Gen-X У меня есть подозрение , что у Вас настроена связь через TLS . Увы , на лету расшифровывать трафик не умею .
вот как это выглядит у Вас
а вот как должно в идеале ( для анализа)
-
@Konstanti
Так что как мне теперь нужно мне настраивать всё? Помогите советом и инструкцией. -
@Gen-X
Сложно что либо советовать "вслепую" , но у каждого телефона/софтфона или sip сервера есть настройки NAT
Выглядеть это может по-разному , например , вот так
те идея в том , чтобы при SIP соединении устройств,находящихся за NAT, указывался внешний ip адрес для RTP трафика , чтобы это проверить нужен "чистый" sip трафик ( при использовании tls это ,увы, невозможно)
Вот тут на картинке четко видно , где настраиваются параметры внешнего ip адреса и сервера STUN (раздел PUBLIC IP) для Вашего софтфона.https://www.microsip.org/help
Если нет такой возможности , как вариант пускать весь SIP/RTP трафик через ipsec туннель (те без использования внешних сетей). Тогда таких проблем быть не должно.
-
@Gen-X Здр
Кстати , обратите внимание на Ваш pcap файл (у Вас только сообщения от 44.1 к 5.11, а ответных пакетов нет) .У Вас в pcap файле очень много RTP пакетов от 44.1 к 5.11
самого SIP обмена не вижу (те устройства договорились о том , что
RTP трафик сервер ждет на порту 16532 хост 10.100.5.11)
Инициирует звонок устройство 10.110.6.16 (номер 7504)
Обратного трафика нет - это значит , что сервер отправляет обратный трафик куда-то в сторону. Или Вы его не захватили.
Насчет TLS я был не прав (его нет)
Очень нужен пакет SIP INVITE
Я все-таки склоняюсь к мысли, что с настройками NAT у Вас проблемы
Поясню почему
Смотрите что у Вас (это что отправляет о себе устройство , когда оно внутри сети)Message Header From: "7504"<sip:7504@10.100.5.11>;tag=aea040-0-13c4-5dbca443-3aaeb11c-5dbca443 SIP Display info: "7504" SIP from address: sip:7504@10.100.5.11 SIP from address User Part: 7504 SIP from address Host Part: 10.100.5.11 SIP from tag: aea040-0-13c4-5dbca443-3aaeb11c-5dbca443 To: "7504"<sip:7504@10.100.5.11> SIP Display info: "7504" SIP to address: sip:7504@10.100.5.11 Call-ID: b07388-0-13c4-5dbca443-4795a198-5dbca443 CSeq: 1 REGISTER Via: SIP/2.0/UDP 10.110.6.16:5061;branch=z9hG4bK-5dbca443-28e1a7a8-6ee3303e Transport: UDP Sent-by Address: 10.110.6.16 Sent-by port: 5061 Branch: z9hG4bK-5dbca443-28e1a7a8-6ee3303e Expires: 3600 Allow: INVITE,CANCEL,BYE,REFER,NOTIFY,SUBSCRIBE,INFO,ACK,MESSAGE,UPDATE user-Agent: ZXV10 P806L V4.3.0.0 10797 Max-Forwards: 70 Supported: replaces,100rel,eventlist Contact: <sip:7504@10.110.6.16:5061;transport=UDP> Contact URI: sip:7504@10.110.6.16:5061;transport=UDP Contact URI User Part: 7504 Contact URI Host Part: 10.110.6.16 Contact URI Host Port: 5061 Contact URI parameter: transport=UDP Content-Length: 0
а должно быть так (когда NAT верно настроен) - раздел сообщения Contact
Message Header Via: SIP/2.0/UDP 192.168.1.42:58139;branch=z9hG4bK-524287-1---c100e3a052f1d748;rport Transport: UDP Sent-by Address: 192.168.1.42 Sent-by port: 58139 Branch: z9hG4bK-524287-1---c100e3a052f1d748 RPort: rport Max-Forwards: 70 Contact: <sip:1000@37.153.XX.XX:58139;rinstance=583d9b0ab894c61f;transport=UDP> Contact URI: sip:1000@37.153.XXX.XXX:58139;rinstance=583d9b0ab894c61f;transport=UDP Contact URI User Part: 1000 Contact URI Host Part: 37.153.XX.XX Contact URI Host Port: 58139 Contact URI parameter: rinstance=583d9b0ab894c61f Contact URI parameter: transport=UDP To: <sip:1000@pbxru.m.org:6001;transport=UDP> SIP to address: sip:1000@pbxru.m.org:6001;transport=UDP From: <sip:1000@pbxru.m.org:6001;transport=UDP>;tag=07236c4c SIP from address: sip:1000@pbxru.morg:6001;transport=UDP SIP from address User Part: 1000 SIP from address Host Part: pbxru.m.org SIP from address Host Port: 6001 SIP From URI parameter: transport=UDP SIP from tag: 07236c4c Call-ID: zyDhs1x4nw4pGTnvVbaXyA.. CSeq: 1 REGISTER Expires: 60 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE User-Agent: Zoiper rv2.10.3.0 Allow-Events: presence, kpml, talk Content-Length: 0
те в Вашем случае раздел Contact должен выглядеть , например,так
Contact: <sip:7504@10.100.44.1:5061;transport=UDP> Contact URI: sip:7504@10.100.44.1:5061;transport=UDP Contact URI User Part: 7504 Contact URI Host Part: 10.100.44.1 Contact URI Host Port: 5061 Contact URI parameter: transport=UDP Content-Length: 0
Поэтому я думаю , что ответные пакеты и идут через IPSEC .
Потому что SIP сервер ищет хост 10.110.6.16
надо проверять настройки -
Добрый
@Gen-XПравила на ЛАН (к-ые c Toshkent в описании ) работать не будут - отключайте. Запомните, что работают только те правила, к-ые НЕПОСРЕДСТВЕННО относятся к сетям на ЭТИХ интерфейсах.
IPSec Phase2 исключены 10.100.5.11 и 10.100.5.15. Отключил 10.0.0.0/8 и добавил 25 подсетей вместо него
Создайте ОДИН IPsec-туннель и во 2-ой фазе нарисуйте роут только до ip сип-сервера. Далее правилами fw разрешайте-запрещайте доступ к нему из ЛАН. Всё. Идиотизм какой-то (
Одним словом "каша". Сядьте за стол. Возьмите ручку и бумагу. Нарисуйте схему с адресацией. Работайте по ней.
Зы. Мой вам совет. Разрешите на время все всем и везде на всех интерфейсах. После этого проверяйте свою IP-телефонию. Как бы не вышло так, что на интерфесах у вас взаимоисключающие правила.
Зы2. Для общей картины linkmeup.gitbook.io/sdsm/ В закладки.
-
@werter said in Проблема при работе с 2-мя WAN интерфейсами:
Правила на ЛАН (к-ые c Toshkent в описании ) работать не будут - отключайте
если Вы об этих, то они у меня работают как ограничители скорости для этих 3-х пользователей к адресам из альяса "Toshkent_Cameras" -
@werter said in Проблема при работе с 2-мя WAN интерфейсами:
Зы. Мой вам совет. Разрешите на время все всем и везде на всех интерфейсах. После этого проверяйте свою IP-телефонию
Я пробовал это. Из-за того что через IPSec разрешён доступ, с СИП сервером даже соединиться не сможет не зная через какой интерфейс нужно подключаться.
-
@Konstanti said in Проблема при работе с 2-мя WAN интерфейсами:
Потому что SIP сервер ищет хост 10.110.6.16
Я тоже склоняюсь к этому. Так как до этого когда в phase2 IPSec тоннеля был только 10.0.0.0/8. Если после перезапуска pfsense сначала активировать WAN2 и подключится к SIP серверу, только после активировать WAN интерфейс IPSec тоннеля, то всё работало.
-
@Konstanti said in Проблема при работе с 2-мя WAN интерфейсами:
а должно быть так (когда NAT верно настроен)
Вот я не могу разобраться в этих настройках NAT.
Хочу чтоб любой IP адрес из 10.110.6.0/24 при соединении с 10.100.5.11 выдавал себя за 10.100.44.1 (WAN2 IP адрес pfSense) (или любой другой IP 10.100.44.1/24) чтоб обратная связь от 10.100.5.11 тоже была к 10.100.44.1, а он соответственно передавал на 10.110.6.0/24. -
@Gen-X
Для этого есть такая настройка STUN сервер - вот с ней разбирайтесь
Как это все настраивать в Вашем софтфоне я Вам уже писал
Включайте захват пакетов не на wan интерфейсе , а на LAN и изучайте SIP трафик. Всю информацию Вы сможете вытащить из пакета SIP INVITE