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

    Problem to port forwarding - Wireguard and PfSense

    Scheduled Pinned Locked Moved NAT
    14 Posts 3 Posters 1.2k 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.
    • V
      viragomann @meletechlab
      last edited by

      @meletechlab
      The clients might not be able to handle this properly. They will send responses to their default gateway.

      You can only workaround this by masquerading the forwarded traffic with the wg interface IP on pfSense. But then you loose the information of the origin source IP.

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

        There is an online service called PortMap that performs the same services I wanted. Obviously, since I cannot rely on external services due to the sensitivity of the data that passes through the tunnel, I need to replicate this condition. Consider that I am not interested in the source of the call but only that the traffic to that specific port is established with the client. Each client has a different port

        V 1 Reply Last reply Reply Quote 0
        • V
          viragomann @meletechlab
          last edited by

          @meletechlab said in Problem to port forwarding - Wireguard and PfSense:

          There is an online service called PortMap that performs the same services I wanted.

          You mean this one in conjunction with VPN, I assume.
          There are the same conditions true for this. Either the VPN server is used as default gateway or the provider masquerades the traffic.

          Since you don't want to use the VPN as default route and don't care about the source IP, you can go with masquerading.

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

            Could you possibly help me with masquerading as I have never used it and I don't want to cause any trouble. How can I apply a rule?

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

              I tried to test it but it didn't work. I would like all traffic coming from outside on port 10203 to be forwarded to port 1880 on IP 172.16.16.3/32 (vpn client). Obviously 10203 must also be opened

              13b344c6-7adf-4a17-bd3b-535dc6df9ca0-image.png

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @meletechlab
                last edited by

                @meletechlab
                You have to do this on the VPN interface.

                Assuming you have already assigned an interface to the Wireguard instance, add an outbound NAT rule to this interface
                interface: <wg instance interface>
                source: any
                source port: any (it's most likely dynamic)
                destination: 172.16.16.3
                dest. port: 1880 (if you want to limit the rule to the needed port)
                translation: interface address

                Ensure that the outbound NAT is set to hybrid mode.

                M 1 Reply Last reply Reply Quote 0
                • M
                  meletechlab @viragomann
                  last edited by

                  @viragomann Into translation section "interface address" it is not present, I only find the ones you see in the photo where WG_VPN is the VPN interface
                  f135aac7-35f9-4f1c-af87-4f8fa376c5ee-image.png

                  V 1 Reply Last reply Reply Quote 0
                  • M
                    meletechlab
                    last edited by

                    I first created a port forwarding from the WAN network (therefore public) to the IP of the wireguard client from the external 10203 to the internal 1880
                    d9eca440-e864-4711-94e1-26e4cea525f8-image.png

                    Then I created the rule according to your directions
                    068f6e08-da2e-42aa-87f4-c4c94097cf26-image.png

                    1 Reply Last reply Reply Quote 0
                    • V
                      viragomann @meletechlab
                      last edited by

                      @meletechlab said in Problem to port forwarding - Wireguard and PfSense:

                      Into translation section "interface address" it is not present, I only find the ones you see in the photo where WG_VPN is the VPN interface

                      Okay, that's new to me. So select the WG_VPN address then.

                      I first created a port forwarding from the WAN network (therefore public) to the IP of the wireguard client from the external 10203 to the internal 1880

                      Then I created the rule according to your directions

                      Seems all correct.
                      But no success?

                      M 1 Reply Last reply Reply Quote 0
                      • M
                        meletechlab @viragomann
                        last edited by

                        @viragomann Nothing, I also tried changing the translation address to various addresses but no results. the VPN client is correctly connected to the Wireguard and from there I reach the PFSense interface

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @meletechlab
                          last edited by

                          @meletechlab
                          Sniff the traffic to find out where it Stücks.
                          On pfSense use Diagnostic > Packet capture to sniff the traffic on the VPN interface. If there is nothing check the WAN.

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