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

Gen-X

то правило у меня и так выше всех стоит.
Во 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