Source based routing

очевидно форварднуть пакет проматчив его, а там и NAT отработает. вот уже запамятовал есть-ли в pf fwd

очевидно форварднуть пакет проматчив его, а там и NAT отработает. вот уже запамятовал есть-ли в pf fwd

Правило с route-to это и должно делать, разве нет?

х.з. вроде должно. Извини не разглядел route-to, попробуй nat on $vpn_if inet from any to any -> $vpn_if если основной маршрут не бросает пакеты на этот интерфейс, хотя откуда тут ноги растут непонятно, с первого взгляда вроде всё правильно

попробуй nat on $vpn_if inet from any to any -> $vpn_if

Нет, всё равно пакеты уходят в re0 на default_gw.

P.S. Сам nat не причём. Проблема именно с роутингом. Если я пропишу маршрут к какому-нибудь хосту через tun0 руками, то пакеты к нему из vlan_if идут как надо.

Вот это немного смущает

nat on $vpn_if inet from $vlan_if:network to any -> $vpn_if

Там же должен быть адрес с которого натить, а не интерфейс. Может $vpn_if нужно в скобках?

nat on $vpn_if inet from $vlan_if:network to any -> ($vpn_if)

Это никак не влияет. Ещё раз, проблема с route-to. Nat нормально отрабатывает, если руками прописать маршрут.

Может как-то криво разворачивает макросы? Пробовал руками дать адрес вместо $vpn_if:peer например? На OpenBSD практически такие же правила (только не на туннельных интерфейсах и с адресами вручную) отрабатывают как надо. Вот прямо скопипастил из живого конфига

nat on $ext_if from (vlan25:network) -> a.b.c.d
...
pass in on vlan25 route-to ($ext_if e.f.g.h) from (vlan25:network) to {!192.168.0.0/16} keep state

Нет, руками развернуть макросы не помогло.

nat on $vpn_if inet from $vlan_if:network to any -> A.A.B.C
pass in on $vlan_if route-to ($vpn_if A.A.B.B) inet from ($vlan_if:network) keep state

Даже в этом случае результат тот же.

Приведи вывод применения правил. Там будет видно, что $vpn_if не раскрылся.

Непонятно. Может быть общее пропускающее правило нужно поставить перед правилом с route-to? У pf такая фича - last rule wins

Я руками раскрывал вообще все макросы. Пофигу.

Oook

пример из рабочего конфига:

ext_if_a = "xl0"
ext_gw_a = "a.a.a.a"

ext_if_b = "fxp1"
ext_gw_b = "b.b.b.b"

ext_if_c = "fxp2"

int_if   = "fxp0"

match out on $ext_if_a inet proto tcp from <src1> to !<src1> nat-to $ext_if_a
match out on $ext_if_b inet from { <src1>, <src2> } to !<src1> nat-to $ext_if_b

pass in on $int_if inet proto tcp from <mail> to any port { www, smtp, https, smtps } route-to ($ext_if_a $ext_gw_a)
pass in on $int_if inet proto { tcp, udp } from <kl-bank> to any port !=25 route-to ($ext_if_b $ext_gw_b)

pass out inet from $ext_if_a route-to ($ext_if_a $ext_gw_a)
pass out inet from $ext_if_b route-to ($ext_if_b $ext_gw_b)
pass out on { $ext_if_a, $ext_if_b }

Это OpenBSD? В FreeBSD немножко старый PF, и другой синтаксис правил. В частности, nat-to не поддерживается, вроде как.

а где ман для фришного пф?

https://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5

Например.

вместо match out используйте свое текущее правило:

nat on $vpn_if inet from $vlan_if:network to any -> $vpn_if

pass in quick on либо правила местами поменять, подсказали же уже

Поменял местами и добавил to !self в правило с route-to. Теперь пакеты вообще никуда не уходят. Кроме того, система перестала отвечать на пинги на $vlan_if и вообще дропает все приходящие пакеты. pass in quick даёт тот же эффект.

Правила выглядят теперь вот так:

