Project

General

Profile

Bug #14

reply-to should not be added when bridging

Added by Chris Buechler almost 10 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Rules/NAT
Target version:
Start date:
06/10/2009
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

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.

test_results.rtf (818 Bytes) test_results.rtf Dan Swartzendruber, 01/07/2010 04:10 PM
bug-14_diffs.rtf (3.19 KB) bug-14_diffs.rtf Dan Swartzendruber, 01/07/2010 04:10 PM
test_results.txt (612 Bytes) test_results.txt Dan Swartzendruber, 02/05/2010 03:11 PM
bug-14_diffs.txt (2.85 KB) bug-14_diffs.txt Dan Swartzendruber, 02/05/2010 03:11 PM

Associated revisions

Revision efefb2a1 (diff)
Added by Chris Buechler almost 10 years ago

add "Disable reply-to" box. Work around for bug #14

Revision 19757916 (diff)
Added by Ermal Luçi over 9 years ago

Ticket #14. Implement an advanced option to allow disabling autogenerated reply-to. Submitted-by: Dan Swartzendruber

History

#1 Updated by Chris Buechler almost 10 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.

#2 Updated by Chris Buechler almost 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.

#4 Updated by Scott Ullrich over 9 years ago

How would we tell when we need the reply-to or not. We need to define the logic that is involved.

#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.

#6 Updated by Dan Swartzendruber over 9 years ago

I am taking a go at this one.

#7 Updated by Dan Swartzendruber over 9 years ago

Test output and patches uploaded.

#8 Updated by Dan Swartzendruber over 9 years ago

Any update?

#9 Updated by Scott Ullrich over 9 years ago

Can you please submit these patches as normal text files? Rich text files do not play along with patches.

#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 :(

#11 Updated by Dan Swartzendruber over 9 years ago

Oh fooey, my bad I think. I noticed I hadn't checked the 'watch this issue' box.

#12 Updated by Ermal Luçi over 9 years ago

  • Status changed from New to Feedback

Patch committed thanks.

#13 Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Resolved

works

Also available in: Atom PDF