- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
07-09-2024 01:34 PM
Scenario: Panorama managed VM-700s. 10.2.9-h1. using template stack. Netskope is a cloud web proxy.
We setup new tunnel interface, GRE tunnel, static route, network monitor, allow rule, no-NAT rule, and PBF. We use a PBF because Netskope requires it.
Clients don't go down the tunnel. I can't ping the probe IP from the clients nor from the firewall using ping source [tunnel_IP] host [probe_IP]
If I enable Keep Alive the tunnel goes down because I can't ping the probe IP.
Coworkers, Netskope support, Palo support, and a 3rd party consultant can't find anything wrong.
Any known gotchas with this? Troubleshooting ideas?
07-30-2024 06:44 AM
The solution was to create an additional No-NAT rule. We already had No-NAT from our test clients to Any destination with interface being the tunnel.1.
However, the packet diagnostics found the need to have an inbound rule from Netskope's Peer IP to our public interface Source IP. Untrust to untrust zone. Any service (because GRE is a protocol not available for selection). And targeting that Ethernet1/1 interface.
Inbound: Netskope Peer (4.1.1.4) to Palo Ethernet 1/1 (3.1.1.3). Zone untrust to untrust. Any service. interface Eth1/1.
Last piece to allow tunnel traffic inside.
Outbound: Inside Test Clients to Any destination. Zone trusted to untrust. Service tcp 80/443. interface Tunnel.1.
07-17-2024 09:25 AM
Netskope escalated the ticket and said I should change the static route destination to their public IP. but no change in the problem. New drawing attached.
Keep in mind we have the Keep Alives disabled because if they are enabled the Tunnel interfaces goes DOWN.
We then disabled the PBF Rule Monitoring option, and then the PBF rules goes UP.
At that point, the test client started hitting the PBF, but no websites are working. Packet Capture shows no return traffic. Netskope then said it's a Palo problem. Palo ticket is still open and pcaps are being looked at.
07-30-2024 06:44 AM
The solution was to create an additional No-NAT rule. We already had No-NAT from our test clients to Any destination with interface being the tunnel.1.
However, the packet diagnostics found the need to have an inbound rule from Netskope's Peer IP to our public interface Source IP. Untrust to untrust zone. Any service (because GRE is a protocol not available for selection). And targeting that Ethernet1/1 interface.
Inbound: Netskope Peer (4.1.1.4) to Palo Ethernet 1/1 (3.1.1.3). Zone untrust to untrust. Any service. interface Eth1/1.
Last piece to allow tunnel traffic inside.
Outbound: Inside Test Clients to Any destination. Zone trusted to untrust. Service tcp 80/443. interface Tunnel.1.
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!