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

    Port obfuscation with 1:1 NAT

    Scheduled Pinned Locked Moved NAT
    11 Posts 4 Posters 2.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.
    • C
      Crispix
      last edited by

      I have a small hosting network and just migrated from Sonicwall to PFSense. Mostly working just fine.

      I have 1:1 NAT set up and working from WAN to DMZ for a /24 network.

      I want to obfuscate all my RDP servers. My customers will RDP to servername.com:9999 and I will port forward to 3389 on the internal IP address. I set up a NAT port forward for each server, publicip:9999 forwards to internalip:3389.

      I got that part working - for each RDP server, I set up a new NAT rule, and a firewall rule was automatically created to allow destination:internalip port:3389 and the port forwarding works perfectly. (It's my understanding that NAT occurs before the firewall rules, so this config makes sense.)

      The problem is the original port 3389 also still works! PFSense auto-creates the firewall rule to allow WAN to 3389 (MS RDP) for each server and I can now connect to my RDP servers on both 3389 and my alternate 9999 port.

      I want to block port 3389 and only allow port 9999 from the WAN and still keep the port forwarding active. What do I need to change? Thanks, hope I explained this clearly.

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

        "My customers will RDP to servername.com:9999"

        Why would your customers not just vpn in and then rdp.. RDP open to the public be it you try and hide the port or not is not secure solution..

        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
        • C
          Crispix
          last edited by

          Yes, VPN is a secure solution, however I'm looking for obfuscation for more services than just RDP.

          This is more about how to properly obfuscate a port in pfsense rather than how to maximize security for this specific task.

          1 Reply Last reply Reply Quote 0
          • I
            isolatedvirus
            last edited by

            The original port works because of the 1:1 nat you have set up. You will need a deny rule listed on your wan interface to deny access to destination: internalip port 3389. This would require a rule for every 1:1 you have set up. Alternatively you can deny inbound connections yo 3389 going to ANY IP, which would reduce the overhead to a single rule.

            1 Reply Last reply Reply Quote 0
            • C
              Crispix
              last edited by

              @isolatedvirus:

              You will need a deny rule listed on your wan interface to deny access to destination: internalip port 3389.

              Unfortunately if I do that, both regular and obfuscated RDP connections stop working. The auto-added rule from the port forward allows traffic to internal port 3389, so added a conflicting block rule to internal port 3389 just stops everything from getting though.

              I thought that NAT always takes place before any firewall rules are checked, so I don't see how port 3389 can get through unchanged when there's a NAT rule to first redirect the traffic to port 9999.

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

                If all you want is the port forward, turn off the 1:1 and just use the port forward.

                The port forward is taking precedence or connections to outside:9999 would be going to inside:9999.

                You are seeing connections to outside:3389 going to inside:3389 due to the 1:1. That traffic is passed by the rules.

                Kind of illustrates the folly of "port obfuscation."

                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
                • C
                  Crispix
                  last edited by

                  @Derelict:

                  If all you want is the port forward, turn off the 1:1 and just use the port forward.

                  The port forward is taking precedence or connections to outside:9999 would be going to inside:9999.

                  You are seeing connections to outside:3389 going to inside:3389 due to the 1:1. That traffic is passed by the rules.

                  Kind of illustrates the folly of "port obfuscation."

                  Ok, I get it. Sounds like I while I can still redirect a port, I cannot obfuscate/block the original port because I have to keep the 1:1 NAT. Thanks for the clarification.

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

                    Yeah I can't think of a way to do that. If you really want to obfuscate the RDP port I think it will have to be done on the target host by changing the listening port there in this case.

                    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
                    • C
                      Crispix
                      last edited by

                      @Derelict:

                      Yeah I can't think of a way to do that. If you really want to obfuscate the RDP port I think it will have to be done on the target host by changing the listening port there in this case.

                      Oh, nice work-around, I like the idea! But really I think it's time to get my clients to accept either a VPN or limit their RDP access to just trusted IPs or networks.

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

                        👍

                        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
                        • I
                          isolatedvirus
                          last edited by

                          You can still do it just with a bit if cleverness. Nat incoming connections to 3389 to port 65555, and dont enter a firewall rule to pass, or set the rule to deny. This rule would have to be above your 1:1 nat rules so its matched first. Bam. Filtered rdp in the 1:1 nat scenario.

                          Edit:

                          Oh, nice work-around, I like the idea! But really I think it's time to get my clients to accept either a VPN or limit their RDP access to just trusted IPs or networks.

                          Oh and +1 to the VPN. Way more secure.

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