Client successfully connects and get's IP but is unable to communicate to remote machine

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Client successfully connects and get's IP but is unable to communicate to remote machine

L3 Networker

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


L4 Transporter



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.



Cyber Elite
Cyber Elite



Need to confirm why you configure VPN client IP pool and remote PC with same subnet?

Normally VPN pool IP is on different subnet then target PC subnet.


Please confirm this


Help the community: Like helpful comments and mark solutions.

L3 Networker

I've updated the config so the VPN addresses are in their own L3 subnet and zone.  I'm also fairly sure I updated the VR to make sure it had a route between the two as well as the security policy and PBF.  I opened a support case with tech support to figure this out.



Thanks for updating us.

Keep us posted what Tech figures out.

Also on PC where you are trying to RDP should have RDP enabled.




Help the community: Like helpful comments and mark solutions.

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.


I've given up on getting it to work.

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.

  • 8 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!