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

MultiWAN+OpenVPN_Site-to-Site+NAT

Scheduled Pinned Locked Moved Russian
4 Posts 3 Posters 2.3k 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.
  • I
    Ingria
    last edited by Sep 10, 2012, 12:53 PM

    Коллеги, настраивал ли кто-нибудь сабж?
    Всё воскресенье убил, чтобы заставить эту связку работать, так и не удалось.
    Имеем 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 Sep 10, 2012, 1:39 PM

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

      Похоже, что это не баг, это фича:
      "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 May 20, 2013, 6:22 AM

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

        1 Reply Last reply Reply Quote 0
        • W
          WY6EPT
          last edited by Aug 24, 2013, 7:58 PM

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

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            [[user:consent.lead]]
            [[user:consent.not_received]]