Bug #14
closed
reply-to should not be added when bridging
0%
Description
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.
Files
Updated by Chris Buechler over 15 years ago
- Target version set to 1.2.3
Note this also causes difficulties when you have a static route on WAN pointing to something other than your default gateway, for traffic that is not initiated by the firewall.
Updated by Chris Buechler over 15 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.
Updated by Ermal Luçi about 15 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.
Updated by Scott Ullrich about 15 years ago
How would we tell when we need the reply-to or not. We need to define the logic that is involved.
Updated by Chris Buechler about 15 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.
Updated by Dan Swartzendruber almost 15 years ago
- File test_results.rtf test_results.rtf added
- File bug-14_diffs.rtf bug-14_diffs.rtf added
Test output and patches uploaded.
Updated by Scott Ullrich almost 15 years ago
Can you please submit these patches as normal text files? Rich text files do not play along with patches.
Updated by Dan Swartzendruber almost 15 years ago
- File test_results.txt test_results.txt added
- File bug-14_diffs.txt bug-14_diffs.txt added
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 :(
Updated by Dan Swartzendruber almost 15 years ago
Oh fooey, my bad I think. I noticed I hadn't checked the 'watch this issue' box.
Updated by Ermal Luçi almost 15 years ago
- Status changed from New to Feedback
Patch committed thanks.