- 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.
08-14-2024 01:01 AM
Hello,
We are in a very similar situation to the one you describe in your case. After applying the "No-NAT" solution, were you able to re-enable the Keep Alives in the tunnels?
Regards
08-14-2024 07:32 AM
Yes, we were able to enable Keep Alives on the GRE Tunnels and the PBF Monitor. Funny thing is, I have since disabled the inbound NAT rule and the tunnel stays up. I also engaged a new consultant and he said he's never heard of that being necessary to get the tunnel working. I found the only way I could break the tunnel was by deleting the GRE Tunnel at Panorama. Disabling it wasn't enough. Kinda making me crazy.
I'd love to hear if that solves your problem. Let us know.
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!