I managed to get GP VPN setup on my PA220 and get a Windows workstation to connect to it. It gets assigned one of the IP addresses reserved for VPN clients. When I attempt to connect RDP to a remote machines from this VPN client it fails. The VPN client is x.x.x.195 and the target machine is x.x.x.18 in the same subnet. When I check the monitor logs I can see incoming traffic from the .195 address but nothing coming back from the .18. I started a WireShark trace on the network and I can see that the traffic is reaching the .18 address but the .18 address is not able to return to .195 because it is failing to ARP for .195.
What have I done wrong?
PA220 running PanOS 10.x
Windows 10 with latest 64bit GP Client
Could you tell me where your VPN tunnel lands? does it terminate in the same zone as the RDP target ?
I have always found that it is a lot easier (as well as being best practice) to terminate your GP tunnel in a separate zone and then create the rules to and from that zone to your inside or DMZ.
I would say that a starting point would be to check the following
Zones that the Tunnel Terminates in (which Virtual Router is it using)
Rules between the GP tunnel and the Zone that is hosting your RDP Target,
Then do a packet capture on the interface facing the RDP Target.
RDP to the target machine works when testing from another node in the same subnet so I've eliminated that. The configs have changed some at this point on the PA220 so my previous wire shark captures are no longer valid but traffic was previously reaching the target node but the target node was not able to return to the VPN client due to failing ARPs. We'll see how far we get tonight with trouble shooting.
Sorry for the very late reply, that isn't actually what I meant, I was wondering if you had terminated the VPN in the same Zone as the RDP session was being created, as I said in the post the best practice would be to separate the two (separate zones, separate Subnets) but some people do not do this, so yes I quite agree that normally the two are different.
Did you really not find a solution to this? I am sure we can figure what is happening as this should be a workable configuration, let me know if you want to continue trying to fix the issue.
The problem I think is that logically speaking the VPN host is actually on a different interface to the host that you are trying to reach, so when the target .18 host tries to reply it simply arps out for the MAC address in standard way, I think that there should be a mechanism by which it can resolve the tunnel interface for the destination.
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!