Подключение 3-го узла



  • Уважаемые коллеги.
    Прошу помощи в борьбе с ошибкой маршрутизации.
    Подключаю третий pfS 2.4.1. Соединение через OpenVPN StS. Каналы поднимаются, адреса сетей поступают в таблицу маршрутизации. Ping, запущенный с fw клиента в сеть сервера проходит, запущенный с fw сервера не проходит. Рабочие станции не контактируют в обе стороны. Сервер на рабочем узле, клиент на новом. В приложениях конфигурация соединения.
    var-etc-openvpn-server6_conf.txt
    var-etc-openvpn-csc-server6-Crch_client.txt
    var-etc-openvpn-client3_conf.txt



  • Доброго.
    iroute в VPN / OpenVPN / Client Specific Overrides
    Проверить, что стоит gw в сет. настройках рабстанций.
    На время откл. fw, антивирусы на проверяемых рабстанциях.



  • @werter:

    iroute в VPN / OpenVPN / Client Specific Overrides
    Проверить, что стоит gw в сет. настройках рабстанций.
    На время откл. fw, антивирусы на проверяемых рабстанциях.

    Пожалуйста, загляните в приложенные файлы. Там описание и сервера и CSO и клиента. Просто я уже четвертый день бьюсь, как об стенку. Может со стороны удастся увидеть причину этого безобразия.
    Доступ роверяется на серверах и сетевых принтерах, с собственных они свободно пингуются.



  • Покажите скрины
    System / Certificate Manager / CAs
    System/ Certificate Manager/ Certificates
    VPN / OpenVPN / Client Specific Overrides

    В какой из сетей 192.168.102.0 192.168.103.0 192.168.111.0 192.168.112.0 нах-ся проблемный клиент?

    Попробуйте добавить на ЛАН сервера разреш. правило fw, где укажите в dest удален. сети впн-клиентов и поставьте его выше всех.

    И еще. Я бы перекл. в Firewall / NAT / Outbound  режим Outbound NAT Mode на Hybrid Outbound NAT rule generation. Создал бы явное Mappings на vpn-интерфейсе , в к -ом откл. NAT для локальных сетей впн- клиентов. Для чего ? Чтобы при проблемах (вирусы и т.д) точно знать с какого адреса из лок. сети впн-клиента лезет кака.

    ![2017-11-13 12_12_11.png](/public/imported_attachments/1/2017-11-13 12_12_11.png)
    ![2017-11-13 12_12_11.png_thumb](/public/imported_attachments/1/2017-11-13 12_12_11.png_thumb)



  • @werter:

    И еще. Я бы перекл. в Firewall / NAT / Outbound  режим Outbound NAT Mode на Hybrid Outbound NAT rule generation. Создал бы явное Mappings на vpn-интерфейсе , в к -ом откл. NAT для локальных сетей впн- клиентов. Для чего ? Чтобы при проблемах (вирусы и т.д) точно знать с какого адреса из лок. сети впн-клиента лезет кака.

    Отлично, после отмены NAT ping между файерволами пошел в обе стороны. Но ping c ws не маршрутизируется все равно. В логах файерволов пакеты не фиксируются с обеих сторон.

    Пошли пинги между ws со стороны сервера на ws у клиента. А tracert с ws со стороны клиента показывает, что запрос минуя интерфейс vpn-a уходит в интернет. Разбираюсь.

    Общее правило на интерфейсе заменил на несколько более жестких и все пошло.



  • Следующий этап.
    Нужно замкнуть кольцо соединением “Fw B” и “Fw C”. Сразу вопрос: такая конфигурация возможна?
    Канал между “Fw B” и “Fw C” создается, но проблема почти та же - от клиента к серверу проходит vpn-интерфейсы и исчезает, от сервера к клиенту нет вообще ничего. Словно на сервере прервана связь между vpn и физическими интерфейсами. NAT и правила не помогают. Может есть еще какой-то магический пинок?

    ![pfS connectors.jpg](/public/imported_attachments/1/pfS connectors.jpg)
    ![pfS connectors.jpg_thumb](/public/imported_attachments/1/pfS connectors.jpg_thumb)
    ![Fw C - server.jpg](/public/imported_attachments/1/Fw C - server.jpg)
    ![Fw C - server.jpg_thumb](/public/imported_attachments/1/Fw C - server.jpg_thumb)
    ![Fw C - CSO.jpg](/public/imported_attachments/1/Fw C - CSO.jpg)
    ![Fw C - CSO.jpg_thumb](/public/imported_attachments/1/Fw C - CSO.jpg_thumb)
    ![Routes fwB.jpg](/public/imported_attachments/1/Routes fwB.jpg)
    ![Routes fwB.jpg_thumb](/public/imported_attachments/1/Routes fwB.jpg_thumb)
    ![Routes fwC.jpg](/public/imported_attachments/1/Routes fwC.jpg)
    ![Routes fwC.jpg_thumb](/public/imported_attachments/1/Routes fwC.jpg_thumb)
    ![Ping 1 (Fw B).jpg](/public/imported_attachments/1/Ping 1 (Fw B).jpg)
    ![Ping 1 (Fw B).jpg_thumb](/public/imported_attachments/1/Ping 1 (Fw B).jpg_thumb)
    ![Routes fwC.jpg](/public/imported_attachments/1/Routes fwC.jpg)
    ![Routes fwC.jpg_thumb](/public/imported_attachments/1/Routes fwC.jpg_thumb)



  • Доброго.

    Нужно замкнуть кольцо соединением “Fw B” и “Fw C”. Сразу вопрос: такая конфигурация возможна?

    Для чего? Резервный канал? Точнее ТЗ, пож-та.



  • И еще. Я бы перекл. в Firewall / NAT / Outbound  режим Outbound NAT Mode на Hybrid Outbound NAT rule generation. Создал бы явное Mappings на vpn-интерфейсе , в к -ом откл. NAT для локальных сетей впн- клиентов. Для чего ? Чтобы при проблемах (вирусы и т.д) точно знать с какого адреса из лок. сети впн-клиента лезет кака.

    А вот тут не понял. Несколько Open VPN site-to-site c и Remote access с центральным офисом.  Outbound NAT - hybrid.
    pfSense, естественно , создал Automatic Rule для всех сетей, включая сети Open VPN c трансляцией их в WAN address.

    Создал бы явное Mappings на vpn-интерфейсе , в к -ом откл. NAT для локальных сетей впн- клиентов. Для чего ? Чтобы при проблемах (вирусы и т.д) точно знать с какого адреса из лок. сети впн-клиента лезет кака.

    Такого правила не создавал,  однако через site-to-site из сети в сеть попадаю с локальным адресом ПК из той сети, в которой ПК находится.
    На клиентах site-to-site - тоже никакого NAT.
    RA-клиент, естественно, видится со своим “туннельным” IP.

    Т.е. если я верно понимаю, несмотря на то, что сети Open VPN и NATятся в WAN в , реально их пакеты ходят по  маршрутам согласно таблице маршрутов без попыток заNATить их.



  • ТЗ: сеть из семи файерволов по схеме “каждый с каждым”. На данном начальном участке fw B является точкой запроса медиаконтента и на него переадресуются запросы с клиентов сетей fw A и fw C. Поток очень значительный (ТВ высокой четкости) так что пересылать его через несколько узлов не желательно.



  • @pigbrother:

    Т.е. если я верно понимаю, несмотря на то, что сети Open VPN и NATятся в WAN в , реально их пакеты ходят по  маршрутам согласно таблице маршрутов без попыток заNATить их.

    Видете ли, я тут столкнулся с несколькими неприятными чудЕсами. Соединение первых двух fw работает без всякого NAT. Соединение третьего fw с первым не отрабатывало маршрутизацию правильно до назначения NAT для ОДНОЙ из сетей клиента, но теперь работают все ПЯТЬ. Соединение третьего fw со вторым не отрабатывает маршрутизацию ни с NAT ни без (выше есть скриншоты).
    Если можете, пожалуйста посмотрите приложения к предыдущему сообщению. Может я просто уже не вижу какую-то тривиальную ошибку?



  • В общем, причина ясна - не поключается таблица маршрутизации к серверному интерфейсу OpenVPN. Один только собственный адрес виден. Хотя в общей таблице маршрутизации видны остальные сети клиента. Но что мешает подключению или как его принудить подключать таблицу?

    ![Fw C - error.jpg](/public/imported_attachments/1/Fw C - error.jpg)
    ![Fw C - error.jpg_thumb](/public/imported_attachments/1/Fw C - error.jpg_thumb)
    ![Routes fwC-ovpns2.jpg](/public/imported_attachments/1/Routes fwC-ovpns2.jpg)
    ![Routes fwC-ovpns2.jpg_thumb](/public/imported_attachments/1/Routes fwC-ovpns2.jpg_thumb)



  • @pigbrother:

    pfSense, естественно , создал Automatic Rule для всех сетей, включая сети Open VPN c трансляцией их в WAN address.

    Очень интересно, а у меня pfSence создал правила только для физических интерфейсов, для OpenVPN никаких NAT-правил не было. И переключение с Hibrid на Automatic и обратно ничего не дает. Можно подробнее?



  • @pigbrother:

    Т.е. если я верно понимаю, несмотря на то, что сети Open VPN и NATятся в WAN в , реально их пакеты ходят по  маршрутам согласно таблице маршрутов без попыток заNATить их.

    Локальные адреса сетей натятся в адреса своих концов туннеля, а не WAN.
    А так - нужно проверять. Будет время - отпишу. Может в 2.4.х что-то и изменилось в этом плане.



  • Коллеги, по моему вопросу есть ли какие-нибудь соображения?



  • @MStar:

    @pigbrother:

    pfSense, естественно , создал Automatic Rule для всех сетей, включая сети Open VPN c трансляцией их в WAN address.

    Очень интересно, а у меня pfSence создал правила только для физических интерфейсов, для OpenVPN никаких NAT-правил не было. И переключение с Hibrid на Automatic и обратно ничего не дает. Можно подробнее?

    Давным-давно (еще в 2.1 или даже в 2.0) переключил NAT с автоматического в manual для добавления пара правил NAT. Обновился до 2.3.х. Потом эти правила стали не нужны и были удалены, из manual NAT  переключился в hybrid. В Automatic Rules получил такое:

    WAN	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	500 	WAN address 	* 		Auto created rule for ISAKMP
    WAN 	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	* 	WAN address 	* 		Auto created rule 
    

    a.a.2.0 - LAN,  b.b.100.0/24 - DMZ. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - сети туннелей RA и site-to-site клиентов Open VPN, котрые в интернет через Open VPN не ходят.
    Интерфейсы для Open VPN не создавались.



  • @pigbrother:

    Интерфейсы для Open VPN не создавались.

    Все так. В данном случае NAT - фактор, роли не играющий.
    Поэтому снова повторяю вопрос: что может препятствовать назначению таблицы маршрутизации серверному интерфейсу OpenVPN и/или как можно этот момент отследить и исследовать. Очень нужна помощь специалиста, знающего pfSense на уровне внутренних механизмов.
    Status / System Logs / OpenVPN```

    Nov 15 09:46:12 openvpn 96554 54AG_Crch_client/188.x.x.10:4484 MULTI_sva: pool returned IPv4=192.168.104.10, IPv6=(Not enabled)
    Nov 15 09:46:12 openvpn 96554 188.x.x.10:4484 [54AG_Crch_client] Peer Connection Initiated with [AF_INET]188.x.x.10:4484
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_TCPNL=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_COMP_STUBv2=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_COMP_STUB=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZO=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZ4v2=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZ4=1
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_PROTO=2
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_PLAT=freebsd
    Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_VER=2.4.4
    Nov 15 09:43:04 openvpn 96554 Initialization Sequence Completed
    Nov 15 09:43:04 openvpn 96554 UDPv4 link remote: [AF_UNSPEC]
    Nov 15 09:43:04 openvpn 96554 UDPv4 link local (bound): [AF_INET]89.x.x.70:11941
    Nov 15 09:43:04 openvpn 96554 /usr/local/sbin/ovpn-linkup ovpns2 1500 1621 192.168.104.9 255.255.255.248 init
    Nov 15 09:43:04 openvpn 96554 /sbin/ifconfig ovpns2 192.168.104.9 192.168.104.10 mtu 1500 netmask 255.255.255.248 up
    Nov 15 09:43:04 openvpn 96554 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
    Nov 15 09:43:04 openvpn 96554 TUN/TAP device /dev/tun2 opened
    Nov 15 09:43:04 openvpn 96554 TUN/TAP device ovpns2 exists previously, keep at program end
    Nov 15 09:43:04 openvpn 96554 Initializing OpenSSL support for engine 'rdrand’
    Nov 15 09:43:04 openvpn 96554 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    Nov 15 09:43:04 openvpn 96294 library versions: OpenSSL 1.0.2k-freebsd 26 Jan 2017, LZO 2.10
    Nov 15 09:43:04 openvpn 96294 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 19 2017

    
    netstat -r
    
    | Routing tables |  |  |  |  |
    |  |  |
    | Internet: |  |
    | Destination | Gateway | Flags | Netif | Expire |
    | default | 89.225.253.65 | UGS | igb1 |  |
    | 10.0.10.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 10.0.11.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
    | 10.0.13.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
    | 10.0.14.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
    | 89.225.253.64/28 | link#2 | U | igb1 |  |
    | 89.225.253.70 | link#2 | UHS | lo0 |  |
    | localhost | link#7 | UH | lo0 |  |
    | 172.16.1.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 188.172.154.10.bcu | 89.225.253.65 | UGHS | igb1 |  |
    | 192.168.1.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.2.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.3.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.100.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.101.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.102.0/24 | link#3 | U | igb2 |  |
    | 192.168.102.1 | link#3 | UHS | lo0 |  |
    | 192.168.103.0/24 | link#12 | U | igb2.2 |  |
    | 192.168.103.1 | link#12 | UHS | lo0 |  |
    | 192.168.104.0/29 | 192.168.104.2 | UGS | ovpns1 |  |
    | 192.168.104.1 | link#14 | UHS | lo0 |  |
    | 192.168.104.2 | link#14 | UH | ovpns1 |  |
    | 192.168.104.8/29 | 192.168.104.10 | UGS | ovpns2 |  |
    | 192.168.104.9 | link#15 | UHS | lo0 |  |
    | 192.168.104.10 | link#15 | UH | ovpns2 |  |
    | 192.168.110.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.111.0/24 | link#1 | U | igb0 |  |
    | pfSense-Crch | link#1 | UHS | lo0 |  |
    | 192.168.112.0/24 | link#13 | U | igb2.4 |  |
    | 192.168.112.1 | link#13 | UHS | lo0 |  |
    | 192.168.114.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.125.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.222.0/29 | link#6 | U | igb5 |  |
    | 192.168.222.2 | link#6 | UHS | lo0 |  |
    | 192.168.252.0/28 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.252.72/29 | 192.168.252.73 | UGS | ovpnc3 |  |
    | 192.168.252.73 | link#16 | UH | ovpnc3 |  |
    | 192.168.252.74 | link#16 | UHS | lo0 |  |
    
    | 
    [ [/td] |


  • @pigbrother:

    WAN	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	500 	WAN address 	* 		Auto created rule for ISAKMP
    WAN 	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	* 	WAN address 	* 		Auto created rule 
    

    a.a.2.0 - LAN,  b.b.100.0/24 - DMZ. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - сети туннелей RA и site-to-site клиентов Open VPN, котрые в интернет через Open VPN не ходят.
    Интерфейсы для Open VPN не создавались.

    Явно указано - WAN. Т.е. если завернуть весь трафик от впн-клиентов в туннель, то в инет они будут иметь возможность выходить через головной сервер. Странно.

    Сохранить конфиг. Удалить правила. Проверить.

    Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?  ::)



  • @werter:

    Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?  ::)

    Это вообще не мои сети, это “pigbrother” рассуждал об автосоздаваемых правилах NAT. На своем примере.



  • А я ему и отвечал  ;D



  • @werter:

    А я ему и отвечал  ;D

    Жалко, что мне никто не вожет ответить! :’(



  • Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?

    Не забыл 😉 Адресацию своих LAN вспомню и во сне. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это именно сети, выделенные под туннели.
    10.11.12.0/24 - туннель для site-to-site
    10.11.11.0/24 и 10.11.10.0/24 - туннели двух Remote access OVPN серверов. Зачем  их 2? Один “правильный” на UDP, второй - TCP  для клиентов, чьи провайдеры режут UDP.

    Жалко, что мне никто не может ответить

    Не знаю, что может мешать. Маршрут и шлюз в другую сеть через появляются в таблице сразу после создания экземпляра Open VPN сервера, насколько помню - даже если к серверу никто не подключен.

    Создайте для эксперимента сервер, ведущий в никуда с уникальной адресацией туннеля. Маску туннеля выберите “стандартную” /24.

    И да, у вас в
    var-etc-openvpn-csc-server6-Crch_client.txt
    несколько записей iroute:

    iroute 192.168.102.0 255.255.255.0
    iroute 192.168.103.0 255.255.255.0
    iroute 192.168.111.0 255.255.255.0
    iroute 192.168.112.0 255.255.255.0
    

    За этим клиентом  действительно столько сетей?



  • Правильный ответ на заданный вопрос: Если в таблице маршрутизации VPN соединения на сервере виден только адрес собственного шлюза, значит не подключилась информация из CSO. Наивероянейшая причина - ошибка в написании канонического имени сертификата пользователя.



  • ошибка в написании канонического имени сертификата пользователя.

    Вероятно - Common Name.

    Да, достаточно ошибиться регистром. Ну тут уж  извините - искать такие ошибки исключительно ваша прерогатива.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy