Reply-to option in firewall rule
I am trying to configure network scenario with multiple path to LAN network (with public IP addresses). I need to put the "reply-to" option into my firewall rules to routing the outcoming traffic back to internal router correctly. Unfortunately there is no way how to do this in PfSense GUI.
Suggested fix: Add "Reply Gateway" (or something like that) into "Advanced Features" section in a firewall rule. It should work similarly to "Gateway" feature which creates "route-to" option except the "reply-to" option is placed in the rule.
#2 Updated by Miroslav Novotný over 5 years ago
- File Drawing1.png added
It should be more clear from the attached picture.
The network 126.96.36.199/26 should be reachable from the Internet and both routers (10.0.0.6 and 10.0.0.13) should work in a failover mode.
There is no problem with incoming connection to 188.8.131.52/26 network. I have created the Gateway Groups (10.0.0.6 and 10.0.0.13) and the firewall rule on the uplink interface matching with packets with the destination in 184.108.40.206/26 with the gateway option set on this Gateway group. It's work as expected.
But, if some host in the 220.127.116.11/26 network initializes connection to the Internet, the reply packets are not routed to the live member of the Gateway Groups. After some research I've came up with the solution. I have created the firewall rule on the internal interface matching with packets with the source in 18.104.22.168/26 network and destination in the Internet with the reply-to option set on one of the gateway.
It's work. Unfortunately this cannot be set in the PfSense GUI and I lost the Failover functionality provided by Gateway Groups.
#3 Updated by Jeremiejig . about 1 year ago
I'm also interested in this feature, for another use.
I need this feature to allow sslh (https://github.com/yrutschle/sslh#transparent-proxy-support) to spoof the src address for transparent proxying.
For that to work correctly I need to put a
reply-to $GWsslh_server to get back the traffic to sslh.
For now I use the Anchor
userrules to add this rules:
pass in quick log on $ZONE_WITH_SSLH reply-to ( vtnet1_vlan21 $sslh_server ) inet proto tcp from any to $openvpnserver port 1194 tracker 40002001 flags S/SA keep state label "USER_RULE: sslproxy openvpn"
pass in quick log on $ZONE_WITH_SSLH reply-to ( vtnet1_vlan21 $sslh_server ) inet proto tcp from any to $https_server1 port 443 tracker 40002002 flags S/SA keep state label "USER_RULE: sslproxy web server 1"
pass in quick log on $ZONE_WITH_SSLH reply-to ( vtnet1_vlan21 $sslh_server ) inet proto tcp from any to $https_server2 port 443 tracker 40002003 flags S/SA keep state label "USER_RULE: sslproxy web server 2"
I didn't get this scenario to work with route-to, as I didn't get to match any rules with SA tcp packet.
Also the reply-to method seems more proper (only one rules instead of a pair of two with route-to `if it works`)