Проблема при работе с 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 правило
    Firewall - LAN правило

    IPSec Phase2 исключены 10.100.5.11 и 10.100.5.15. Отключил 10.0.0.0/8 и добавил 25 подсетей вместо него
    IPSec Phase2 исключены 10.100.5.11 и 10.100.5.15. Отключил 10.0.0.0/8 и добавил 25 подсетей вместо него

    То, что показывает Firewall Log
    То, что показывает Firewall Log

    Diagnostics / States
    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 (к-ый гибче и удобнее)?



  • @werter

    1. то правило у меня и так выше всех стоит.
    2. Во floating ничего нет.
    3. Pf перезагружал много раз, не помогло.
    4. IPSec затем, что потусторонний монополист-админ захотел чтоб так было. Кстати он и разделил эти 2 адреса.
    5. Скрины всех правил скину завтра, как буду на работе.


  • @Gen-X Здр
    еще раз
    Повторюсь , если связь с SIP сервером есть ( я так понял , что она есть ) , то через Packet capture (tcpdump) посмотрите внутрь SIP пакетов , на предмет того , о чем устройства "договариваются " .
    Если можете , выложите здесь pcap файл SIP обмена при вызове



  • @werter
    alt text
    Floating
    alt text
    WAN
    alt text
    VKS
    alt text
    LAN
    alt text
    IPSec



  • @Konstanti packetcapture.cap
    pcap файл SIP обмена при вызове



  • @Gen-X У меня есть подозрение , что у Вас настроена связь через TLS . Увы , на лету расшифровывать трафик не умею .

    вот как это выглядит у Вас
    2f6724e0-f5b1-4a30-9dda-ce5908ada48b-image.png

    а вот как должно в идеале ( для анализа)

    816533fc-f8ad-46b6-995a-0baeef29d964-image.png



  • @Konstanti
    Так что как мне теперь нужно мне настраивать всё? Помогите советом и инструкцией.



  • @Gen-X
    Сложно что либо советовать "вслепую" , но у каждого телефона/софтфона или sip сервера есть настройки NAT
    Выглядеть это может по-разному , например , вот так
    e0a0603d-2c06-4dd7-b222-5dc13acab38d-image.png

    те идея в том , чтобы при 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 в описании ) работать не будут - отключайте

    001.jpg
    если Вы об этих, то они у меня работают как ограничители скорости для этих 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


Log in to reply