Menu Categories Author

Nubis Novem

Consulting On Cloud Nine

Pinning a hole in Palo Alto: NAT forwarding of inbound TCP port

“I’m fixing a hole where the rain gets in
And stops my mind from wandering
Where it will go”
“Fixing A Hole”, from The Beatles album “Sgt. Pepper’s Lonely Hearts Club Band” (1967)

Today our challenge was to create a simple setup that is often called inbound TCP port forwarding, or, a pinhole with a more (or less) advanced firewall device. The network appliance for this cosmetic surgery was one of the recent PAN (Palo Alto Networks) PA-3000 series running PAN OS 6.0. First of all, do not do it. Again, do not do it. And again: please, do not create a destination port forwarding from external network interface into an internal or trusted network behind the firewall. There are other (proper!) techniques that would be better to use for remote network access, dedicated line or VPN (stands for Virtual Private Networking), for instance. Modern VPNs have little overhead and lots of security benefits. Though, for testing purposes only, we have decided to ignore our own advice which was just mentioned above for 3 times.

Task

Imagine, there was a Windows server behind that firewall (what a rare commodity these days, but it is easy if you try). We needed to grant remote access to that server. One might think of a vendor or a home office user that would not use VPN for various reasons. The task was to allow RDP or Remote Desktop protocol on external IP of the firewall to internal IP of the Windows server. For instance, external IP is 192.0.2.38 and that belongs to “untrust” Layer-3 / external interface. Internal network IP for the server would be 192.168.233.20 (and it is part of the “trust” zone with firewall internal interface).

Implementation

RDP Service added as follows:


Name: RDP
Protocol: TCP
Destination port: 3389
Source port: 1-65535

NAT rule added as follows:

Name: Incoming RDP
Tags: none
Source zone: untrust
Destination zone: untrust
Destination interface: any
Source address: any
Destination address: 192.0.2.38
Service: RDP
Source translation: none
Destination translation: address: 192.168.233.20

Security policy looked like this:

Name: Incoming RDP
Tags: none
Source Zone: untrust
Source Address: any
Destination Zone: trust
Destination Address: 192.0.2.38
Service: RDP
Action: allow

It was a bit challenging to figure out that NAT rule had to have both source AND destination zone designated as “untrust”. It is also counter-intuitive to indicate in the security policy destination zone “trust” while destination address is from external interface (which belongs to untrust zone). Apparently, PAN considers NAT mechanism a part of a zone of destination (translated) interface. Also, it would be a bit humbling to admit that initially a silly mistake was made with value 3389 entered in the source port option of the service object (instead of 1-65535). That had to be a range of source ports, it does not work otherwise, for obvious reasons.

Aftermath notes

These rules may be adjusted in several ways:

  • One might have used a different port to forward from outside, say 22999 that would go to 3389 on the server. It would be an easy change in the rules, still there would be some risk involved in case your internet traffic would be observed and custom port that you were trying to hide would become known to a perpetrator, even while modern RDP session is protected by SSL encryption.
  • Source address may be indicated to restrict access only to certain user with a static IP or a range of IPs. While it is better than allow “any” source of the connection, though the spoofing risk still remains in this case.
  • Applications might be restricted to: ms-rdp, t.120, ssl, cotp.
  • Please use VPN or any sort of protected or dedicated connection instead of a direct pin hole exposed to the whole almighty Internet. :)

References

Comments

(3)
  • Shane
    #

    Thanks..This really helped me out. Your instructions are clear and I was able to do this. I recommend restricting the source IP address if you will be allowing RDP into your network.

    • Andrei Spassibojko
      #

      Thank you, Shane, we are glad it was useful for you. We are trying to provide level of details just enough for a professional to use as reference. You are right, filtering source IP is a logical thing to do. Sometimes that is not possible, though, in certain scenarios (home computers, dynamic IPs and staff traveling). All sorts of VPN, private network setup is easier to maintain and more secure in that regard. That is why “do not implement this” as is repeated quite a few times throughout text of the recipe.

  • Tim
    #

    This was extremely helpful – I am new to Palo Alto and this helped me set up both RDP and HTTPS access for a vendor. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *