Bug #6986

reply-to is not functioning on pfSense 2.4

Added by Jim Pingle about 4 years ago. Updated about 4 years ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


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.


#1 Updated by Renato Botelho about 4 years ago

  • Assignee set to Luiz Souza

#2 Updated by Luiz Souza about 4 years 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 about 4 years 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.

#5 Updated by Luiz Souza about 4 years ago

  • % Done changed from 0 to 100

#6 Updated by Jim Pingle about 4 years 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