trouble with GRE tunnel to Netskope

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

trouble with GRE tunnel to Netskope

L1 Bithead

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? 

 

1 accepted solution

Accepted Solutions

L1 Bithead

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.

View solution in original post

4 REPLIES 4

L1 Bithead

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. 

L1 Bithead

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.

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

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. 

  • 1 accepted solution
  • 1491 Views
  • 4 replies
  • 0 Likes
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!