nat on $vpn_if inet from $vlan_if:network to any -> ($vpn_if)
pass from { lo0, $lan_if:network, $vlan_if:network } to any keep state
pass in on $vlan_if route-to ($vpn_if $vpn_if:peer) inet from ($vlan_if:network) to !self keep state

Честно говоря, я нифига не понимаю почему так происходит. Мб я какой-то флаг где-то должен включить? Помимо ip.forwarding.

Если же убрать разрешающее правило (pass from { lo0, $lan_if:network, $vlan_if:network } to any keep state), то пакеты вообще никуда не роутятся.

Может во FreeBSD есть какие-то особенности? В OpenBSD в sysctl.conf вижу только «net.inet.ip.forwarding=1»

Натыкай ему протоколирования (pass log), он в выводе tcpdump -n -e -i pflog0 должен показать правило по которому пропускает (или блокирует) пакеты

Хотя, возможно, дело не в pf а в OpenVPN? Он добавляет маршрут после подключения?

Лог:

20:33:54.738183 rule 8..16777216/0(match): pass in on re0.12: 172.16.12.7 > 8.8.8.8: ICMP echo request, id 16099, seq 1, length 64

Правило 8 из pfstat -s rules:

pass in log on re0.12 route-to ( [SKIPPED]) inet from (re0.12:network) to ! 172.16.12.1 flags S/SA keep state

Всё вроде как верно.

У меня в конфиге OpenVPN стоит routes-nopull, чтобы он не менял default gateway для всей системы. В netstat -r маршрут к пиру присутствует.

И дальше никуда не идет? На tun-интерфейсе ничего не появляется?

Вот вроде бы похожий случай: http://daemonforums.org/showthread.php?t=6713

Пишут разное, «Using route-to with a tun device in „dev-type tap“ mode does not work. Probably a bug i think.» например.

В итоге у него получилось, что-то там подкрутил с маршрутами

И дальше никуда не идет? На tun-интерфейсе ничего не появляется?

Именно.

Вот вроде бы похожий случай: http://daemonforums.org/showthread.php?t=6713

Да, у него такая же конфигурация, но на OpenBSD. И у него проблема решилась добавлением шлюза, что у меня было изначально.

Вот что бывает, когда не хватает базовых знаний, не читают мануал, ищут решение методом гугляжа.

Какой мануал кроме man pf.conf, который я уже прочитал, мне нужен?

У вас в конфиге, кроме этих 3-х правил, еще что нибудь есть? Полный конфиг приведите.

Нет. Полный конфиг в изначальном посте. Потом я только последние два правила местами поменял.

Это очень странно вообще-то, так как pf по умолчанию пропускает все, что не попало под действие правил. Вывод: косяк в правиле route-to. Когда оно реально начинает действовать, весь трафик перестает ходить. Разверните все макросы, не прячьте серые адреса. Какая топология OpenVPN (p2p, net30, subnet)? Тот ли IP peer? Вот сгенерированный pfSense рабочий набор правил под вашу задачу (см. последнее):

nat on em0 inet from <nPRIVATE> to any -> A.B.C.158 port 1024:65535
nat on ovpnc4 inet from <nPRIVATE> to any -> 10.211.1.37 port 1024:65535

block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"

block drop in log on ! em0 inet from A.B.C.0/24 to any
block drop in log inet from A.B.C.158 to any
block drop in log on ! ovpnc4 inet from 10.211.1.37 to any
block drop in log inet from 10.211.1.37 to any

pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"

pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
pass out route-to (em0 A.B.C.1) inet from A.B.C.158 to ! A.B.C.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass out route-to (ovpnc4 10.211.1.38) inet from 10.211.1.37 to ! 10.211.1.37 flags S/SA keep state allow-opts label "let out anything from firewall host itself"

pass in quick on em1 route-to (ovpnc4 10.211.1.38) inet from 192.168.11.0/24 to any flags S/SA keep state label "USER_RULE"

Здесь сетевой экран реализует политику 'default deny', потому необходимо не только впустить трафик, но выпустить его специальным правилом «let out anything from firewall host itself».