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

    Port fowarding to host on far end of site2site (due to CGNAT)

    Scheduled Pinned Locked Moved NAT
    6 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.
    • T
      tedly
      last edited by

      So.. I have multiple sites that were all connected to each other. One of the satellite offices is switching to CGNat (starlink). So I shuffled some of the openvpn NAT/Rules and now VPN clients (mobile or site2site) connecting to the non-CGNAT endpoint can reach the CGNAT end. And that's great. That's the largest concern.

      But it's major bonus points if I can port forward for public IP space, where they won't be on the VPN. But no matter what I do, I can't seem to get the routing between the Hosts under CGNAT to reply to the clients originating on the other end of the site2site. I think it has to do with the fact that traffic reaching the servers is coming from a public IP and therefore possibly responding out the local gateway of the CGNAT pfsense site. Rather than back to the originating client.

      I feel like this might be where Outbound NAT does ... something. But for the life of me, I can't seem to grasp what I want to setup in my outbound NAT rules.

      Am I heading down the right path? If so, what kind of rules should I be using for the Outbound NAT.

      HELP!

      port-forward-over-site2site-vpn.jpg

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

        @tedly
        You can solve this by masquerading (outbound NAT) on headquarter pfSense though, but that's a dirty workaround. You would loose the information about origin public source IPs on the servers.
        To avoid this, pfSense can also handle the routing properly, when you set it up correctly.

        So let's go. On the branch pfSense assign an interface to the site-to-site OpenVpN client instance and enable it, if you didn't already. Hence you get a firewall rule tab for this interface.
        Then move the firewall rules which are allowing the forwarded traffic from the headquarter to this interface and remove all rules from the OpenVPN tab.
        As I understand your drawing, there is only one OpenVPN instance anyway, so it's easy move all rules over.
        Also ensure that there is no floating rule applied to the forwarded traffic from the remote site.

        That's the whole magic. It should work after this is done.

        1 Reply Last reply Reply Quote 1
        • T
          tedly
          last edited by tedly

          There actually is a lot of routes in there for site to site vpn clients. But if i know which is the fix then i'll do the grunt work of moving it too.

          But, honestly, I got impatient for a reply. (No knock on you's, it's free help!) So last night I setup a new Netgate box on one end and and bought a new IP for a VM on the other end. And now I have two virgin pfsense hosts.

          It was too late to start tough problems for me at that point. But tonight I'll jump in and first try out Wireguard cause I hear that's quite a bit faster/efficient. And if that falls through, I'll give your extra interface idea a try.

          But thank you for the reply! And telling me outbound NAT is an unwise path. :)

          1 Reply Last reply Reply Quote 0
          • T
            tedly
            last edited by

            I don't believe the recommended steps worked.

            To start with, I have an existing site-to-site vpn on the 100.64.0.0/24 network.

            HQ side is 192.168.104.0/24
            Branch side is 192.168.1.0/24

            Each pfsense is on .1 on it's own network.

            Until I made the changes, the pfsense hosts could ping each other's internal IP.

            Here are the files on the Branch (since thats where all the changes were made).

            branch_interfaces.png
            branch_new-int_enabled.png

            That shows the new interface (called s2svpn) and my enabling it.

            branch_WAN_rules.png
            branche_OpenVPN_rules.png
            branch_s2svpn_rules.png

            And those are the corresponding firewall rules. The moment I moved the rule from OpenVPN group to S2SVPN group i could no longer ping the oppose side's interfaces. But I went forward to see if it worked in the end.

            HQ_NAT.png
            HQ_Rules.png

            Here is the HQ side. (Dark mode, so one can tell apart easily.)

            NAT is listening on port 7788 TCP on WAN.

            15313 is web config port.
            7201 is UDP for openvpn port.
            12345 is the port on the 192.168.1.1 pfsense for webconfig.

            I cannot pass traffic from outside of the HQ side through the VPN to the port on the Branch side.

            HQ_Openvpn_rules.png

            This is the only other relevant thing I can think of. On the HQ side I have the allow rules for the OpenVPN for the tunnel subnet.

            What am I doing wrong? @viragomann

            Please and thank you.

            1 Reply Last reply Reply Quote 0
            • T
              tedly
              last edited by

              I gave each vpn end a restart and now the two sides can ping. Excellent! But the above posted port forward is still not working.

              1 Reply Last reply Reply Quote 0
              • T
                tedly
                last edited by

                Got it!

                HQ_port_pass.png

                I could see the port passing in on HQ. But still no dice.

                branch_missing_port.png

                I added this accept rule on the Branch side and now it talks!

                Took me some wandering but now I understand. Thanks @viragomann !

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