Project

General

Profile

Bug #6986

reply-to is not functioning on pfSense 2.4

Added by Jim Pingle 10 months ago. Updated 9 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Rules/NAT
Target version:
Start date:
12/05/2016
Due date:
% Done:

100%

Affected version:
2.4
Affected Architecture:
All

Description

Rules in the ruleset have reply-to, but any rules matching inbound traffic on non-default WANs fail to fully establish because reply packets are not respecting reply-to but are instead exiting the default gateway.

Should be simple to replicate on any Multi-WAN system. Put a port forward to something on the LAN on both WANs. It will work on the default gateway WAN but fail on the other. Same config and rules work fine on 2.3.x.

History

#1 Updated by Renato Botelho 9 months ago

  • Assignee set to Luiz Souza

#2 Updated by Luiz Souza 9 months ago

JimP, I cannot reproduce this bug with todays snapshot. This is a fresh install with two WANs (DHCP) and two port forward rules to the same client (with different ports). Works in both cases.

Maybe I need something else to reproduce this ?

#3 Updated by Jim Pingle 9 months ago

It's still not working here. Port forwards only work on the WAN with the default gateway. Configuration is unchanged in that regard from what had been working on 2.3.

I didn't have to do anything special. Two WANs, one LAN, port forward on both WANs to the same local port on the same target, which is a very common Multi-WAN configuration.

In /tmp/rules.debug, the firewall rule for each port forward has reply-to on it, as expected, and the rules are being matched judging by the counters. However, a packet entering the non-default WAN has its reply exit the default WAN.

You may not notice it if your upstream does not do strict state checking or egress filtering, as the packet may still leave the default gateway and reach back to the client in your test.

#4 Updated by Luiz Souza 9 months ago

  • Status changed from Confirmed to Feedback

#5 Updated by Luiz Souza 9 months ago

  • % Done changed from 0 to 100

#6 Updated by Jim Pingle 9 months ago

  • Status changed from Feedback to Resolved

I tested this on two systems that previously reproduced the problem 100% of the time, and now they both work. Looks good to me.

Also available in: Atom PDF