How can GRE be secure?

Hi there, I’m new to Zscaler and have a question about the recommended connection method from an office to Zscaler. GRE is the recommended method. Deploy a GRE tunnel from your internal network, over the Internet to Zscaler. Sounds nice and simple. However how does this provide security if an attacker or snooper is in the traffic path? Let’s say some of the traffic from my office destined for the Internet is encrypted and some isn’t (which is normal). So the traffic goes to Zscaler and is scanned, and so is the return traffic/replies. The attacker then intercepts the reply traffic and inserts malicious code/malware/virus/worm/document change - which goes back onto the internal network inside the office. I think I must be not fully understanding how this stuff works. I can see it would be fine if 100% of all traffic destined to the Internet is encrypted 100% of the time but what about any traffic that isn’t encrypted - couldn’t an attacker intercept this on the way back from Zscaler? I think perhaps I don’t fully understand the recommended setup here. Can anybody enlighten me? Thanks, P.

GRE is not by design a secure protocol because it does not encrypt the payloads.

The GRE Tunnels are for creating locations to route the traffic directly to Zscaler. If security is of concern, then IPSEC would be of benefit to add encryption.

There would still be SSL/TLS available with GRE though this is still subject to attacks.

1 Like

May I ask you @Mr.Whiskers - why are you so concerned about security of Internet-bound traffic? In a traditional network, traffic hits onprem FW, then NAT is applied and it is being sent into a wild west. Attackers (MITM) can potentially do whatever they want. Hence, why all business critical apps must be TLS encrypted.

Zscaler receives exactly the same Internet bound traffic. Hence why would you encrypt it at this point? If it’s non TLS application, then application must be re-designed to address this. At the end of the day. it will leave Zscaler cloud unencrypted (if it’s HTTP). I am not sure about your concern :slight_smile:

2 Likes

Thanks for the reply Adam, security is what Zscaler is about so I’m surprised that they don’t recommend IPSec VPNs as the recommended unless an organisation knows that all of its traffic is encrypted, in which case GRE would be fine.

Thanks for the reply Tymofii, normally (at least in a reasonable sized organisation) reply traffic would be scanned by a security stack after it gets back from the Internet. With Zscaler and GRE tunnels it’s scanned before being sent back out over the Internet and back into the organisation.

Using GRE tunnels just exposes more of the Internet to the unencrypted data whereas IPSec tunnels would not expose the traffic on its way to Zscaler or on the way back - just a smaller attack surface. I was originally thinking about stuff like DNS queries which might be sent unencrypted but anything that’s not encrypted is a potential risk I suppose.

Ok, I get your point. If DNS is hijacked, Zscaler will stop this connection. Not DNS itself, but further application traffic as it will be going to a non legitimate IP address. Zscaler performs DNS lookups as well. But if you want this extra layer, then yeah… IPSec. Or switch to DNS over HTTPS :slight_smile:

We also use ZCC Tunnel2.0 over GRE which means connections from end users are encrypted with DTLS end to end. Only IoT traffic goes via GRE unencrypted, and DNS too… but as I said, Zscaler ‘should’ detect hijacked DNS in the application stack, when client attempts to establish HTTP/S connection to hijacked and potentially blacklisted IP address.

Thanks again Tymofii, I’ll bear in mind the ZCC Tunnel2.0 over GRE.

On the down side it may be that the new IoT connected office washing machine tries to become the DHCP server :wink:

1 Like

Generally encrypting Internet bound traffic with IPSec is not very helpful as it’s only adding the encryption layer between your site and Zscaler. If the traffic isn’t encrypted, and assuming it’s allowed in your zscaler policy, the traffic will continue from zscaler to it’s destination natively (unencrypted).

@yakuza you should not send Tunnel 2.0 traffic inside of GRE to zscaler. If you are using Tunnel 2.0 for devices behind a GRE tunnel, then traffic for Zscaler IPs (i.e. tunnel 2.0 traffic) should go direct. GRE can still capture other traffic of course.

It’s perfectly fine, and even recommended to use PAC or Tunnel 1.0 traffic inside of GRE though.

1 Like

@MikeRuiz when this was implemented in our environment it WAS a recommended best practice and was vetted by Zscaler :slight_smile: only near to the end of our deployment we’ve been told it’s not… I believe this project (ZIA) is now trying to find a way to bypass GRE/IPSec for Tunnel2.0 traffic, but it’s not as simple as it sounds.

Awesome @yakuza I’m glad you’re working internally and with Zscaler to sort that out. Most of my customers if they’re doing default route out GRE, put in some static routes and bypass traffic destined for Zscaler ranges letting it go direct. But as you say, it’s not always that simple.

We’re Aruba (Silver-Peak) SDWAN and it’s not simple… well, at least our MSP still trying to figure out how to do this. AFAIK, first two attempts have failed, but I am not very close to this activity.

1 Like

Hi Mike, the point I was making is that any unencrypted traffic can be intercepted on the Internet after it’s been scanned by Zscaler before going directly onto the company internal network.

What can I say… DHCP snooping :smiley: We’ve implemented globally quite a while now. Works like a charm :smiley: