-
Here I will show my errors I made or where pfsense didn't work like expected.
The most things I describe are on multi wan scenarios.1. Always choose a gateway for wan interfaces at the interface setting:
If you don't choose a gateway, the pfsense can't make rules with route-to and reply-to options for choosing the right interface for traffic.
Without this options the traffic for WAN2 will leave at WAN1.2. Rules on interface groups won't work like rules on interfaces:
Normally interface based rules get the reply-to option, which shows the pfsense on which interface the packages have to leave.
That means if a session comes in on WAN2 the pfsense remember this rule with the gateway of WAN2 for this state and the packages go out the right way.
Interface groups don't have a single gateway and pfsense couldn't set a reply-to rule.
I think this makes interface groups useless until pfsense splits the rules for each interface.more will come next …
-
Those behaviors have always been the same on 2.x, and to some extent on 1.2.x (1.2.x didn't have groups though).
The lack of reply-to on group rules isn't something that can be 'solved' since there is no way to have those properly determine the return gateway since it would be ambiguous. The only potential workaround, aside from just putting the rules on their appropriate WAN interfaces, would be to have the backend produce one rule per interface with the correct gateway. That isn't really viable either though because it would break the way the group rules are handled, and if there were some mix of WAN-type and non-WAN-type interfaces in a group the outcome would be very ambiguous.
-
those are all by design. Jim addressed #2, #1 is because there has to be a way to differentiate what is and what isn't a WAN.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.