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

MStar

И еще. Я бы перекл. в 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 уходит в интернет. Разбираюсь.

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

MStar

Следующий этап.
Нужно замкнуть кольцо соединением "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)

werter

Доброго.

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

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

pigbrother

И еще. Я бы перекл. в 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ить их.

MStar

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

MStar

@pigbrother:

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

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

MStar

В общем, причина ясна - не поключается таблица маршрутизации к серверному интерфейсу 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)

MStar

@pigbrother:

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

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

werter

@pigbrother:

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

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

MStar

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

pigbrother

@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 не создавались.

MStar

@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] |

werter

@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 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ? ::)

MStar

@werter:

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

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

werter

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

MStar

@werter:

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

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

pigbrother

Зы. А может 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

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

MStar

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

pigbrother

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

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

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