When using FreeBSD as a loadbalancer with route-to pf rules redirecting traffic to machines behind the loadbalancer and public addresses assigned on carp interface and it is impossible to use synproxy.
As far as I understand the code, proxied packets to the target server are sent using normal routing table lookup which ends up with sending them on lo0 or carp (the public one, as it has the public address configured) interface.
Fix: A known workaround is to provide a second pf rule on lo or carp interface to do synproxy and loadbalancing again. But this solution requires a double (or tripple, when including carp interface) amount of pf rules.
The attached patch modifies the following things:
- Adds an additional route* route_to_ro parameter to pf_send_tcp which is then passed to ip_output.
- Inside pf_test_state_tcp if a synproxy-related packet is about to be sent behind the loadbalancer, create a route structure and fill it with loadbalancing information stored in the state.
The patch has a status of "works for me" and was not yet tested on heavy traffic.
Patch attached with submission follows:
How-To-Repeat: Use synproxy with route-to, outgoing packetes appear on lo0 or carp interfaces instead of the one provided in route-to pf rule.
Over to maintainer(s).
Created attachment 145230 [details]
Fix synproxy operation for route-to targets for IPv4 and IPv6
The patch introduces the following changes:
- New functions pf_rebuild_route and pf_rebuild_route6 create a minimal route struct which can be passed to ip_output or ip6_output if state already contains loadbalancing information.
- Allocate pfse with M_ZERO to have zeroed pfse's route structs.
- Check m for M_SKIP_FIREWALL in pf_test6(), this fixes bug 127920.
- Introduce new route flag RT_PFROUTE, check for this flag before touching routes' counters as routes in pfse are not really allocated as routes should be.
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.