- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
02-09-2012 04:41 AM
Hi
I am looking for a way doing a packet capture (or Debug Flow) with a filter based on a defined VPN Connection. The only thing I found, was a filter like "debug dataplane packet-diag set filter match ingress-interface tunnel" but with this I am not able to filter just one VPN Connection (eg tunnel.100). It seems, this command doesn't support sub-interfaces.
Filtering based on src-/dst-address is not possible since we sometimes use GRE like VPN's (both sides of Phase2 ProxyID's are 0.0.0.0/0) and I want to check if src-/dst-IP are the right ones.
Also, filtering based on zone is not possible since all our vpn tunnels are in the same zone (firewall doesn't support that many zones as we have tunnel interfaces)
02-13-2012 07:28 AM
I see, thank you for the details. You could use your traffic log for this investigation. If all of your remote sites map to unique zones, you can filter based on zone and then look at the traffic log details to see how the source and destination addresses were changed by NAT. These details are available in the session detailed view (magnifying glass icon at the far left of the traffic log in the web interface).
If your remote sites all map to a common zone, you can expose the egress and ingress interfaces in the traffic log and filter using that criteria. Each remote site will have a unique tunnel interface so it's easy to narrow the search.
Thanks,
Nick
02-12-2012 10:03 PM
Hi,
Doing a filter based on a defined VPN Connection is not possible. I am afraid we do not have such granularity at the moment. The purpose of filters on a PAN box is for debugging and it yields the best results when trying to capture very specific traffic.
Thanks,
Ahsan
02-13-2012 06:48 AM
Hello,
Could you please describe the goal of this packet capture? We may have functionality elsewhere in the firewall that will help.
Thanks,
Nick Campagna
02-13-2012 07:15 AM
As described, we have some VPN tunnels which allows any traffic (Proxy IDs 0.0.0.0/0). With this, we have a GRE-Like Encrypted tunnel.
With VPN, there are always a lot of NAT configuration which could be wrong. Since the administrators on most of our remote sites aren't big companies, there usually don't have big knowledge in special NAT configurations. So, they are sometimes wrong and on a Zyxel (or similar) firewall, it is not easy to debug. Sometimes they even struggle on the routing part.
An easy way to find configuration issues on the remote firewall (if you don't have access to it), is looking at the traffic which is coming from this VPN.
Routing Issues -> No Traffic at all
NAT issues -> Traffic with wrong source/destination IP
If you can do a filter on outgoing interfaces, it's also an easy way to check if my NAT is correct.
As described, I am looking for traffic which is not as expected. So, i am not able to filter it based on IP information. And for a setup like "each VPN has its own zone" (so I can filter based on Zone) the Paloalto doesn't support that much zones as we have tunnels.
02-13-2012 07:28 AM
I see, thank you for the details. You could use your traffic log for this investigation. If all of your remote sites map to unique zones, you can filter based on zone and then look at the traffic log details to see how the source and destination addresses were changed by NAT. These details are available in the session detailed view (magnifying glass icon at the far left of the traffic log in the web interface).
If your remote sites all map to a common zone, you can expose the egress and ingress interfaces in the traffic log and filter using that criteria. Each remote site will have a unique tunnel interface so it's easy to narrow the search.
Thanks,
Nick
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!