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

    Port Forwarding over OpenVPN Site to Site

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 2 Posters 836 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.
    • T
      tonny512
      last edited by tonny512

      I barely know much about routing and networking, so I need help here. I am trying the best I can, though.

      I have the publicly connected WAN (pfA) and a double nat (pfB). pfA is hosting an OpenVPN Server for site to site, where pfB is the client. They both can contact their networks and both have assigned an interface to the VPN tunnel.

      What I am trying to do is something like this:

      Public WAN pfA (3389) (1.2.3.4) -> OpenVPN Interface -> Private LAN pfB -> RDP Server (3389) (192.168.10.123).

      Right now I tried to just add the NAT Port Forwarding rule in pfA to the IP since it is pingable by the router, and both sides can ping each other, but the port forwarding just doesn't work. LAN to VPN-LAN works, but WAN to VPN-LAN doesn't.

      Am I missing something here?

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

        @tonny512
        I don't recommend to access RDP via the internet at all. You should tunnel the whole path.

        However, to forward WAN traffic over the VPN in general consider following:

        • If pfB is still on version 2.5.1 upgrade the box before you go on.
        • On pfB you have to ensure that a firewall pass rule on the interface you have assigned to the OpenVPN client instance is matching the incoming traffic from pfA.
          That means, there must no pass rule on the OpenVPN tab and as well no floating rule match the traffic.
          Consider that both would have priority over the interface tab.
        T 1 Reply Last reply Reply Quote 0
        • T
          tonny512 @viragomann
          last edited by

          @viragomann RDP was just an example.

          pfB was updated to 2.5.2 today.

          OpenVPN interface has no rules.
          d6562872-0b49-4665-88e4-dd7a79237aec-image.png

          The VPN is assigned to OPT2.
          91fac115-827f-4c7a-af67-7f1baf878f77-image.png

          There is also no floating rules set.
          20c21497-4e53-409a-85a2-e6c4aaab6d16-image.png

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

            @tonny512
            Should work, doesn't it?

            T 1 Reply Last reply Reply Quote 0
            • T
              tonny512 @viragomann
              last edited by

              @viragomann It doesn't. It could have something to do with the RDP protocol though. I could try a different software to test the port.

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

                @tonny512
                I assumed that pfB is the default gateway on the destination computer.

                On side A the NAT port forwarding to the destination IP and the firewall rule have to be set properly.

                Also consider that the destination computer might block access from out of his own subnet. That is the default setting of Windows firewalls.

                You can sniff the traffic using Diagnostic > Packet capture on pfB to see what's going on.
                If Windows blocks the access you will see the packets on side B's LAN interface going to the computer, but no responses coming back.

                T 1 Reply Last reply Reply Quote 0
                • T
                  tonny512 @viragomann
                  last edited by

                  @viragomann I just tried it again with a different server-side and it worked flawlessly.

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