On Mon, Oct 19, 2020 at 12:28:19PM +0200, Alexandr Nedvedicky wrote: > Hello, > > </snip> > > > > > > it seems to me 'route-to vs. pfsync' still needs more thought. the > > > next-hop IP address in route-to may be different for each PF box > > > linked by pfsync(4). To be honest I have no answer to address this > > > issue at the moment. > > > > i have thought about that a little bit. we could play with what the > > argument to route-to means. rather than requiring it to be a directly > > connected host/gateway address, we could interpret it as a destination > > address, and use the gateway for that destination as the nexthop. > > > > eg, if i have the following routing table on frontend a: > > > > Internet: > > Destination Gateway Flags Refs Use Mtu Prio > > Iface > > default 192.168.96.33 UGS 6 176171 - 8 > > vmx0 > > 224/4 127.0.0.1 URS 0 0 32768 8 lo0 > > > > 10.0.0.0/30 192.168.0.1 UGS 0 0 - 8 > > gre0 > </snip> > > > > and this routing table on frontend b: > > > > Internet: > > Destination Gateway Flags Refs Use Mtu Prio > > Iface > > default 192.168.96.33 UGS 9 87548 - 8 > > aggr0 > > 224/4 127.0.0.1 URS 0 0 32768 8 lo0 > > > > 10.0.0.0/30 192.168.0.3 UGS 0 0 - 8 > > gre0 > </snip> > > > > if gre0 on both frontends pointed at different legs on the same backend > > server, i could write a pf rule like this: > > > > pass out to port 80 route-to 10.0.0.1 > > > > 10.0.0.1 would then end up as the rt_addr field in pf_state and > > pfsync_state. > > > > both frontend a and b would lookup the route to 10.0.0.1, and then > > use 192.168.0.1 and 192.168.0.3 as the gateway address respectively. > > both would end up pushing the packet over their gre link to the > > same backend. the same semantic would work if the link to the backend > > was over ethernet instead of a tunnel. > > > > > > thoughts? > > > > > > > > > > What you've said makes sense. However I still feel pfsync(4) > > > does not play well with route-to. > > > > maybe your opinion is different if the above makes sense? > > > > Thanks for detailed explanation. This is good enough to make me happy. > The remaining questions on this are sort of 'homework for me' to poke > to PF source code, for example: > are we doing route look up for every packet? or route look up > is performed when state is created/imported? (and we cache > outbound interface + next-hop along the state)
the "destination" address is determined when the state is created and stored in rt_addr if pf_state. the route lookup using that address is done per packet in pf_route. > also what happens when route does not exist on pfsync peer, which > receives state? How admin will discover state failed to import? the route lookup or interface lookup fails and the packet is dropped. there are no counters to show this is happening though :( > Anyway, your plan above looks solid to me now. It's certainly more > flexible > (?reliable?) to select route to particular destination, than using pair of > interface,next-hop. cool, i'll keep working on it then. > > thanks and > regards > sashan
