Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Port forward egress packets not being rewritten

    Scheduled Pinned Locked Moved NAT
    4 Posts 2 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rmc47
      last edited by

      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 MAC

      The 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_SENT

      I 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>

      1 Reply Last reply Reply Quote 0
      • R
        rmc47
        last edited by

        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>

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          Limiters with NAT are broken everywhere but on 2.4 devel snapshots.

          1 Reply Last reply Reply Quote 0
          • R
            rmc47
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.