reply-to should not be added when bridging
When bridging to a WAN or OPT WAN with hosts that use a gateway other than the WAN/OPT WAN's gateway, reply-to will break the ability to communicate with those hosts from the outside.
It's not as simple as not adding reply-to when bridging though, as that will create a different bug where bridging is used in combination with multi-WAN.
#2 Updated by Chris Buechler about 10 years ago
- Target version changed from 1.2.3 to 2.0
work around committed to RELENG_1_2. https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/efefb2a1e860d082a6024b7c6b67c646b1e8aa6e
needs to be revisited for 2.0, in hopes we can find a better change that won't cause regressions and automatically handles the bridging and static route scenarios properly.
#3 Updated by Ermal Luçi over 9 years ago
- Affected Version set to 2.0
Well if you are doing NAT in bridge mode and the 'other' gateway of the host is not on the same subnet as the gateway of the WAN/OPTWAN there is no escape.
If you are just doing bridging than you do not need at all the reply-to, afaik.
#5 Updated by Chris Buechler over 9 years ago
It's not possible to definitively tell on the firewall, there are too many possible combinations and it ultimately depends on what the default gateway of the bridged hosts is - if it's the same as WAN's gateway it doesn't matter.
having a "Disable reply-to" checkbox under Advanced on a per-rule basis seems like the best solution for this. That's the only way every possible scenario can be handled correctly.
#10 Updated by Dan Swartzendruber over 9 years ago
Test and patch re-uploaded as vanilla text. By the way, I'm not sure why, but I do not seem to be getting email notifications of issues like this in my inbox. I have verified my email address on the site and checked my mailserver logs, and no indication of any problems :(