On 2021/01/26 09:29, Alexandr Nedvedicky wrote:
> Hello,
>
> </snip>
> > >
> > >
> > > I'm not sure if proposed scenario real. Let's assume there
> > > is a PF box with three NICs running on this awkward set up
> > >
> > > em1 ... 192.168.1.10
> > >
> > > em0
> > >
> > > em2 ... 192.168.1.10
> > >
> > > em0 is attached to LAN em1 and em2 are facing to internet which is
> > > reachable with two different physical lines. both lines are connected
> > > via
> > > equipment, which uses fixed IP address 192.168.1.10 and PF admin has
> > > no way to change that.
> >
> > in this scenario are em1 and em2 connected to the same ethernet
> > segment and ip subnet?
>
> em1 and em2 are connected to different wires (broadcast domains).
>
> and I agree this set up is really awkward. not sure if it will work
> because it also depends on how ARP table is organized. I think it
> works on Solaris, but I have not tried that with OpenBSD.
I don't know about ethernet/ARP, but that does work with pppoe.
FWIW this is how I was doing things. (I'm not doing this any more)
PRIO_LINES="81.187.8.161@pppoe4 81.187.218.235@pppoe5"
PRIO_LINES_V6="fe80::@pppoe4 fe80::@pppoe5"
..
pass in log quick on {lan, wifi} proto udp to 193.35.128.0/20 port {500, 4500}
tag uma-orange route-to {$PRIO_LINES}
pass in log quick on {lan, wifi} proto {esp, ah} to 193.35.128.0/20 tag
uma-orange route-to {$PRIO_LINES}
pass out log quick on aaisp tagged uma-orange nat-to 81.187.41.148/30 random
sticky-address static-port
pass in quick inet proto {tcp,udp} from {(self), 10.71.12.5, 192.168.10.5} to
!10/8 \
port domain tag priority-dns route-to {$PRIO_LINES}
pass in quick inet6 proto {tcp,udp} from {(self), 2001:8b0:6412:11::5} to
!2001:8b0:6412::/48 \
port domain tag priority-dns route-to {$PRIO_LINES_V6}
pass out on aaisp tagged priority-dns
..
In these I used the "my side" address on the pppoe interfaces because
the "ISP side" address was always 81.187.81.187. AFAIK PF didn't care
about the actual address when it was point-to-point and just a dummy
address worked. (Same with the standard route table too, but that
got changed, I think maybe with ART).
> > the other is to add add routes "beyond" 192.168.1.10 and route-to
> > them:
> >
> > # route add 127.0.1.10 192.168.1.10 -ifp em1
> > # route add 127.0.2.10 192.168.1.10 -ifp em2
> >
> > then you can write rules like this:
> >
> > pass in on em0 from 172.16.0.0/16 route-to 127.0.1.10
> > pass in on em0 from 172.17.0.0/16 route-to 127.0.2.10
That sounds like a usable hack. Maybe even better than before (this
route should go down with the interface, so the traffic wouldn't
end up blackholed like it did with route-to ip@iface).
I think that's easier to deal with than rtables if you have incoming
traffic to services running on the router itself.
> yes I understand that. I'm not able to judge how many currently working
> configurations will remain broken after we kill 'address@interface' form.
> I'm sure many deployments will get fixed with simple tweak:
> echo 'address@interface'|cut -d @ -f 1
standard ethernet: address@em0 -> address
ppp, different isps: address@pppoe0 -> (pppoe0:peer)
ppp with same isps, or
conflicting ethernet: rtable or "routes beyond" hack
dhcp, rtadv: ETOOHARD, don't think it worked before without
scripted pf.conf changes anyway. use rtable.
