The pfSense Store

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MStar

Pages: [1] 2
1
Russian / Re: Подключение 3-го узла
« on: November 26, 2017, 01:03:09 pm »
Правильный ответ на заданный вопрос: Если в таблице маршрутизации VPN соединения на сервере виден только адрес собственного шлюза, значит не подключилась информация из CSO. Наивероянейшая причина - ошибка в написании канонического имени сертификата пользователя.

2
Russian / Re: Подключение 3-го узла
« on: November 15, 2017, 07:20:48 am »
А я ему и отвечал  ;D
Жалко, что мне никто не вожет ответить! :'(

3
Russian / Re: Подключение 3-го узла
« on: November 15, 2017, 06:55:02 am »
Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?  ::)
Это вообще не мои сети, это "pigbrother" рассуждал об автосоздаваемых правилах NAT. На своем примере.

4
Russian / Re: Подключение 3-го узла
« on: November 15, 2017, 02:39:20 am »
Интерфейсы для Open VPN не создавались.
Все так. В данном случае NAT - фактор, роли не играющий.
Поэтому снова повторяю вопрос: что может препятствовать назначению таблицы маршрутизации серверному интерфейсу OpenVPN и/или как можно этот момент отследить и исследовать. Очень нужна помощь специалиста, знающего pfSense на уровне внутренних механизмов.
Status / System Logs / OpenVPN
Code: [Select]
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:
DestinationGatewayFlagsNetifExpire
default89.225.253.65UGSigb1
10.0.10.0/24192.168.252.73UGSovpnc3
10.0.11.0/24192.168.104.10UGSovpns2
10.0.13.0/24192.168.104.10UGSovpns2
10.0.14.0/24192.168.104.10UGSovpns2
89.225.253.64/28link#2Uigb1
89.225.253.70link#2UHSlo0
localhostlink#7UHlo0
172.16.1.0/24192.168.252.73UGSovpnc3
188.172.154.10.bcu89.225.253.65UGHSigb1
192.168.1.0/24192.168.252.73UGSovpnc3
192.168.2.0/24192.168.252.73UGSovpnc3
192.168.3.0/24192.168.252.73UGSovpnc3
192.168.100.0/24192.168.252.73UGSovpnc3
192.168.101.0/24192.168.252.73UGSovpnc3
192.168.102.0/24link#3Uigb2
192.168.102.1link#3UHSlo0
192.168.103.0/24link#12Uigb2.2
192.168.103.1link#12UHSlo0
192.168.104.0/29192.168.104.2UGSovpns1
192.168.104.1link#14UHSlo0
192.168.104.2link#14UHovpns1
192.168.104.8/29192.168.104.10UGSovpns2
192.168.104.9link#15UHSlo0
192.168.104.10link#15UHovpns2
192.168.110.0/24192.168.252.73UGSovpnc3
192.168.111.0/24link#1Uigb0
pfSense-Crchlink#1UHSlo0
192.168.112.0/24link#13Uigb2.4
192.168.112.1link#13UHSlo0
192.168.114.0/24192.168.252.73UGSovpnc3
192.168.125.0/24192.168.252.73UGSovpnc3
192.168.222.0/29link#6Uigb5
192.168.222.2link#6UHSlo0
192.168.252.0/28192.168.252.73UGSovpnc3
192.168.252.72/29192.168.252.73UGSovpnc3
192.168.252.73link#16UHovpnc3
192.168.252.74link#16UHSlo0
[

5
Russian / Re: Подключение 3-го узла
« on: November 14, 2017, 11:12:55 am »
Коллеги, по моему вопросу есть ли какие-нибудь соображения?

6
Russian / Re: Подключение 3-го узла
« on: November 14, 2017, 07:53:03 am »
pfSense, естественно , создал Automatic Rule для всех сетей, включая сети Open VPN c трансляцией их в WAN address.

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

7
Russian / Re: Подключение 3-го узла
« on: November 14, 2017, 06:32:23 am »
В общем, причина ясна - не поключается таблица маршрутизации к серверному интерфейсу OpenVPN. Один только собственный адрес виден. Хотя в общей таблице маршрутизации видны остальные сети клиента. Но что мешает подключению или как его принудить подключать таблицу?

8
Russian / Re: Подключение 3-го узла
« on: November 14, 2017, 02:49:01 am »
Т.е. если я верно понимаю, несмотря на то, что сети Open VPN и NATятся в WAN в , реально их пакеты ходят по  маршрутам согласно таблице маршрутов без попыток заNATить их.

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

9
Russian / Re: Подключение 3-го узла
« on: November 14, 2017, 02:30:12 am »
ТЗ: сеть из семи файерволов по схеме "каждый с каждым". На данном начальном участке fw B является точкой запроса медиаконтента и на него переадресуются запросы с клиентов сетей fw A и fw C. Поток очень значительный (ТВ высокой четкости) так что пересылать его через несколько узлов не желательно.

10
Russian / Re: Подключение 3-го узла
« on: November 13, 2017, 01:00:49 pm »
Следующий этап.
Нужно замкнуть кольцо соединением "Fw B" и "Fw C". Сразу вопрос: такая конфигурация возможна?
Канал между "Fw B" и "Fw C" создается, но проблема почти та же - от клиента к серверу проходит vpn-интерфейсы и исчезает, от сервера к клиенту нет вообще ничего. Словно на сервере прервана связь между vpn и физическими интерфейсами. NAT и правила не помогают. Может есть еще какой-то магический пинок?

11
Russian / Re: Подключение 3-го узла
« on: November 13, 2017, 04:47:41 am »
И еще. Я бы перекл. в 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 уходит в интернет. Разбираюсь.

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

12
Russian / Re: Подключение 3-го узла
« on: November 13, 2017, 02:39:03 am »
iroute в VPN / OpenVPN / Client Specific Overrides
Проверить, что стоит gw в сет. настройках рабстанций.
На время откл. fw, антивирусы на проверяемых рабстанциях.
Пожалуйста, загляните в приложенные файлы. Там описание и сервера и CSO и клиента. Просто я уже четвертый день бьюсь, как об стенку. Может со стороны удастся увидеть причину этого безобразия.
Доступ роверяется на серверах и сетевых принтерах, с собственных они свободно пингуются.

13
Russian / Подключение 3-го узла
« on: November 12, 2017, 03:43:24 pm »
Уважаемые коллеги.
Прошу помощи в борьбе с ошибкой маршрутизации.
Подключаю третий pfS 2.4.1. Соединение через OpenVPN StS. Каналы поднимаются, адреса сетей поступают в таблицу маршрутизации. Ping, запущенный с fw клиента в сеть сервера проходит, запущенный с fw сервера не проходит. Рабочие станции не контактируют в обе стороны. Сервер на рабочем узле, клиент на новом. В приложениях конфигурация соединения.

14
Проще. Но это не дает понимания чем отличаются команды
route 192.168.1.0 255.255.255.0
и
push "route 192.168.1.0 255.255.255.0"

Правильно ли я понимаю, что "push" это дополнительные команды удаленному клиенту для конфигурирования маршрутизации через канал?

15
Отлично. Большое спасибо!

Как я понял, в конфигурации сервера должна быть использована команда "route 178.62.9.0 255.255.255.0", а для CSC команда "iroute 178.62.9.0 255.255.255.0".
Вопрос: в поле записи команд должны ли они предваряться командой PUSH?

Pages: [1] 2