On Mon, Oct 19, 2020 at 09:46:19AM +0200, Alexandr Nedvedicky wrote: > Hello, > > disclaimer: I have no chance to run pfsync on production, I'm very > inexperienced with pfsync(4).
i wrote the defer code in pfsync, and i think i wrote the code in pfsync that calls pf_route badly, so noones perfect :) > </snip> > > > > the third problem is that pf_route relies on information from rules to > > work correctly. this is a problem in a pfsync environment because you > > cannot have the same ruleset on both firewalls 100% of the time, which > > means you cannot have route-to/reply-to behave consistently on a pair of > > firwalls 100% of the time. > > > > my solution to both these problems is reduce the amount of information > > pf_route needs to work with, to make sure that the info it does need > > is in the pf state structure, and that pfsync handles it properly. > > > > if we limit the information needed for pf_route to a nexthop address, > > and which direction the address is used, this is doable. both the > > pf_state and pfsync_state structs already contain an address to store a > > nexthop in, i just had to move the route-to direction from the rule into > > the state. this is easy with pf_state, but i used a spare pad field in > > pfsync_state for this. > > > > 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 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 142 32768 1 lo0 192.168.0.0 192.168.0.0 UHl 0 0 - 1 gre0 192.168.0.1 192.168.0.0 UHh 1 1 - 8 gre0 192.168.96.32/27 192.168.96.34 UCn 2 122849 - 4 vmx0 192.168.96.33 00:00:5e:00:01:47 UHLch 1 14611 - 3 vmx0 192.168.96.34 00:50:56:a1:73:91 UHLl 0 362231 - 1 vmx0 192.168.96.60 fe:e1:ba:d0:74:ef UHLc 0 59690 - 3 vmx0 192.168.96.63 192.168.96.34 UHb 0 0 - 1 vmx0 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 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 62 32768 1 lo0 192.168.0.2 192.168.0.2 UHl 0 0 - 1 gre0 192.168.0.3 192.168.0.2 UHh 1 1 - 8 gre0 192.168.96.32/27 192.168.96.55 UCn 3 62186 - 4 aggr0 192.168.96.33 00:00:5e:00:01:47 UHLch 1 7442 - 3 aggr0 192.168.96.35 00:23:42:d0:56:8e UHLc 0 1905 - 3 aggr0 192.168.96.55 fe:e1:ba:d0:e0:83 UHLl 0 178119 - 1 aggr0 192.168.96.60 fe:e1:ba:d0:74:ef UHLc 0 31021 - 3 aggr0 192.168.96.63 192.168.96.55 UHb 0 0 - 1 aggr0 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 and > regards > sashan no, thank you for reading my long email. cheers, dlg
