Port forward egress packets not being rewritten
-
Hi folks,
Struggling a little with some port forwarding. Previously, we were running pfSense 2.1.5 on a desktop PC, and all was good. We upgraded to 2.3.2.1, then migrated (via backup then restore of config) to a PCEngines board running the same.
Network looks like:
Public interwebs <–> ADSL router (which I don't have control over, so can't put into bridge mode) 192.168.0.1 <--> 192.168.0.2 PFSense 10.105.56.250 <--> 10.105.56.1 Server in question
There's a bunch of other 10.105.x.0/24 subnets on the LAN side of PFSense as well, each of which (including the .56.0/24) is a tagged VLAN on igb0; 192.168.0.2 is untagged on igb2. We're not running multi-WAN. The only gateway is 192.168.0.1
The ADSL router is set up to DMZ everything through to PFSense. This hasn't changed since everything was working pre-upgrade.
Outbound NAT from 10.105.56.1 to the internet works fine.
However, we have a port forwarding rule pointing inwards:
pfctl -sn | grep 1050
rdr on igb2 inet proto tcp from any to 192.168.0.2 port = 1050 -> <int_server>round-robin
And associated filter rule:
pfctl -sr | grep 1050
pass in log quick on igb2 reply-to (igb2 192.168.0.1) inet proto tcp from any to <int_server>port = 1050 flags S/SA keep state label "USER_RULE: NAT Test" dnpipe(2, 1)
If I mirror both igb0 and igb2 on the switch to a machine running Wireshark so I can see packets on both interfaces, I see:
a.b.c.d:56748 –> 192.168.0.2:1050 SYN - from ADSL router's MAC to igb2's MAC
a.b.c.d:56748 --> 10.105.56.1:1050 SYN - from igb0's MAC to the internal server's MAC
10.105.56.1:1050 -> a.b.c.d:56748 SYN ACK - from the server's MAC to igb0's MAC
10.105.56.1:1050 -> a.b.c.d:56748 SYN ACK - from igb2's MAC to the ADSL router's MACThe fourth packet is where the problem shows up - pf seems to be failing to do the address translation of the outbound packet, but obviously does do the right thing on the inbound packet.
If I look at the state table at this point, it's in the half-established state:
pfctl -ss | grep 1050
igb2 tcp 10.105.56.1:1050 (192.168.0.2:1050) <- a.b.c.d:56748 SYN_SENT:ESTABLISHED
igb0_vlan56 tcp a.b.c.d:56748 -> 10.105.56.1:1050 ESTABLISHED:SYN_SENTI don't think I'm doing anything crazy, but obviously it isn't wanting to play :-). I've tried rebooting, disabling the rules and re-enabling, disabling and enabling NAT Reflection (though I believe it should not apply here as I'm coming in from a WAN IP).
Any thoughts very much appreciated…
[Edited to add: I've just gone back to the original hardware, post-upgrade to 2.3.2 (not p1), and the behavior is the same, so I don't believe it's hardware-related.]
Thanks,
Rob</int_server></int_server> -
Ahh… a clue: this only seems to apply when I have a pipe selected on the filter rule.
Dropping the pipe off so the rule becomes:
pass in log quick on igb2 reply-to (igb2 192.168.0.1) inet proto tcp from any to <int_server>port = 1050 flags S/SA keep state label "USER_RULE: NAT Test"
…everything works correctly.
The limiter is configured to allow a fixed amount of bandwidth, with no schedule, no mask, and no advanced options set.
Cheers,
Rob</int_server> -
Limiters with NAT are broken everywhere but on 2.4 devel snapshots.
-
Thanks - just found the bug having established the connection! https://redmine.pfsense.org/issues/4326
That explains why it broke after the upgrade from 2.1.5 :-(.