Разрешить трафик между OpenVpn, IpSec и локальной сетью
-
Я понимаю... Степень своей не осведомленности я уже осознал))) но работаю над этим с вашей помощью))) вообщем, что бы решить этот вопрос анализируем данные packet capture и копаемся в правилах настройки фаервола. Правильно?
-
@dimm56 нет, все не так
Работу файрвола изучает факультативно. Думаю, что тут проблема в другом. Нужен pcap файл для анализа происходящего -
Правило для LAN на OVPN-интерфейсе не рисуется. Оставьте на OVPN только * * * * * , остальные удалите.
Что у 192.168.6.27 шлюзом? Должен быть лок. адрес пф. У всех в сети 192.168.6.0 должен быть 192.168.6.49. Иначе доступ не получите.
Плюс у всех в сети 192.168.6.0 должна быть правильная маска (и на пф тоже) (как минимум /24). Иначе доступ не получите.
И если у вас на 192.168.6.27 веб-сервер - смотрите его настройки. Может там доступ не из локальной сети запрещен. Проверяйте.Можно попасть из OVPN клиента через браузер на сам pfSense 192.168.6.49
Это плохо. В будущем разрешайте досту к вебке пф только избранным.
-
Спасибо за ценные советы. Я учту все это в своей работе. Что есть сегодня: 1. Модемы keenetic надо обновлять или отключать обновления, если все уже и так работает стабильно. Кропотливо перебирая их настройки увидел желающих поставить обновления) и, о чудо, после обновления ещё пару тоннелей поднялись сами, хотя может просто помогла сама перезагрузка. 2. Модемы kennetic не очень любят изменения уже созданных vpn соединений без полной перезагрузки. Обновление и авто перезагрузка модема заставило поднять ещё пару каналов). Остальные каналы добил руками, просто удаляя и создавая подключения заново. На сегодняшний день остался только один тоннель который не хочет подниматься, но думаю и это решу. 3. Всегда и везде включайте правило проверки дохлых пиров, особенно на мобильных сетях и когда нет статики т.е. нет возможности попасть в модем при не работающем тоннеле, что бы модемы всегда старались восстановить подключение ( так я потерял один удаленный туннель на 4G канале и мне придется просить людей с ноутбуком ехать туда и дать мне доступ для его донастройки((((). 4. Модемы kennetic дают возможность создания бесплатных ddns адресов! Это первое что надо сделать при подключении к модему!! Тогда у вас всегда будет гарантированный резервный канал для связи. Плюс к этому очень интересно попробовать проглотил ли pfsense в поле "удаленный шлюз" Фаза 1 в качестве адреса ddns имя, а не чистый ip адрес. 5. Pfsense, keenetic - все используют strongswan, а значит, продолжая идею просто берём strongswan client for android и просто заставляем работать все это вместе))) apple клиенты и так имеют качественный встроенный vpn клиент, им ставить ничего не надо. Красота))) А openvpn будем использовать лишь для того, что бы дать доступ по rdp к 1С серверу. Получается тоже классно. Ipsec и openvpn каналы не связанный друг с другом и каждый получает что хочет. Безопасники свою сеть видеонаблюдения. Простые смертные пользователи))) доступ к 1С. План на выходные настройка мобильных android клиентов и уже окончательно решение данного вопроса.
-
@dimm56
Роутеры zyxel keenetic умеет прошивку PADAVAN, к-ая расширяет возможности (появл-ся openvpn и т.д.). Форум 4pda в помощь.Ps. Классные dyndns:
https://freemyip.com/
http://www.duckdns.org/На своем пф пользую ТРИ ddns-сервиса. На случай ,если какой-то из них "сдохнет". Openvpn на клиентах прекрасно умеет пользовать неск-ко имен сервера.
-
У нас keenetic lite 3. Тему же есть встроенный ovpn клиент. Да и встроенный в них ddns тоже хорошо работает. В качестве резервного канал у меня статика на адресе))) да и pf на статике висит. Со щвязь проблем нет, а вот настройка - да. Сейчас затык заставить работать без стороннего по на устройствах мобильные тоннели.
Вот рекомендации самого производителя: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev1-xauth.html
Настаиваю, настраиваю, а мой андроид подключаться все не хочет.... Печалька... -
@dimm56
https://bitbucket.org/padavan/rt-n56u/wiki/RU/Часто%20задаваемые%20вопросы#markdown-header-padavanэта прошивка уже использовала аппаратный offload для UDP WAN-трафика и Wi-Fi-трафика
Стандартная это умеет?
-
Честно скажу, не до конца понимаю о чем речь))) поэтому точно сказать не могу)
-
@dimm56 не мучайтесь, поставьте strongswan VPN client для Android. Прекрасно работает в связке с pf
-
Я пытался))) видимо и тут туплю. Насколько я понял клиент не поддерживает psk авторизацию. Только rsa. Настраивал тоннель на rsa и клиента на rsa - не заработало. Бросил до завтра, надо отдыхать хоть иногда))) если есть возможность помощь с настройкамм - буду рад. Тем более что ещё надо apple клиентов подключить. Вообще куча мелких не решённых задач...
-
@dimm56 этот клиент работает только с ikev2, и psk, возможно, не поддерживает. Для использования rsa нужно быть уверенным, что обе точки умеют фрагментировать пакеты и собирать их обратно. Иначе, может быть возможной ситуация, когда сертификат передать не сможете в одном сообщении. После небольшой модификации у меня pf поддерживает ecdsa вместо rsa и авторизация по сертификатам проходит 'на ура'. И ios и Android и Mac OS и сторонние маршрутизаторы
-
Я почему упёрся в универсальную настройку psk+xaut, т.к. по завершению производителя pfsesne это многократно протестированно и одинаково хорошо работает на android и ios. Даже ставит ничего не надо все настраивается стандартными средствами. А сейчас получается ios умеет сама тоннель поднять - это хорошо, а на Андроид приходится ovpn ставить и решать проблему как его в ipsec сети пустить.... Ставить клиент стронгсван, значит переходить на авторизацию по сертификатам, т к. Psk он не поддерживает. Как ни крути, самый универсальный вариант дожимать и заставлять работать psk+xaut))) модно будет все устройства одинаково настраивать в перспективе.
-
@dimm56 said in Разрешить трафик между OpenVpn, IpSec и локальной сетью:
нас keenetic lite 3. Тему же есть встроенный ovpn клиент.
@dimm56 said in Разрешить трафик между OpenVpn, IpSec и локальной сетью:
Тем более что ещё надо apple клиентов подключить.
Все же посмотрите в сторону Open VPN, Клиенты есть для всего.
Получите гибкость маршрутизации, простоту настроек - просто импорт конфига в болшинстве случаев и т.д. -
Работаю с тем, что досталось по наследству. Переход на ovpn потрбудет перенастройки всего, а это считай что заново создать всю систему. А это 22 точки подключения, 3 мобильных клиента и куча видеорегистраторов в тоннелях. Одна только смена ip адресов у всех устройств - большой и кропотливый труд. А на данным момент, все что мне осталось - заставить работать мобильных клиентов и все! Дальше уже в руках есть готовая система с алгоритмом настройки, что очень важно т.к. количество точек со временем будет увеличиваться и мне надо будет их быстро качественно подключать. Это работа не просто что все заработало, делаю всё для того, что бы облегчить себе работу в будущем)))
-
@dimm56
Зря Вы так
Нет ничего лучше чем связка из По одного производителя
Тут как раз и получается Strongswan-StrongswanВот ограничения клиента Strongswan, которые надо учесть , и все прекрасно соединяется . Вы можете использовать аутентификацию EAP-MSCHAPv2 для подключения
Known Limitations/Issues
Only IKEv2 is supported
Client authentication is limited to:
EAP authentication based on username/password (EAP-MSCHAPv2, EAP-MD5, EAP-GTC)
RSA/ECDSA authentication with private key/certificate
EAP-TLS with private key/certificate (see 1.4.5 for limitations)
The server always has to be authenticated with RSA/ECDSA (even when using EAP-TLS, see 1.4.5)
PSK authentication is not supported, as it is potentially very dangerous because the client might send the hash of a weak password to a rogue VPN server. Thus we prefer EAP authentication where the server is first authenticated with a certificate and only afterwards the client uses its password. -
Это будет правильно? Создал еще один обычный тоннель.
Фаза 1
Фаза 2
Уже вижу что нет.... Мой сертификат это сервер, а не пользователь. Сейчас поправлю...
-
@dimm56 Не знаю , что Вы настраиваете , но
повторюсь , что при использования Mutual RSA могут быть неожиданные проблемы , связанные с тем , что при установлении фазы1 некорректно будут/будет передан/ переданы сертификат/сертификаты (связано это с тем что размер данных больше чем размер MTU и сообщения надо фрагментировать ) . Это надо учитывать . Я бы лично при создании туннеля Сеть-Сеть использовал Mutual PSK (Хотя сам использую ECDSA вместо RSA) -
Сеть-сеть, т.е. сервер-модем у нас на PSK и построены. Может я просто логики не могу понять опять)))
Мобильных клиентов запускаем через "Мобильный клиент".
Вот этот документ говорит о том, что можно настроить pfsense так, что бы все работало без применения доп ПО:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev1-xauth.html
Видимо это значит что все устройства можно настроить по ключу PSK и паре логин/пароль стандартными, встроенными в ОС средствами. Вот этого наверное в итоге и хочу добиться - универсальной настройки для всех мобильных устройств. -
@dimm56
Что Вы понимаете под термином "мобильные устройства" ?
То что у Вас на картинках , это соединение Сеть-Сеть
То что по ссылке - это настройка удаленных клиентов ( так называемых,Road-Warrors)IPsec Road-Warrior
Road Warriors are remote users who need secure access to the companies infrastructure. IPsec Mobile Clients offer a solution that is easy to setup with macOS (native) and is know to work with iOS as well as many Android devices. -
Вот, я опять путаюсь в терминах и понятиях))) Извините, если что.... Поставим задачу точно. 4 смартфона (2 iphone + 2 android). Первоначально iphone для просмотра видео в ipsec каналах были подключены так же через ipsec. А Android устройства через OVPN и каким то, мне неизвестным пока образом, заворачивались в ipsec каналы.
Теперь надо уже на базе pfsense сделать то же самое обеспечить все 4 устройствам доступ к видео в ipsec каналах.
Поэтому и зацепился за это:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev1-xauth.html
что бы сделать одну универсальную настройку для всех типов мобильных устройств.
