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

    NAT vs port forward

    NAT
    3
    8
    210
    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.
    • S
      silviub
      last edited by

      Hello,

      I've got a PFSense firewall that's got an IPSec connection to another site. This other site has a subnet 10.41.13.0/24 which is allowed to get to everything behind my PFsense.
      Inside the network, I want to redirect the traffic to a non-existing IP that I want forwarded to another IP (inside the local network). This work surprisingly well, but I've got a head-scratcher:
      My PFsense rule to do this is:
      196ee2b7-6722-4b95-9ec3-90a218c1c96d-image.png
      10.41.199.65 is the local IP, OpenVPN is the interface where the traffic is COMING from. So, as I understand this, all traffic coming IN the OpenVPN interface, any src address and any port, with a destination of 172.31.254.100 will be forwarded to 10.41.199.65. FORWARDED, not NAT-ed, right?
      Well, the funny thing: I've got traffic coming from 10.41.13.0/24 via the IPSec interface that matches this rule AND also gets NATed.
      Why I'm saying it matches this rule: when I disable this rule, the 10.41.13.0/24 network can't connect to 172.31.254.100 anymore.

      Help?! As I don't get it. Why does this traffic match the interface and, most importantly, why does it get NATed?

      Thank you.

      S 1 Reply Last reply Reply Quote 0
      • S
        SteveITS Rebel Alliance @silviub
        last edited by

        @silviub If you create a NAT rule then you’re using NAT port forwarding, even if it’s all ports.

        Are you trying to route packets to this IP? If pfSense doesn’t already know how to get to it you’ll need to create a static route.

        https://docs.netgate.com/pfsense/en/latest/routing/static.html

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        S 1 Reply Last reply Reply Quote 0
        • S
          silviub @SteveITS
          last edited by

          @SteveITS hello and thank you for your reply.
          I've created the Port Forwarding rule by going to Firewall -> NAT -> Port Forwarding. I was not aware this is not just a port forward, but also a NAT rule....? Is it?

          I'm trying to route packets that have the 172.31.254.100 as destination to 10.41.199.65 IF they are coming from the VPN interface. Right now, even though the interface is set to OpenVPN, it is matching all interfaces. From the documentation, the interface:

          Interface
