Прокидывать broadcast udp из одной подсети в другую
-
Имеем две машинки с pfsense. Одна раздаёт интернет в подсеть 192.168.0.1, другая в 192.168.1.1, в разных офисах города.
Между подсетями опять же средствами pfsense поднят IPSEC VPN.Клиентские компутеры в офисах замечательно видят друг друга и пингуются.
На этих компах почти у всех работников установлена программа локального чата net speakerphone.
Периодически она анонсирует пользователя в сети, посылая широковощательный UDP пакет на порт 8765.
И вот, на одном офисе все видят своих работников, на другом своих, что логично, поскольку широковещательный траффик не "пробивает" в другую подсеть.Задача: заставить UDP пакеты, отосланные на порт 8765, "перебегать" через IPSEC VPN и благополучно броадкастить в другую подсеть, дабы объединить списки пользователей чата.
Такое возможно стандартными средствами pfsense? Заранее всем спасибо за советы.
-
В правилах fw (обеих сетей) во вкладке IPSEC есть разрешение для данного вида трафика ? Плюс, вкл. логирование на fw-ах и смотрите что и как блочится.
-
В правилах fw (обеих сетей) во вкладке IPSEC есть разрешение для данного вида трафика ?
Плюс, вкл. логирование на fw-ах и смотрите что и как блочится.Там всё хорошо, IPSEC настроен на прокидывание любого TCP/UDP + ICMP, в правилах для локальных интерфейсов тож всё разрешено.
Пакеты не блочатся, просто никому не доставляются. Если бы какая-то программа прям на фряхе, где крутится pfsense, забиндилась на 0.0.0.0, и сказала, что будет слушать UDP на порту 8765, тогда бы она стала получать эти пакеты. У них был бы широковещательный адрес назначения внутренней подсети, например 192.168.0.255. И вот надо, чтобы этот пакет магическим образом заимел адрес назначения 192.168.1.255, переправился в другую подсеть через тунель (уже поднят IPSEC в подсеть 192.168.1.0/24), и вывалилось из туннеля в сетевую карту в локалку на другом оффисе. И то же самое должно происходить в обратную сторону, из другого офиса в этот.
Подходом в лоб стало бы написание специального демона, запущенного в разных офисах, который всем бы этим занимался, однако сперва решил спросить тут грамотных людей, дабы не городить велосипедов.
Ещё на другом форуме http://bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=4&m=164961 мне ответили "если VPN route-based а не policy-based, то можно попробовать изловчиться и использовать rdr-to", только я не понимаю что это значит, потому что не очень знаком с freebsd'шным pf, реализацией IPSEC, и вообще, использую pfsense из-за её отличнейших возможностей гуёвого конфигурирования. От чего и не хотелось бы сильно отходить, и возможно, всё уже написано до нас, и достаточно где-то в закромах настроек pfsense повозюкать мышкой :-)
-
Вот ответ c форума и из FAQ m0n0wal :
http://forum.m0n0.ch/index.php?topic=330.0
http://doc.m0n0.ch/handbook/faq-broadcasts-over-vpn.htmlBroadcasts don't cross broadcast domains. In the case of a VPN link, each network is its own broadcast domain. Normally you don't want to connect broadcast domains because most networks have way more broadcast traffic than you want to push over a VPN connection. In some cases like this it may be desirable, but it's not possible with IPsec.
15.29. Can I forward broadcasts over VPN for gaming or other purposes?
Not yet. OpenVPN will make this possible in the future.
Вот еще из ipfire довольно свежий (http://forum.ipfire.org/index.php?topic=6011.0) :
broadcasts (to all network other devices) are not routed to other networks.
P.s. По поводу OpenVPN (http://www.ossg.ru/docs/OpenVPN/faq.html) :
What is the difference between bridging and routing?
Bridging and routing are two methods of linking systems via a VPN.
Bridging advantages
Broadcasts traverse the VPN – this allows software that depends on LAN broadcasts such as Windows NetBIOS file sharing and network neighborhood browsing to work.
No route statements to configure.
Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
Relatively easy-to-configure solution for road warriors.Т.е. поднимаем OpenVPN сервер , используя TAP (по L2 к-ый работает) и рисуем правила в fw. После этого в туннеле должен будет "бегать" любой трафик.
-
Т.е. поднимаем OpenVPN сервер , используя TAP (по L2 к-ый работает) и рисуем правила в fw. После этого в туннеле должен будет "бегать" любой трафик.
Это очень хорошо, если бы я планировал VPN "с нуля", сейчас уже запущен IPSEC, который вяжет не только наши офисы, но ещё и обеспечивает защ. связь с кое-какими сторонними организациями и их сервисами.
Я вот тут нашёл старинный софт, с двумя параметрами командной строки, под названием udp-proxy, с юниксовыми сорцами на 100 строк: http://www.vttoth.com/CMS/technical-notes/63-an-ip-tunnelling-problem-a-case-study#Appendix . Руки конечно чешутся его скомпилить и прибить гвоздями в pfsense, однако меня удивляет, что такой полезный сервис ещё не внедрили в pfsense сами разработчики… Хотелось бы видеть его отдельным пакетом, и видеть его состояние, например, в индикаторе Dashboard -> Services status.
Поскольку написание сервисов pfsense в виде его пакетов -- занятие, требуещее гораздо большего опыта, чем компиляние стострокового сорца, попробую привлечь кого-нить из опытных разработчиков pfsense за скромную оплату и попросить их внедрить эту штуку в будущие версии pfsense, как сервис, значительно расширяющий круг возможного применения этой замечательной системы.
Боюсь правда суммы, которую они озвучат :-\
-
Кстати, возможно совет и глупый, но в VPN: IPsec: Edit Phase 2 вашего IPSEC-туннеля можно выбрать Mode :Transport.
Может это даст желаемый результат? -
У нас в студенческой сети тоже долго использовали net speakerphone. Посмотрите в настройках, там есть опция определяющая маску рассылки (я уже не помню точно, вроде в ini файле эта опция была) и поставьте ее шире 192.168.255.255 Правда в итоге мы перешли на платную версию с отдельным сервером без широковешания.