Excuse what is probably a very novice problem.
I've gone through the guide on setting up a SSL VPN (1.3.0) on PAN 4 for our new PA-500, and I can successfully log into the NetConnect client and receive an IP from the VPN pool, etc. However, I cannot ping or otherwise reach any internal systems. When I run traceroute to an internal system, it times out after the first hop to my own system.
Looking at its network configuration, everything looks good, except no default gateway is listed. I can't tell if this is normal behavior or not. The routing table on the VPN client appears to have a valid entry for accessing the internal network.
After looking through the forums and other documentation, the most obvious answer seems to be that I'm missing something in regards to a rule/policy that is blocking traffic from going over the VPN. I've tried setting rules to allow such traffic, but have been unsuccessful.
Any help/ideas would be greatly appreciated.
A picture is worth a thousand words...
Can we see a picture of the SSL VPN client config tab?
Is there a route in your virtual router (on the PAN) for the ssl vpn client IP address pool and does that route point back to the tunnel interface you are using for the ssl vpn?
I am not sure which documentation you would have used to configure your VPN, but it could also depend on how you are connecting your VPN clients whether you are NAT'ing them through to you internal network or routing them through, as if you are using a private IP range that is not part of the internal network you default gateway if not the PA would need to know about sending that traffic back to the PA on the tunnel interface.
Also is your VPN on the same zone as the internal network ? if not you would need to add a security rule in to allow them though and the applications they would require.
Hope this helps
Hi bpappas and Marct, thanks for your help.
Attached is a screen grab of the VPN client config tab. The IP pool sits in the same subnet as the rest of the internal network, but is reserved in the DHCP server. The VPN is on the trust zone along with the rest of my network, so I don't think there's any security policy getting in the way.
As for the virtual router, the VPN's tunnel interface is included in the same virtual router as both the trust and untrust zones. I do have an entry that I thought would take care of routing from the tunnel interface to the trust interface. However, it's looking more and more like it's either the virtual router or a NAT rule that I'm missing (after looking through the logs, I can see the ping requests coming through and being allowed through by a security rule, so I know the packet is getting as far as the firewall and being passed through security).
I've tried tweaking my virtual router and NAT rules, but still haven't been able to get packets to pass through to the trusted zone. Any hints as to how these rules should be configured would be helpful.
Thanks again for your help.
Your access route points back at the subnet which contains the SSL VPN clients.
the access route should point at your internal networks behind the PAN device!
Ah. So, the VPN clients must be on a different subnet than the rest of the internal network? Well, good to know! However, I'm still missing something. After putting the VPN clients on a different subnet, I still cannot ping the internal network.
Thank you for your help, as always!
You need to use a different subnet for the remote clients. Once you have the different subnet, please make sure the internal servers and layer3 devices on your trust networks knows that to reach the remote client subnet then need to route the traffic to PAN.
You can also try to do a traceroute from the internal server to the IPs of the remote client VPN and check if it reaches the PAN as well.
Hope this helps.
One more thing which I missed if you have a deny any any any rule at the bottom of your rule base and don't have a policy for trust to trust traffic above your deny rule then traffic from trust zone to trust zone will be blocked as well. FYI.
Thank you for your help.
After I put the VPN on another subnet, I set up a VR route for anything bound for the remote subnet to be sent over the tunnel. I tried to ping again, and still no luck.
As you suggested, I did a traceroute from an internal network machine, and it successfully made the first hop to the PAN trust interface as it should, but timed out all subsequent hops, so it knows that packets bound for the VPN subnet need to go over the PAN.
One interesting thing is that it DID successfully run a netbios-ns to get the hostname of the machine it was tracing to the VPN network -- the host name appeared in the header of the tracerout, and the traffic entry appeared in the PAN log.
All of this has be thinking I must be fundementally misunderstanding the configuration of my virtual router, or there is a NAT rule I need to set.
Again, thank you for time and help trying to get this newbie squared away. It is really much appreicated.
1) Do you have any firewall installed on the remote computer? If you do can you please disable it and see if that helps.
2) When the SSL VPN comes up, can the routing table to see if a /32 bit route for the remote client shows up in the routing table via the tunnel interface. use command "show routing route 192.168.x.y"
3) What version of PAN-OS SW and SSL server vers are you using?
4) Check the session table using "show session all filter destination <server-ip>" once you identify the session check the session id. Follow that by "show session id <session-id>" to see how many layer 7 packets you saw and if natting is done properly on that session.
5) If all the above does not help then please open up a support case for this issue.
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 Live Community as a whole!
The Live Community thanks you for your participation!