Port obfuscation with 1:1 NAT
-
"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..
-
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.
-
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.
-
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.
-
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."
-
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.
-
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.
-
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.
-
-
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.
