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

    OpenVPN Clients are not using outbound Port forwarding

    Scheduled Pinned Locked Moved NAT
    9 Posts 3 Posters 587 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.
    • P
      Paddy
      last edited by

      Our office has connections to remote sites that have services on non standard ports.

      I setup port forwarding so that standard ports could be used by staff which were then forwarded to the non standards ports at the remote destination.

      This works on our LAN but not for clients on our OpenVPN subnet. They have to use the non standard port or else they can't connect.

      I have duplicated the forwarding rules and changed the source interface to the openvpn interface, but this didn't help.

      Any ideas

      Patrick

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        You will probably have to provide examples (screen shots) of something that is working vs something that isn't.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • P
          Paddy
          last edited by

          Here are examples of what I have.

          The first forwarding rule works for nodes on my LAN but not for nodes connected on my OpenVPN interface.
          OpenVPN users need to include the non standard port number.

          0_1551717245472_portfw1.JPG

          I then added another port forwarding rule but changed the interface to openvpn. Everything else is the same. This didn't help.

          0_1551717280862_portfw2.JPG

          The third screen shot is my OpenVPN rules.

          0_1551717292219_openvpnrules.JPG

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Hmm. Working here.

            Where is 10.10.10.10?

            Does it have a route back to your OpenVPN tunnel network? Does it accept connections from the OpenVPN tunnel network?

            I am running it in the opposite mode, forwarding https://host:28443/ to host:443 but the principles are the same.

            The states look as you would expect:

            0_1551723724797_Screen Shot 2019-03-04 at 10.21.44 AM.png

            https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              You running pfblocker - it uses 10.10.10.10 as a vip..

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • P
                Paddy
                last edited by Paddy

                Sorry. I sanitized the rules as they are client IPs 10.10.10.10 was the first IP that came into my head.

                The IP at the remote is a public IP that is locked down to our external IP.

                Some of our remote workers need access to the client's ips so they connect to the our pfsense using openvpn which is configured to send all traffic. This then allows them to connect to our clients as there connection is coming from our external IP.

                This works great when standard ports are used such as HTTP on port 80. However some of our clients use non standard ports(5555 for example) that are then forwarded to the correct port (80) in their dmz.

                To make this transparent to our staff I do the opposite at my end so that pfsense accepts the outbound connection on the standard port (80) and then forwards it to our clients IP on its non standard (5555) which their firewall then forwards to the correct port (80) in their dmz.

                This all works flawlessly for our LAN users. Our remote users connecting in openvpn however must include the non standard port in their url ie. http://remote_IP:5555. before they can successfully connect.

                So it would appear that pfsense is not applying the portforward rule when the outbound connection originates from the openvpn subnet.

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  OK. Except that it does apply the port forward as I have demonstrated.

                  Probably going to need a diagram. Your description is not making a whole lot of sense.

                  You can look at the states in Diagnostics > States and see what address/port translations are being applied.

                  You will also have Outbound NAT in play if these are connections to hsots outside of WAN. But those will only apply translations to the source addresses, not the destinations.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • P
                    Paddy
                    last edited by

                    I discovered the problem.

                    I used the copy rule function to copy the working forwarding rule and changed the interface to OpenVPN.

                    This new 'copied' rule didn't work. I deleted it and manually created it - and it works.

                    It seems that modifying a copy of a rule caused my problems.

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      I have never seen that happen. a copied rule is the same as making a new rule. It is more likely you did not adjust something that needed to be adjusted.

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

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