The interface where the port forward will be active. In most cases this will be WAN. For additional WAN links or local redirects this may be different interface. The Interface is the location on the firewall where traffic for this port forward enters.

          So by creating the above rule, I thought this would mean ANY traffic coming IN the OpenVPN interface, change the destination from 172.31.254.100 to 10.41.199.65. What am I doing wrong?

          P.S. 10.41.199.0/24 is the IP address of one of the PFSense interfaces, so no routes should be needed.

          Thank you!

          S 1 Reply Last reply Reply Quote 0
          • S
            SteveITS Rebel Alliance @silviub
            last edited by SteveITS

            @silviub Rules created on the NAT page are NAT rules. NAT rules are port forwards. That's the only way to redirect an IP:port to a different IP:port.

            Is 172.31.254.100 the pfSense OpenVPN interface IP? Or something on pfSense? If not then pfSense shouldn't be receiving that connection and should not be able to do anything with it.

            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
            Upvote 👍 helpful posts!

            S 1 Reply Last reply Reply Quote 0
            • S
              silviub @SteveITS
              last edited by

              @SteveITS No, 172.31.254.100 is not the PFsense IP, but it gets the traffic for 172.31.254.100 because the PFSense is the default gateway.
              I want to have some "virtual" / nonexisting IPs that are being forwarded on very specific ports. This works, and works amazingly well, the only issues is that the port forward rule seems to be ignoring the incoming interface.
              P.S. I have just tried assigning 172.31.254.100 to the PFsense and nothing seems to be changing.

              S 1 Reply Last reply Reply Quote 0
              • S
                SteveITS Rebel Alliance @silviub
                last edited by

                @silviub OK yeah my coffee caught up.

                Not sure why/how your NAT rule would apply to any other interface. You can set a source on the NAT rule though, "OpenVPN subnets" I think is how it'd be phrased now. That should narrow it down.

                If you don't want it NATted, and pfSense knows where 172.31.254.100 is, access can be controlled by firewall rule, without NAT.

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote 👍 helpful posts!

                1 Reply Last reply Reply Quote 0
                • M
                  mvbif
                  last edited by

                  Hello,
                  Port forwarding is a nat (It change the destion, but based on port too), Destination nat, source nat.
                  Network Address Translation, in your case is a destination nat, source and port will stay.
                  Nat lonely should not allow anyway traffic not allowed from a security rules.
                  So now i will check but, i feel to say that yes that nat rule will apply only on traffic coming from openvpn and has that destination.

                  About the ipsec traffic, are you saying that with nat on, your ipsec host can ping 172.x.x.x , with nat off can't anymore?
                  Btw ipsec should have rules permitting traffic to 10.41.99.65 isn't it?

                  S 1 Reply Last reply Reply Quote 0
                  • S
                    silviub @mvbif
                    last edited by silviub

                    @mvbif Yes, you're right, port forwarding is a DNAT, actually, I was wrong. The thing is, this port forwarding is SNAT-ing too.

                    Nat lonely should not allow anyway traffic not allowed from a security rules.

                    The port forwarding was done and a rule has been added to allow the traffic. Also, the IPSec traffic is allowed via a different rule, so the traffic is allowed.

                    So now i will check but, i feel to say that yes that nat rule will apply only on traffic coming from openvpn and has that destination.

                    Well, this is what should happen. Only traffic coming in via the OpenVPN interface should match. But it doesn't.

                    About the ipsec traffic, are you saying that with nat on, your ipsec host can ping 172.x.x.x , with nat off can't anymore?

                    Yes, that's what I mean. If I exclude the IPSec connected subnet (10.41.13.0/24) from the NAT rule OR I disable the NAT rule, the IPSec traffic cannot go to 172.31.254.100.

                    Btw ipsec should have rules permitting traffic to 10.41.99.65 isn't it?

                    Yes.

                    Also, the thing is, the rule's SNATing too: With the rule in place, 10.41.13.225 for example, can curl 172.31.254.100 and get a reply. On the 10.41.199.65 (the actual IP that the port forwarding rule is set on) I see the traffic coming from 10.41.199.2 (PFSense).
                    Test scenario: Via the IPSec, I'm sending, from 10.41.13.225 a curl 172.31.254.100:2345 (port was chosen so no traffic is going to disturb the test). With the port forwarding rule enabled, I can see traffic on 10.41.199.65, coming from 10.41.199.2 (PFSense IP address) dst port 2345. This clearly matches the traffic. Checking the firewall logs I can see the traffic being allowed from 10.41.13.225 to 10.41.199.65 (translated IP address). This means that PFSense matched the traffic and DNATed via the above rule, but it also SNATed (why?).
                    Disabling the above rule and running the same scenario: curl 172.31.254.100:2345 in the firewall logs I can see the traffic as being allowed from 10.41.13.225 to 172.31.254.100 (not translated) but the traffic doesn't reach the 10.41.199.65 VM (normal, since it was not translated).
                    What's going on?!

                    Also, check this out: states tables filtered by 2345 (dst port):
                    8710e90a-870d-4772-8d91-8056ab5d502a-image.png
                    So it sees the traffic as coming from the IPSec interface, but it's SNATing it and then delivering it to 10.41.199.65.
                    I have NO NAT RULES to match this traffic (outgoing on VLAN199 interface) so there should be no SNAT done, from what I can say. There's no NAT rule matching 10.41.13.225 or 10.41.13.0/24 or 10.41.0.0/16.
                    Can't I somehow see what NAT rule is this traffic matching?

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