VPN vs ZTNA - where is FW applied in ZTNA if on-prem?

VPN
1

Hi All
We are traditional user with edge firewalls deployed and our VPNs terminate there. So all traffic from employees laptop terminates on firewall, gets inspected, and then forwarded to desired server in DC. We have edge firewall in AWS for direct VPN from users to access cloud VMs. We have NAC deployed as well for segmentation.

All this is working solution; yes complicated but built over time and had to scale VPNs when everybody went remote.

New vendors are pushing for ZTNA solution. In that solution, as per our understanding, instead of VPN client on laptop, you have ZTNA client. Now there are two options:

  1. install agents on each of DC servers… and then from ZTNA client from laptop T-bones into ZTNA cloud and connects via some proprietary tunnel to that server’s agent.

  2. Or, you can install a (or set of) proxy near those servers, and tunnel from laptops again after T-bones into these proxies.

Of course, segmentation policies can be applied which are I think implemented in cloud at T point. Or may be downloaded into agents/proxies. Either way.

Question: Where does the traffic gets inspected before hitting servers?

A) I’m using on-prem edge firewalls and do not intend to replace them in future, these proxies or agent on servers bypassed the firewall inspection due to encrypted tunnel passing through them.

B) I asked the vendor if somebody is using their cloud based NGFW, does inspection happens at T point before traffic is forwarded to DC. He said no? I am assuming person doesn’t know and that may be an option.

This is my understanding of the subject and quite likely I may be missing some big piece here. Any help or pointers are appreciated.

Thanks

2

Question: Where does the traffic gets inspected before hitting servers?

This wildly varies from product to product so we can’t be entirely exact.

But to take it at a more abstract point, I’d describe ZT it like this:

  • Network Segmentation from your users to network resources essentially disappear.
  • Network Segmentation between your resources will still be required.

In many scenarios you’ll have your resources (or maybe a single set of servers dedicated to ZT connectivity) making an outbound connection of some sort to some sort of proxy/termination point.

You users will access this proxy, either by clients using microtunnels (like zscaler), or through something as simple as DNS redirection (like Cloudflare for Teams or Google BeyondCorp Enterprise). In either case, the vendor’s cloud makes the decisions on what applications are allowed, and can perform additional inspections.

The proxy is intelligent enough to perform authentication and authorization across multiple criteria (user, device posture, location, etc). And many of them can include L7 protections (think OWASP), since a majority of products in the pure ZT space focus primarily on web-based application protections for now.

When I say pure ZT - most (if not all) firewall vendor “ZT” solutions still rely on IPs to determine access and forward. They often map users to IPs, map applications to IPs, or perform a combination of both. This works great until you have a web server running hundreds of applications. At the L3/L4 level you’ll be allowed access to servers and with clever L7 manipulation you could gain access to applications you don’t have permission. This means you’ll be relying on AAA built into the application/service - which is painful to scale after 50 or applications. User’s IPs can be spoofed as well with enough knowledge, and tracking user’s IPs as they access resources can be painful with only L3/L4 information (what do you mean, I need VPN logs AND the firewall logs???).

A pure ZT solution, all requests are filtered/logged at Layer 7. So you don’t need to worry about IP Pools anymore, or tracking down who was logged in at a particular point in time; You’ll know each connection as it was generated by the user.

I’ve been slowly putting notes together in a public repo to help explain some of the differences between types of access, architecture, and the common pitfalls of Zero Trust designs and deployments. It’s still far from complete, but I’ll always be happy to take feedback or additional contributions there.