OpenVPN PKI: Site-to-Site инструкция для обсуждения
-
Глупо, но со стороны сервера или со стороны клиента отзываться должен?
Далее у вас пакеты между подсетями сервера и клиента (-ов) нормально "бегают"? Если - да, то не заморачивайтесь.P.s. А проще так - включайте логирование fw и смотрите что блокируется.
Это проверили? Смотрите логи fw - что может быть проще и нагляднее?
-
Добрый день….
Подскажите пожалуйста...
а как можно указать клиентам несколько IP адресов моего cервера?Использовал сервис DYNDNS no-ip.org но сейчас у них проблеммы ну вот как тут можно нормально относится к Майкрософт?…. и клиенты отвалились...
как-то можно задать список IP адресов к которым клиент мог бы пытаться подключаться?... (если не доступен один то пытается подключится по другому..)
-
Указывать несколько remote :
client
remote x.x.x.36 1194
…остальные настройкиremote x.x.x.98 1195
...остальные настройки -
Глупо, но со стороны сервера или со стороны клиента отзываться должен?
Далее у вас пакеты между подсетями сервера и клиента (-ов) нормально "бегают"? Если - да, то не заморачивайтесь.P.s. А проще так - включайте логирование fw и смотрите что блокируется.
Это проверили? Смотрите логи fw - что может быть проще и нагляднее?
Не пингует сам себя…Т.е. сам себя пинговать и не должен? ??? И с некоторых клиентов. Пакеты бегают в обе стороны, но не все как хотелось бы, вот хочу понять с какой стороны копать начинать. В логе тишина - те пинги что проходят есть, те что не проходят и в логе упоминаний о них нет.
Еще вопрос - в мануалах OpenVPN 2.xx в самом начале есть такие слова:
--mode m
Set OpenVPN major mode. By default, OpenVPN runs in point-to-point mode ("p2p"). OpenVPN 2.0 introduces a new mode ("server") which implements a multi-client server capability.
В конфигурационном файле, формируемом через интерфейс pfSense никаких упоминаний mode нет, т.е. работает в режиме p2p. А как сконфигурировать mode server? (В примерах и мануалах на OpenVPN тоже не нашел)PS Немного разобрался, нужно выбирать Remote Access и директива server вставит mode server. Правда обнаружилась другая непонятная вещь - оказывается с топологией subnet формат ifconfig ip mask (как у tap)
-
@ mikhe
В каком режиме работает у вас OpenVPN-сервер ?
-
Я запускал и p2p и RA (перезагружал на всякий случай). Конфигурационные файлы различались лишь парой строк - в конфиге p2p добавлялась строка ifconfig 172.19.19.1 172.19.19.2, а в RA строка client-to-client. Разницы я не заметил - т.е. те подглюкивания, с которыми я пытаюсь бороться есть и там и там.
После внимательного чтения мана опенвпн получается что в результирующем конфиге p2p присутствуют две противоречивые строки ifconfig 172.19.19.1 172.19.19.2, которую вставлят пфсенс и ifconfig 172.19.19.1 255.255.255.0. которая генерится из server 172.19.19.0 255.255.255.0 и topology subnet -
Доброе. Подскажите кто в курсе, есть ли принципиальная разница в организации маршрутизации между подключениями по схеме OpenVPN p2p (share key) и OpenVPN p2p (SSL/TSL)?
Суть проблему в том, что при настройки по схеме OpenVPN p2p (share key), трафик между двумя роутерами на базе pfsense ходит без проблем, в том числе между рабочими станциями, которые находиться в локальных сетях за этими роутерами. Если я перенастраиваю только OpenVPN для работы по схеме и OpenVPN p2p (SSL/TSL), то трафик почему получается односторонним, причем только от клиента к серверу, от сервера к клиенту трафик уже не ходит не говоря о том что и нету трафика между рабочими станциями. При этом с маршрутизации все в порядке, на клиенте есть маршрут в сеть сервера, а на сервере есть маршрут в сеть клиента. Даже если открыть полностью файрвол, то проблема останется. В чем может быть дело?
Схема следующая:
WS1(192.168.1.100)–-(192.168.1.1)pfsense1(WAN)--(WAN)pfsense2(192.168.10.1)--(192.168.10.100)WS2
Туннель в openvpn:
10.0.8.1 <-p2p-> 10.0.8.2 <=p2p=> 10.0.8.5 <-p2p-> 10.0.8.6Таблица маршрутизации на pfsense1 192.168.1.1 (OpenVPN Server)
default 89.89.89.93 UGS 0 50332 1500 em0
10.0.8.0/24 10.0.8.2 UGS 0 3811 1500 ovpns2
10.0.8.1 link#9 UHS 0 3 16384 lo0
10.0.8.2 link#9 UH 0 0 1500 ovpns2
89.89.89.64/27 link#1 U 0 1958172 1500 em0
89.89.89.73 link#1 UHS 0 0 16384 lo0
127.0.0.1 link#6 UH 0 666 16384 lo0
192.168.1.0/24 link#2 U 0 2046000 1500 em1
192.168.1.1 link#2 UHS 0 3 16384 lo0
192.168.10.0/24 10.0.8.2 UGS 0 8093 1500 ovpns2Таблица маршрутизации на pfsense2 192.168.10.1 (OpenVPN Client)
default 89.89.89.73 UGS 0 38973 1500 em0
10.0.8.1/32 10.0.8.5 UGS 0 1382 1500 ovpnc2
10.0.8.5 link#9 UH 0 0 1500 ovpnc2
10.0.8.6 link#9 UHS 0 4 16384 lo0
89.89.89.64/27 link#1 U 0 2051472 1500 em0
89.89.89.93 link#1 UHS 0 0 16384 lo0
127.0.0.1 link#6 UH 0 648 16384 lo0
192.168.1.0/24 10.0.8.5 UGS 0 6257 1500 ovpnc2
192.168.10.0/24 link#2 U 0 1950883 1500 em1
192.168.10.1 link#2 UHS 0 0 16384 lo0Firewall: Rules (pfsense1 и pfsense2)
OpenVPN:
IPv4 * * * * * * none
Lan:
IPv4 * LAN net * * * * nonePing с pfsense1:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нетPing с WS1:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нетPing с pfsense2:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.1.1 (pfsense1)- есть
ответ на 192.168.1.100 (WS1)-естьPing с WS2:
ответ на 10.0.8.1-нет
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нетP.S.
Проверяю на pfsense 2.1.5, на виртуальных машинах, шлюзы это ip противоположенных роутеров. -
2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом. -
2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.а у меня без iroute всё видится)Как туда так и обратно, какспер только иногда всё прикрывает )
-
2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.а у меня без iroute всё видится)Как туда так и обратно, какспер только иногда всё прикрывает )
Так у вас
@Tr0tter:У вас на сертификатах OpenVPN или на shared key построен?
Покажите скрин Certificates на сервере OpenVPN (pfsense).shared key на клиентах вставлен shared key
У меня тоже с ним нету проблем, а тема о подключении OpenVPN p2p (SSL/TSL)
-
2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.Для начала хочу обратить внимание на странность, что с ws2 трафик так и не проходит в сеть pfsense1, хотя на pfsense2 есть маршрут в локальную сеть pfsense1 и к тому же трафик с самого pfsense2 проходит в сеть pfsense1.
Насчет указания директивы iroute на сервер openvpn в Client Specific Override, пробивал указывать
Disabled Common Name Description
NO ovpnc2 (iroute 192.168.10.0 255.255.255.0)
Указывал:
iroute 192.168.10.0 255.255.255.0Но результат прежний, трафик не идет. И да правильно я понимаю что в Common Name нужно указывать интерфейс vpn подключения и в мое случаи ovpnc2 ?
-
И да правильно я понимаю что в Common Name нужно указывать интерфейс vpn подключения и в мое случаи ovpnc2
Нет,не правильно.
http://fastinetserver.wordpress.com/2013/03/09/pfsense-openvpn-static-ip-for-clients/
NOTE: Common Name should be the same as specified in the clients certificate:
If you have forgotten this name go to System\Cert Manager\Certificates and check the value of the CN for your VPN use
-
Доброе. Подскажите кто в курсе, есть ли принципиальная разница в организации маршрутизации между подключениями по схеме OpenVPN p2p (share key) и OpenVPN p2p (SSL/TSL)?
Суть проблему в том, что при настройки по схеме OpenVPN p2p (share key), трафик между двумя роутерами на базе pfsense ходит без проблем, в том числе между рабочими станциями, которые находиться в локальных сетях за этими роутерами. Если я перенастраиваю только OpenVPN для работы по схеме и OpenVPN p2p (SSL/TSL), то трафик почему получается односторонним, причем только от клиента к серверу, от сервера к клиенту трафик уже не ходит не говоря о том что и нету трафика между рабочими станциями. При этом с маршрутизации все в порядке, на клиенте есть маршрут в сеть сервера, а на сервере есть маршрут в сеть клиента. Даже если открыть полностью файрвол, то проблема останется. В чем может быть дело?
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.
Спасибо за разъяснение. Был невнимателен. Действительно нужно было указать подсеть клиента с помощью директивы iroute на сервер в Client Specific Override, где в Common name, нужно было указать Common name из сертификата клиента.
-
А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?
-
А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?
Если имеются в виду подсети за OVPN-клиентами, подключенными к "центральному"OVPN-серверу, то указать каждой подсети маршрут в другую подсеть:
На клиентах в Advanced configuration
route 192.168.Х.0/24 255.255.255.0или, если на сервере используется конфигурация PKI - в Client Specific Overrides
push route "192.168.Х.0 255.255.255.0"где 192.168.Х.0 - сеть удаленного филиала
В редких случаях push route может оказаться нужным дополнить явным указанием шлюза:
push route "192.168.Х.0 255.255.255.0 10.х.х.1"где 10.х.х.1 адрес OVPN-сервера в туннеле
Не лишним может оказаться добавление на LAN на сервере и клиентах правил вида
IPv4 * LAN net * 192.168.Х.0/24 * * none
Обратите внимание на **IPv4 *** - по умолчанию правило создается только для TCP
-
А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?
Если имеются в виду подсети за OVPN-клиентами, подключенными к "центральному"OVPN-серверу, то указать каждой подсети маршрут в другую подсеть:
На клиентах в Advanced configuration
route 192.168.Х.0/24 255.255.255.0или, если на сервере используется конфигурация PKI - в Client Specific Overrides
push route "192.168.Х.0 255.255.255.0"где 192.168.Х.0 - сеть удаленного филиала
В редких случаях push route может оказаться нужным дополнить явным указанием шлюза:
push route "192.168.Х.0 255.255.255.0 10.х.х.1"где 10.х.х.1 адрес OVPN-сервера в туннеле
Не лишним может оказаться добавление на LAN на сервере и клиентах правил вида
IPv4 * LAN net * 192.168.Х.0/24 * * none
Обратите внимание на **IPv4 *** - по умолчанию правило создается только для TCP
Тобишь, если имеется сервер с IPv4 Tunnel Network 172.16.1.0/24 нужно в Advanced добавить помимо вот этого push "route 192.168.0.0 255.255.255.0";
route 192.168.100.0 255.255.255.0; ещё и push route "192.168.5.0 255.255.255.0 172.16.1.0 ? Сеть от 5 заворачиваем через 172.16.1.0 в 100 ? это на одном сервере, тоже самое на другом, только тунель будет другим ? -
Забудьте про адресацию туннелей. Для туннеля ваша единственная задача - обеспечить уникальную (неиспользуемую ни в какой реальной подсети адресацию, которая работает\будет работать в OpenVPN.
После того, как туннель поднялся все настройки производятся с реальными адресами подсетей, шлюзов и т.д.это на одном сервере, тоже самое на другом, только тунель будет другим ?
Давайте уточним терминологию.
Сервер - это то, что ожидает подключения.
Клиент - это то, что инициирует подключение.В случае PKI ("сервер с сертификатами") настройки сервера в client specific overrides в принципе равнозначны настройкам на клиенте.
Например push route "…. в client specific overrides делает то же самое, что route в настройках клиента.
Исключение - директива iroute, ее нужно указывать именно в client specific overrides на сервере. -
Забудьте про адресацию туннелей. Для туннеля ваша единственная задача - обеспечить уникальную (неиспользуемую ни в какой реальной подсети адресацию, которая работает\будет работать в OpenVPN.
После того, как туннель поднялся все настройки производятся с реальными адресами подсетей, шлюзов и т.д.Ну и где это делается ? из сети 192.168.0.0 я могу пинговать всё что можно, а вот из 192.168.5.0 не могу пинговать 192.168.100.0 но из этих сетей я могу пинговать 192.168.0.0
-
Добрый день!
Все сделал как написано в топике, все хорошо работает. Но почему то компьютеры не видят друг друга в сетевом окружении и более того непонятен такой момент. Компьютеры которые находятся в одной подсети с сервером не пингуют компы из подсети клиента, а наоборот пинги есть и доступ по IP.
Какой то парабокс - доступ из клиентской подсети в серверною есть, а наоборот нет :(Сеть с сервером 10.2.0.0/24
Сеть клиента 10.2.1.0/24
Туннель 172.16.0.1/24Маршруты на сервере
default xxx.xxx.xxx.xxx UGS 0 8327006 1500 em1
10.2.0.0 link#1 U 0 8450553 1500 em0
gw01 link#1 UHS 0 0 16384 lo0
10.2.1.0 172.16.0.2 UGS 0 3790876 1500 ovpns1
xxx.xxx.xxx.0/27 link#2 U 0 205476 1500 em1
xxx.xxx.xxx.xxx link#2 UHS 0 0 16384 lo0
localhost link#5 UH 0 217 16384 lo0
172.16.0.0 172.16.0.2 UGS 0 0 1500 ovpns1
172.16.0.1 link#7 UHS 0 0 16384 lo0
172.16.0.2 link#7 UH 0 0 1500 ovpns1Маршруты на клиенте
default xxx.xxx.xxx.xxx UGS 0 29325548 1500 em0
10.2.0.0/24 172.16.0.5 UGS 0 2891014 1500 ovpnc1
10.2.1.0/24 link#2 U 0 28010720 1500 em1
10.2.1.1 link#2 UHS 0 0 16384 lo0
xxx.xxx.xxx.xxx/27 link#1 U 0 715465 1500 em0
xxx.xxx.xxx.xxx link#1 UHS 0 0 16384 lo0
127.0.0.1 link#5 UH 0 176 16384 lo0
172.16.0.1/32 172.16.0.5 UGS 0 0 1500 ovpnc1
172.16.0.5 link#7 UH 0 0 1500 ovpnc1
172.16.0.6 link#7 UHS 0 0 16384 lo0Чего не хватает?
-
NetBIOS, iroute.
-
iroute 10.2.1.0 255.255.255.0 добавлено в specific.
А как быть с NetBios -
Внимательнее смотрите страницу настроек. Там должна быть галка по поводу NetBIOS.
Или поднимайте tap-туннель. -
Добрый день!
Посоветуйте, как лучше реализовать следующую схему:Есть 2 сети за pfsense и внешние виндовые клиенты с виндовым openvpn.
Нужно объединить сети за pfsence и дать возможность внешним клиентам, при подключении видеть общие ресурсы обеих сетей, а не только той к openvpn серверу которой они коннектятся.
При этом не хотелось бы устраивать на pfsense множество серверов openvnc. Желательно вообще 1.Навскидку кажется, что можно это сделать при помощи “Peer to Peer (SSL/TLS)” (PKI), но неясно можно ли подключить туда виндовых клиентов, и если да, то как.
-
Для одиночных клиентов есть Remote access… Peer to Peer - это когда нужно сделать связь сети за сервером с сетью за клиентом.
-
У меня 2 pfsense за каждым из них сеть и эти сети надо объединить. Кроме этого существуют виндовые клиенты, которые подключаются к одному из серверов, но хотят видеть ресурсы из второй сети тоже.
Вы предлагаете, поднять для виндовых клиентов отдельный север с RA, а 2 сети объединять Site 2 Site ? Сейчас так и сделано, но при этом виндовые клиенты видят только сеть за сервером к которому подключаются. -
Если сети за pfSense'ми видят друг-друга, то и клиенты на windows тоже могут без проблем. Нужно просто передать им маршрут в соседнюю сеть. Типа: route 192.168.0.0 255.255.255.0
-
Это сделано, но не помогает *)
-
Наконец, зачем была нужна директива: iroute 192.168.20.0 255.255.255.0 в Client Specific Overrides для клиента ovpnc1
Прописываю iroute в Client Specific Overrides на OpenVPN сервере (что бы прописать мартрут и сказать серверу за каким клиентом сеть) и почему то не добавляется маршрут на сервере, а если прописываю route в Advanced в настройках самого OpenVPN сервера то маршрут прописывается и все работает
-
если прописываю route в Advanced в настройках самого OpenVPN сервера то маршрут прописывается и все работает
Не советую этого делать.
Прописываю iroute в Client Specific Overrides на OpenVPN сервере (что бы прописать мартрут и сказать серверу за каким клиентом сеть) и почему то не добавляется маршрут на сервере
А имя клиента в Client Specific Overrides - правильное ?
NOTE: Common Name should be the same as specified in the clients certificate:
If you have forgotten this name go to System\Cert Manager\Certificates and check the value of the CN for your VPN user
-
Уважаемый werter, прежде все хочу сказать спасибо за Ваши ответы!
Теперь по теме, я задал не правильно вопрос…
В настройках OpenVPN сервера я прописываю -
VPN - OpenVPN - Server - Advanced - route ip_range netmask;
Делаю я это для того что бы в таблице маршрутизации OpenVPN сервера прописался маршрут до удаленной сети за OpenVPN клиентом.Вопрос как можно приписать добавление маршрута в таблицу маршрутизации OpenVPN сервера в настройках
VPN - OpenVPN - Client Specific Overrides - CommonName - Advancedесли прописываю route в Advanced в настройках самого OpenVPN сервера то маршрут прописывается и все работает
Не советую этого делать.
Поясните как лучше сделать?
@werter:Прописываю iroute в Client Specific Overrides на OpenVPN сервере (что бы прописать мартрут и сказать серверу за каким клиентом сеть) и почему то не добавляется маршрут на сервере
А имя клиента в Client Specific Overrides - правильное ?
Да праивльное в предыдущем посте про iroute излишняя информация этой дериктивой прописываем за каким конкретно клентом та или иная сеть.
Почему этого не достаточно и необходимо еще прописывать route в настройках сервера? -
… iroute... этой дериктивой прописываем за каким конкретно клентом та или иная сеть.
Почему этого не достаточно и необходимо еще прописывать route в настройках сервера?Потому что route инсталлирует маршрут в системную таблицу маршрутов pfSense (и говорит системе, что сеть находится за OpenVPN сервером), а iroute - во внутреннюю базу маршрутов OpenVPN (и говорит серверу за каким именно клиентом находится сеть). Это совсем разные вещи.
Почему iroute не инсталлирует маршруты и туда и туда? Таков дизайн, и это правильно. Мне например никакие системные маршруты от iroute не нужны, т. к. я получаю их по OSPF. Что было бы если бы те же маршруты полезло писать туда же iroute? Так что, пусть каждый занимается своим делом.
-
Помогите пожалуйста.. настраивал OpenVPN по этой инструкции … с подводными камнями разобрался и все работало (есть мои посты выше)
Уже подключено с 10 клиентов и все работает.... версия 2.1.3-RELEASE (i386)Сейчас подключается еще 1 клиент.... все настроено как и раньше единственное отличие это новая версия pfSense 2.2.2-RELEASE (i386)
Никак не могу понять что он хочет?... почему реконект?Лог клиента pfSense 2.2.2-RELEASE (i386)
Apr 20 09:18:57 openvpn[96982]: Restart pause, 5 second(s) Apr 20 09:19:02 openvpn[96982]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Apr 20 09:19:02 openvpn[96982]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 20 09:19:02 openvpn[96982]: Socket Buffers: R=[65228->65536] S=[65228->65536] Apr 20 09:19:02 openvpn[96982]: Attempting to establish TCP connection with [AF_INET]203.169.76.29:1194 [nonblock] Apr 20 09:19:03 openvpn[96982]: TCP connection established with [AF_INET]203.169.76.29:1194 Apr 20 09:19:03 openvpn[96982]: TCPv4_CLIENT link local (bound): [AF_INET]10.85.110.7 Apr 20 09:19:03 openvpn[96982]: TCPv4_CLIENT link remote: [AF_INET]203.169.76.29:1194 Apr 20 09:19:03 openvpn[96982]: TLS: Initial packet from [AF_INET]203.169.76.29:1194, sid=9fd8d700 66b332bc Apr 20 09:19:03 openvpn[96982]: VERIFY OK: depth=1, C=UA, ST=Kyivskaya, L=Kyiv, O=Gidroenergoinvest, emailAddress=itgdr@gmail.com, CN=internal-vpn2-ca Apr 20 09:19:04 openvpn[96982]: VERIFY OK: depth=0, C=UA, ST=Kyivskaya, L=Kyiv, O=Gidroenergoinvest, emailAddress=itgdr@gmail.com, CN=gei.com Apr 20 09:19:05 openvpn[96982]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Apr 20 09:19:05 openvpn[96982]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Apr 20 09:19:05 openvpn[96982]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Apr 20 09:19:05 openvpn[96982]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Apr 20 09:19:05 openvpn[96982]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Apr 20 09:19:05 openvpn[96982]: [gei.com] Peer Connection Initiated with [AF_INET]203.169.76.29:1194 Apr 20 09:19:07 openvpn[96982]: SENT CONTROL [gei.com]: 'PUSH_REQUEST' (status=1) Apr 20 09:19:07 openvpn[96982]: PUSH: Received control message: 'PUSH_REPLY,route 172.21.0.0 255.255.255.0,route 172.21.0.0 255.255.255.0 172.10.0.1,route-gateway 172.10.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 172.10.0.3 255.255.255.0' Apr 20 09:19:07 openvpn[96982]: OPTIONS IMPORT: timers and/or timeouts modified Apr 20 09:19:07 openvpn[96982]: OPTIONS IMPORT: --ifconfig/up options modified Apr 20 09:19:07 openvpn[96982]: OPTIONS IMPORT: route options modified Apr 20 09:19:07 openvpn[96982]: OPTIONS IMPORT: route-related options modified Apr 20 09:19:07 openvpn[96982]: Preserving previous TUN/TAP instance: ovpnc1 Apr 20 09:19:07 openvpn[96982]: Initialization Sequence Completed Apr 20 09:19:12 openvpn[96982]: Connection reset, restarting [0] Apr 20 09:19:12 openvpn[96982]: SIGUSR1[soft,connection-reset] received, process restarting Apr 20 09:19:12 openvpn[96982]: Restart pause, 5 second(s)
Лог с сервера pfSense 2.1.3-RELEASE (i386)
Apr 20 09:19:00 openvpn[38122]: ktsvo.com/186.105.212.244:9355 send_push_reply(): safe_cap=940 Apr 20 09:19:02 openvpn[38122]: TCP connection established with [AF_INET]105.134.224.202:8627 Apr 20 09:19:05 openvpn[38122]: 105.134.224.202:8627 [ ktsvo.com] Peer Connection Initiated with [AF_INET]105.134.224.202:8627 Apr 20 09:19:05 openvpn[38122]: MULTI_sva: pool returned IPv4=172.10.0.3, IPv6=(Not enabled)
-
Эти директивы есть в конфиг. файле клиента ?
keepalive 5 10
ping-timer-rem
persist-tun
persist-keyhttp://tuxnotes.ru/note/1
-
ээээмм…. не знаю.... а где это указывается?.... в Advanced configuration чисто… на сервере только iroute указан в Client Specific Override….
-
Эти директивы есть в конфиг. файле клиента ?
Прочтите еще раз внимательнее где
-
Странная проблема, не могу осилить правила файрволла на pfSense 2.2.1 (x64)
Есть сервер с OpenVPN PKI, есть один удаленный клиент, сеть сервера 192.168.0.0/22, клиента 192.168.20.0/24
Все работает, но с компов за клиентом не пингуется ничего кроме самого сервера (и не только не пингуется, ничего не идет). Если на клиенте отключить файрволл, пинги идут, но это не вариант (клиент торчит во внешку).
в LAN на клиенте есть правила - IPv4 * * * * * * none any to any
в OpenVPN - IPv4 * * * * * * none any to any
Просмотр логов firewall не показывает где идет блокировка (например, пингую с компа из сети клиента свой комп, а ICMP в логах не вижу совсем).
Куда копать? Дело явно в файрволле, т.к. если поставить галку Disable all packet filtering на клиенте - все работает.Добавление правил вида IPv4 * LAN net * 192.168.0.0/22 * * none до правила any to any ситуацию не меняет.
-
2 xl
В кач-ве клиента тоже pfsense ?Директиву iroute в настройках сервера (Client Specific Overrides) с правильным указанием Сommon name Вы для себя уже открыли ?
iroute 192.168.20.0 255.255.255.0;
В настройках сервера есть ли директивы ?
_route 192.168.20.0 255.255.255.0;
push "route 192.168.0.0 255.255.252.0";_
Есть сервер с OpenVPN PKI, есть один удаленный клиент, сеть сервера 192.168.0.0/22, клиента 192.168.20.0/24
IPv4 * LAN net * 192.168.0.0/22 * * none до правила any to any ситуацию не меняет.
Должно быть и на сервере и на клиенте (и в первых рядах правил fw):
IPv4 * LAN net * 192.168.0.0/22 * * none - на клиенте
IPv4 * LAN net * 192.168.20.0/24 * * none - на сервере
P.s. Не хочу показаться
мучудаком и кого-то учить уму разуму, но люди , если Вы уж взялись быть сисадминами, то
вспоминайте элементарные вещи. Я про замечательную команду traceroute \ tracert пытаюсь донести. Она отлично покажет Вам на каком этапе в цепочке прохождения пакетов от точки А до точки Б затык. Пользуйтесь ею! -
Конечно все это сделано, я же написал, если отключить файрволл, то всё во все стороны ходит.
Но, дело было не в файрволле. При отключении файрволла там есть такое:
Disable all packet filtering.
Note: This converts pfSense into a routing only platform!
Note: This will also turn off NAT!
Вот как раз отключение Outbound NAT, в котором криво создались правила, и помогало. Судя по всему какой-то баг в новой версии, переключение режимов из Automatic в Manual и обратно спасло ситуацию.
И кстати, трейс доходил до 10.0.8.1 (что вроде как сервер), а помогало отключение NAT и файрволла на клиенте. Вот чем тут мне трейсроут помог? :) -
Покажите правила в Outbound NAT в режиме автоматическом и ручном на сервере и клиенте.
И правила fw на LAN\WAN\OpenVPN на сервере и клиенте. -
Добрый день!
Прежде всего хочу сказать огромное спасибо rubic за инструкцию! По ней у меня всё работает прекрасно.Есть сервер
WAN = реальный ип адрес
LAN1 = 192.168.21.0/24
LAN2 = 192.168.0.0/24 новаяИ есть клиент
WAN1 = реальный ип адрес №1
WAN2 = реальный ип адрес №2
LAN1 = 192.168.2.0/24Единственное отклонение от инструкции - пришлось в клиенте указать IPv4 Remote Network/s = 192.168.21.0/24
Иначе хосты из сети клиента не могли видеть хосты в сети сервера от чего-то. Может быть из-за версии пфсенса (у меня 2.1.5-RELEASE с обеих сторон). Хотя в обратную сторону работало.И в общем-то всё работало около года без проблем, пока на сервере не появилась новая сетевая карта с сетью 192.168.0.0/24 куда мне нужно обеспечить доступ из сети клиента.
Казалось бы, всё просто.
Изменил на сервере IPv4 Local Network/s = 192.168.21.0/24, 192.168.0.0/24
Изменил на клиенте IPv4 Remote Network/s = 192.168.21.0/24, 192.168.0.0/24На клиенте появился маршрут 192.168.0.0/24 10.0.8.5 UGS 0 0 1500 ovpnc1
Но хосты из сети клиента не хотят по нему ходить! Трасировка показывает, что они пытаются идти через wan сетевую (интернет)!
Хотя трасировка прямо со шлюза показывает что машрут рабочий, и прямо со шлюза хосты в новой сети пингуются!В чем же дело? =(