On Mon, Jan 25, 2021 at 05:38:40PM +0100, Alexandr Nedvedicky wrote: > Hello, > > > On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote: > > Hi, > > > > Some personal thoughts. I am happy when pf route-to gets simpler. > > Especially I have never understood what this address@interface > > syntax is used for. > > > > I cannot estimate what configuration is used by our cutomers in > > many installations. Simple syntax change address@interface -> > > address of next hob should be no problem. Slight semantic changes > > have to be dealt with. Current packet flow is complicated and may > > be inspired by old NAT behavior. As long it becomes more sane and > > easier to understand, we should change it. > > > 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? > the 'address@interface' syntax is the only way to define rules: > > pass in on em0 from 172.16.0.0/16 route-to 192.168.1.10@em1 > pass in on em0 from 172.17.0.0/16 route-to 192.168.1.10@em2 > > regardless of how much real such scenario is I believe it can > currently work. this is a very awkward configuration. while i think what it's trying to do is useful, how it is expressed relies on something i want to break (fix?). one of the original reasons i wanted to break this kind of config is because pfsync hasn't got a way to exchange interace information, and different firewalls are going to have different interface topologies anyway. one of the reasons to only use a destination/next hop as the argument to route-to rules was so pfsync would work. i'm pretty sure this is broken at the moment because of bugs in the routing code. it is possible to configure routes to 192.168.1.10 via both em1 and em2 if net.inet.ip.multipath is set to 1, but im sure the llinfo (arp and rtable) part of this kind of multipath route setup does not work reliably. i guess i should try and get my fixes for this into the tree. there are two alternate ways i can think of to do this. the first is to configure an rtable for each interface: # route -T 1 add default 192.168.1.10 -ifp em1 # route -T 2 add default 192.168.1.10 -ifp em2 then you could write rules like this: pass in on em0 from 172.16.0.0/16 rtable 1 pass in on em0 from 172.17.0.0/16 rtable 2 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 this will likely hit the same bugs in the rtable/arp code i referred to above though. also, note that i haven't tested either of these. cheers, dlg
