Feature #2676
open
Reply-to option in firewall rule
Added by Miroslav Novotný over 11 years ago.
Updated 3 months ago.
Description
Hello,
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.
Thx,
Mirek
Files
Can you describe this more since its a bit of strange unless you have not the same subnet on multiple cards.
It should be more clear from the attached picture.
The network 1.1.1.0/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 1.1.1.0/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 1.1.1.0/26 with the gateway option set on this Gateway group. It's work as expected.
But, if some host in the 1.1.1.0/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 1.1.1.0/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.
Hello,
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`)
Regards,
jeremiejig
Upvote for this request.
We have a rare scenario that requires this reply-to been added to some of the firewall rules. and the GUI does not provide that so far.
So I'm dynamically modify the dumped rules at /tmp/rules.debug to add the 'reply-to' to some of our rules then use pfctl -f to apply it.
If the GUI could provide a way to force add this reply-to when creating the rules. that will be great!
- Status changed from New to Rejected
From what I can tell, the referenced scenarios would be solved by adding a gateway to the interface. This is the currently supported way of using reply-to. When an exception is needed on interfaces with gateways, an option is available per rule to disable reply-to. If there's a scenario that is not covered by this, the feature can be reconsidered.
- Status changed from Rejected to New
- Priority changed from Normal to Low
There are some scenarios where it would be nice to have the ability to force reply-to to use a specific value and not be automatic. For example, cases with multiple gateways on the same interface, or certain VPNs that may not have the exact expected behavior with the automatic settings.
Also available in: Atom
PDF
Updated by Ermal Luçi 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 