- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-13-2022 03:35 PM
Hello, I am new to Palo Alto and I would like help in configuring RDP access to a server in the private network for testing purposes. I have gone through several articles but cannot seem to get it to work. Below is my config. Any help is greatly appreciated.
NAT Policy:
Original Packet:
Source Zone: untrust
Destination Zone: untrust
Destination Interface: eth 1/1
Service: Any
Source Address: Any
Destination Address: Public IP address of the Firewall
Translated Packet:
Source Address Translation: None
Destination Address Translation:
Translated Address: Private IP address of the server or subnet of the private network/Also tried public IP
Translated Port: <blank>
Security Rule
Source Zone: untrust
Source Address: any
User: any
Destination Zone: trust
Destination Address: Public IP address of the firewall
Service: RDP
Action: Allow
Log: end
11-13-2022 04:45 PM
Hello @Linford
Your two policies look OK. You review the Monitor Log traffic when you testing the access from external Networks?
Translated Address: Private IP address is the correct
You check if another policy block the trarffic ? You check if your Nat and Security policy do it a Match/Hit ?
You have checked review if the endpoint local Firewall/IPS an other security sofware can block your request to RDP ?
Cheers
11-14-2022 07:09 AM
Thanks for the response. Based on the config posted earlier, I was not getting any Match/Hit. Monitor logs was not showing any traffic from my local to the Firewall or Server. Made one change to the policies by switching Public IP of firewall to private IP and I can see some traffic but rdp still doesnt work. Did a capture on the traffic and I can see my local reaching the firewall private ip and servers private IP but no response coming back from the server. Anything here that I am missing?
11-14-2022 09:20 AM
Helo @Linford
Ok, so both the security policy and NAT, you already see Hits in it.
OK, when you check the incoming traffic in the firewall you already see logs, marked as age-out ? if you filter for example by tcp port 3389 ?
Now the next points to check.
-Does your server, which you are trying to reach, have local windows firewall ? or some software that could be denying the connection ? Did you validate by disabling, just temporarily to validate, and then make the corresponding adjustments ?
-Now the server has correct access to its default gateway ? to the LAN gateway of your Trust network ? Do you have Ping to it ?
-Now from the server you have access to the Internet ? if you do a Ping or a trace you have access ? the trace and the ping answer correctly ?
-At firewall level has the default route set, the public default gateway, that is your 0.0.0.0.0/0 through the same link associated to your 1/1 interface?
-Do you have multiple WAN links ?
- From the RDP server, do you have access to the Internet ?
Best regards
11-14-2022 10:30 PM
Yes I do see traffic in the logs. Image attached
Also disabled firewall temporarily. Server has correct access to its default gateway and trace route succeeds to the internet. Default route has been set and 0.0.0.0/0 attached to eth1/1. RDP server has access as well and still no luck. Could you please explain having multiple WAN links mean? Also noticed that, logs traffic are only generated when rdp file is pointed to the public ip of the firewall.
11-14-2022 10:47 PM - edited 11-14-2022 10:50 PM
Hi usually the age-out issue is either a nat issue or a return path issue.
I mean if you have more than one link to the internet, multiple links.
The server must be able to, I am talking from the server, directly from the server, to have correct internet access from the server's private Ip to some test Ip.
Now a nat destination NAT, has to comply with the following.
Referential example:
NAT policy:
Origin zone: Untrust/WAN zone
Destination Zone Untrust/WAN zone
Source Any ( or you filter from X public IPs to establish the connection )
Destination Address: The public IP with which you are doing the NAT / DNAT ( i.e. the External IP of the server, External Public )
Service: You could just set the RDP, example TCP-3389
Source translate: Nothing None
Destination Translation: Here at this exact point goes the Private IP, the LAN IP of your server.
You can use Translated Port to set 3389.
Now the Security Policy example:
Source zone Untrust/WAN Zone
Destination: The destination zone, e.g. DMZ, Trust, Servers, etc. however you have it named.
Source Address: Any
Destination Addres: The public IP with which you are doing the NAT / DNAT (i.e. the External IP of the server, External Public).
In service: You can also use the service to close and only limit to port 3389-TCP-RDP.
Try in each case, NAT and security policy, upload the policy to be one of the first, in both cases.
Now your server must exit on the same link that your request enters so you don't have problems with return traffic.
Validate that the server, that is to say from the private IP of the server, can exit correctly to the Internet, that at the level of routing by the main link and/or the same of the DNAT it works well.
Now also validate that you are placing the correct Ip, that the server, if you arrive from the same LAN or from the same network if you answer the RDP.
Validate that from the Server you have Ping with the LAN gateway, you have Ping, with public Ip.
Validate that there is no security profile blocking the connection.
Try the connection from several external connections, from outside the network, not from the inside, but from the outside against that public IP you mention, from your laptop sharing internet with your cell phone via 4G, from a home network, your house, etc.
Greetings
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!