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

    MultiWAN+OpenVPN_Site-to-Site+NAT

    Russian
    3
    4
    2.3k
    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.
    • I
      Ingria
      last edited by

      Коллеги, настраивал ли кто-нибудь сабж?
      Всё воскресенье убил, чтобы заставить эту связку работать, так и не удалось.
      Имеем 2 LANs+2pfsense's+4 ISPs
      между локалками гоняется IPSEC, с ним проблем нет (ну или почти нет, за исключением загадочных глюков на этапе работы ISAKMP)
      есть еще по резервному WAN линку на каждую локалку. Для файловерности хочу поднять OpenVPN Site-to-Site (имхо, оптимальное решение, если учесть, что один из линков - с динамическим IP)
      В общем, клиент (pfsense) достукивается, tun подымается. iroute сеть/маска в client overrides стоит, записи в таблице маршрутизации о достижиомсти сети через ovpn-шафсу создаются. Но пакеты ходят только с pfsense'ов. Т.е. с каждого шлюза могу достичь удаленной локалки, и наоборот, из удаленной локалки доступен ovpn-интерфейс шлюза. А вот между локалками - тишина. tcpdump на ovpn интерфейсе ничего не показывает. Т.е. пакеты приходят на локальный интерфейс, помещаются в ядро, и… дальнейший их путь мне непонятен, тк. они ни дропаются (pflog0 молчит), ни на внешнем интерфейсе не появляются. Нужные правила на фаерволе на локальном интефейсе, перед общим лоадбалансингом есть. Заметил только, что при трассировке со шлюза исходящее правило нат создается, а при трассировке с локалки - нет. В общем, буду признателен за наводки, готового рецепта в общем-то и не надо.
      Спасибо

      1 Reply Last reply Reply Quote 0
      • I
        Ingria
        last edited by

        Сам танцую, сам пою  :)

        Похоже, что это не баг, это фича:
        "Because of the way IPsec ties into the FreeBSD kernel, any enabled IPsec connection matching
        the local and remote subnets that exists when IPsec is enabled (even if it is not up) will cause that
        traffic to never be routed across the OpenVPN connection. Any IPsec connections specifying
        the same local and remote networks must be disabled."
        Придется подымать два независимых openvpn-туннеля…

        1 Reply Last reply Reply Quote 0
        • A
          alex_pupkin
          last edited by

          Вот такая же ерунда была, теперь ясно почему оно так работает. НО я удалил все IPsec подключения  и вырубил службу на одном шлюзе, а на втором удалил подключения связанное с этой сетью, службу там выключить нельзя, с другимим офисами по IPsec связь идёт. Тогда вопрос это вообще что ли IPsec как службу надо на обоих шлюзах вырубать?

          1 Reply Last reply Reply Quote 0
          • W
            WY6EPT
            last edited by

            Тут дело в самой структуре сайт то сайт.
            Дело в том, что этот вид тоннелирования одно направленый. Тоесть, если ам нужно попасть из сети А в сеть Б мы по запросу поднимаем тоннель в удаленный офис. И на оборот при запросе из Б в А мы поднимаем тоннель из удаленного офиса.
            Вот такие пироги, зато за счет такого построения сетей можно получить доступ из А к точке В через Б. Но нужно писать динамические маршруты при не достижении точки В напрямую.

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