Проблема при работе с 2-мя WAN интерфейсами

Gen-X

Дело такое.
Имеется 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

Konstanti

@Gen-X Здр
Пока сложно понять , что и как у Вас настроено

Проблема слышимости в RTP (одно или двухсторонней) обычно состоит в том , что в SIP Invite пакете содержится неверная информация о Ip адресе , через который пойдет обмен RTP пакетами . Те это проблема настройки NAT в настройках SIP сервера и/или софтфона

Обратите внимание , что по таблицам состояний нет rtp пакетов
есть только пакеты для портов 5060/5061 ( а это sip пакеты)

werter

Добрый
@Gen-X

Во floating rules правил нет?

И в LAN Rules создал правило для доступа к 10.100.5.11 и 10.100.5.15 указав Gateway от WAN2.

Поставьте это правило выше всех. После или перезагрузите пф или сделайте Reset states.

Зы2. Покажите скрины правил fw на ВСЕХ интерфейсах.

Зы3. Чем обусловлен выбор Ipsec? На том конце что-то, что не умеет openvpn (к-ый гибче и удобнее)?

Gen-X

@werter

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

Konstanti

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

Gen-X

@werter
alt text
Floating

WAN

VKS

LAN

IPSec

Gen-X

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

Konstanti

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

вот как это выглядит у Вас

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

Gen-X

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

Konstanti

@Gen-X
Сложно что либо советовать "вслепую" , но у каждого телефона/софтфона или sip сервера есть настройки NAT
Выглядеть это может по-разному , например , вот так

те идея в том , чтобы при SIP соединении устройств,находящихся за NAT, указывался внешний ip адрес для RTP трафика , чтобы это проверить нужен "чистый" sip трафик ( при использовании tls это ,увы, невозможно)
Вот тут на картинке четко видно , где настраиваются параметры внешнего ip адреса и сервера STUN (раздел PUBLIC IP) для Вашего софтфона.

https://www.microsip.org/help

Если нет такой возможности , как вариант пускать весь SIP/RTP трафик через ipsec туннель (те без использования внешних сетей). Тогда таких проблем быть не должно.

Konstanti

@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
надо проверять настройки

werter

Добрый
@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/ В закладки.

Gen-X

@werter said in Проблема при работе с 2-мя WAN интерфейсами:

Правила на ЛАН (к-ые c Toshkent в описании ) работать не будут - отключайте

если Вы об этих, то они у меня работают как ограничители скорости для этих 3-х пользователей к адресам из альяса "Toshkent_Cameras"

Gen-X

@werter said in Проблема при работе с 2-мя WAN интерфейсами:

Зы. Мой вам совет. Разрешите на время все всем и везде на всех интерфейсах. После этого проверяйте свою IP-телефонию

Я пробовал это. Из-за того что через IPSec разрешён доступ, с СИП сервером даже соединиться не сможет не зная через какой интерфейс нужно подключаться.

Gen-X

@Konstanti said in Проблема при работе с 2-мя WAN интерфейсами:

Потому что SIP сервер ищет хост 10.110.6.16

Я тоже склоняюсь к этому. Так как до этого когда в phase2 IPSec тоннеля был только 10.0.0.0/8. Если после перезапуска pfsense сначала активировать WAN2 и подключится к SIP серверу, только после активировать WAN интерфейс IPSec тоннеля, то всё работало.

Gen-X

@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.

Konstanti

@Gen-X
Для этого есть такая настройка STUN сервер - вот с ней разбирайтесь
Как это все настраивать в Вашем софтфоне я Вам уже писал
Включайте захват пакетов не на wan интерфейсе , а на LAN и изучайте SIP трафик. Всю информацию Вы сможете вытащить из пакета SIP INVITE