PfSense для средней сети и настройка правил.

pigbrother

то сети OpenVPN клиентов попадают в таблицу лишь тогда, когда они перечисленны через >запятую в поле "Remote networks" OpenVPN сервера,
1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?
2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>

rubic

@pigbrother:

1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?

Да. Ведь Remote Access - это по определению для одиночных клиентов, за которыми нет сетей. Можно конечно добиться, чтобы и с сетями работало, но если клиент позволяет подключиться в режиме Peer tо Peer SSL/TLS, то зачем?

2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>

Не знаю, нужно пробовать. По мне так проще руками сделать аналог negate rule чем надеяться на этот скрытый механизм, который еще и меняется в самый неудобный момент.

pigbrother

По мне так проще руками сделать аналог negate rule чем надеяться на этот скрытый механизм, который еще и меняется в самый неудобный момент.

Да, изменения произошли внезапно, но хуже, что при обновлении настройки не переносятся из Advanced configuration в Remote networks.

Прочитал :) комментарии к настройке поля Remote networks. Они честно отличаются:

Для 2.0.х

This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

Для 2.1.2:
These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

Если можно - подробнее про самостоятельное создание аналога negate rule.

По поводу negate_networks> на клиентах. Проверил на 2.1.2
В tmp/rules.debug
table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

rubic

@pigbrother:

Прочитал :) комментарии к настройке поля Remote networks. Они честно отличаются:

Для 2.0.х

This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

Для 2.1.2:
These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

Таким образом, теперь нет необходимости прописывать "route…" в Advanced configuration, все сети можно прописать в IPv4 Remote Network/s. То же самое с "push route" - все локальные для сервера сети можно прописать в IPv4 Local Network/s.

Если можно - подробнее про самостоятельное создание аналога negate rule.

Обратите внимание на следующее: любое policy based routing (PBR) правило направляет трафик в обход системной таблицы маршрутизации, т.е. на этот трафик системные маршруты не действуют, даже если они есть (pf routing: https://forum.pfsense.org/index.php?topic=73670.0). Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default. Это именно то, что и делают скрытые negate rules - перед каждым PBR правилом разрешают трафик из всех подключенных сетей во все подключенные сети. Очевидно, разработчики пришли к выводу, что это медвежья услуга - лучше, чтобы оператор сам контролировал кого куда пускать.

По поводу negate_networks> на клиентах. Проверил на 2.1.2
В tmp/rules.debug
table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

WY6EPT

я бы посоветовал переназначить порт управления роутером и выключить автоматический редирект в админку. искать специально будут долго.

а так же как уже выше описали при использовании атрибута Gateway в правиле сети можно исключить попадание клиента в любую сеть кроме внешней.

так же можно заготовить правило для копирования и просто переносить копию на вновь появившийся интерфейс. для запрета доступа к локальному интерфейсу шлюза.
допустим прописать его таким образом
reject
интерфейс клиента
протокол any
сурс эни
дест интерфейс_адресс

а в портах прописать алиас портов которые хочется прикрыть 22 80 443 и тд
днс в таком случае будет ходить

pigbrother

Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default

То есть то самое правило вида:
IPv4 * LAN net * remote_network/24 * * none
Так?

А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

Создал fake-клиента с такими настройками:

dev ovpnc1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.126.128
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote 1.2.3.4 1194
ifconfig 10.0.22.2 10.0.22.1
route 10.0.0.10 255.255.255.0
ca /var/etc/openvpn/client1.ca 
cert /var/etc/openvpn/client1.cert 
key /var/etc/openvpn/client1.key 
tls-auth /var/etc/openvpn/client1.tls-auth 1

и в tmp/rules.debug

записи появились:

table <vpn_networks>{ 10.0.0.10/24 10.0.22.0/24 }
table <negate_networks>{ 10.0.0.10/24 10.0.22.0/24 }

Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?</negate_networks></vpn_networks>

werter

Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

В чем проблема проверить?
Варианты :

1. Не указывать. В настройках сервера прописать директиву push "route x.x.x.x y.y.y.y vpn_gateway"; и route … .На клиенте же можно добавить директиву pull (а можно и не добавлять)
2. В настройках сервера не указывать директиву push …, только route. В настройках клиента прописать директиву route x.x.x.x y.y.y.y vpn_gateway;
3. Заполнить поле Remote Network/s на клиенте и route ... на сервере.

Это основные вар-ты. Существуют еще и подверсии этих же.

P.s. @ pigbrother

Какой-то Вы нерешительный, что ли. С одним несчастным ОпенВПН-ом разбираетесь хз сколько времени. Уже давно бы все попробовали и выяснили что для вас подходит\работает.
Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.

rubic

@pigbrother:

Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

Не и на клиенте, а только на клиенте, если negate_networks вам так дороги)

pigbrother

@werter
Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.

Показалось, что тема negate в деталях интересна не только мне. Если этим отвлек\напряг вас - не обессудьте, старею, наверное.

werter

@ pigbrother

Пардоньте и вы меня, но вот сложилось такое впечатление.
P.s. "Не ошибается тот , кто ничего не делает"(с)

Rearden

Коллеги, приветствую!
Ограничил доступ к ssh,http как показано на скриншоте. На самом деле всё просто - первым правилом разрешается пинговать шлюз, следующим правилом разрешается доступ к локальным ресурсам (на тестовом роутере сделано from $net to $servers any, в идеале надо сделать доступ только к определенным портам, Например from $net to $server 80,25 etc.). Третьим правилом разрешается "выход в интернет" но кроме $local_networks в чей диаппазон и входит адрес конкретного маршрутизатора.

На данный момент полет нормальный. 18 VLAN'ов. States в среднем 10k (в данный момент 7% (6461/98000)).
За 37 дней аптайма был следующий глюк - сервер перестал пускать на вэб-интрефейс. Проблема решилась удалением php-sockets из /tmp и рестартом webconfigurator.

Далее есть непонятка с NetFlow. Сейчас работает softflowd. На самом деле не понятно как работает, ибо в том VLANe на который он натравлен крайне мало netflow трафика (несколько пакетов в 5 минут), соответственно в биллинге не обновляется информация о трафике. Пробовал pfflowd, он генерит больше трафика, но постоянно падает. Так что вопрос о netflow остается открытым. На продакшене сейчас работает через ngctl и правило ipfw add ngtee 5 ip from any to any in.

1.png_thumb

werter

https://forum.pfsense.org/index.php?topic=78224.30

И да, по первому правилу (сверху вниз) - fw разрешает\запрещает трафик только ко внешним сетям. У вас же правило, к-ое пытается обработать трафик в одной с pfsense сети.
Толку от него - нуль.

Поправьте (или проверьте) , если я не прав.

Rearden

werter, смотрите:
Первое правило - это разрешение пинговать шлюз (Proto ICMP)
Второе правило - разрешение трафика до серверов
Третье правило - выход в инет

werter

@Rearden:

werter, смотрите:
Первое правило - это разрешение пинговать шлюз (Proto ICMP)
Второе правило - разрешение трафика до серверов
Третье правило - выход в инет

Как работают правила - я в курсе . Еще с первых версий m0n0wall-а.

И да, по первому правилу (сверху вниз) - fw разрешает\запрещает трафик только ко внешним сетям. У вас же правило, к-ое пытается обработать трафик в одной с pfsense сети. Толку от него - нуль.

Проверили это ?

Rearden

Проверили это ?

Не понимаю, что Вы имеете ввиду.

werter

Отключите\удалите то правило и проверьте будет ли пинг.

Rearden

не пингует без него.