Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Russian
    17 Posts 3 Posters 605 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • werterW
      werter
      last edited by werter

      Добрый
      @Gen-X

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

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

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

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

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

      G 2 Replies Last reply Reply Quote 0
      • G
        Gen-X @werter
        last edited by

        @werter

        1. то правило у меня и так выше всех стоит.
        2. Во floating ничего нет.
        3. Pf перезагружал много раз, не помогло.
        4. IPSec затем, что потусторонний монополист-админ захотел чтоб так было. Кстати он и разделил эти 2 адреса.
        5. Скрины всех правил скину завтра, как буду на работе.
        K 1 Reply Last reply Reply Quote 0
        • K
          Konstanti @Gen-X
          last edited by

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

          G 1 Reply Last reply Reply Quote 0
          • G
            Gen-X @werter
            last edited by Gen-X

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

            1 Reply Last reply Reply Quote 0
            • G
              Gen-X @Konstanti
              last edited by

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

              K 1 Reply Last reply Reply Quote 0
              • K
                Konstanti @Gen-X
                last edited by

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

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

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

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

                G 1 Reply Last reply Reply Quote 0
                • G
                  Gen-X @Konstanti
                  last edited by

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

                  K 2 Replies Last reply Reply Quote 0
                  • K
                    Konstanti @Gen-X
                    last edited by

                    @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 туннель (те без использования внешних сетей). Тогда таких проблем быть не должно.

                    1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @Gen-X
                      last edited by 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
                      надо проверять настройки

                      G 2 Replies Last reply Reply Quote 0
                      • werterW
                        werter
                        last edited by 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/ В закладки.

                        G 2 Replies Last reply Reply Quote 0
                        • G
                          Gen-X @werter
                          last edited by

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

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

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

                          1 Reply Last reply Reply Quote 0
                          • G
                            Gen-X @werter
                            last edited by

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

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

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

                            1 Reply Last reply Reply Quote 0
                            • G
                              Gen-X @Konstanti
                              last edited by

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

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

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

                              1 Reply Last reply Reply Quote 0
                              • G
                                Gen-X @Konstanti
                                last edited by

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

                                K 1 Reply Last reply Reply Quote 0
                                • K
                                  Konstanti @Gen-X
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.