Zscaler Airgap: True Zero Trust Microsegmentation

Поділитися
Вставка

КОМЕНТАРІ • 5

  • @adamwhite3811
    @adamwhite3811 4 місяці тому +1

    I really dont understand the /32 and how this connects. If the host needs to get somewhere, and it is not seen as the same segment, then it needs to look at its routing table, will arp for the next hop and send the traffic. In this case, the zscaler is not on the same segment, so how does this work? What does it arp for? how does it send the packet there through the OSI stack? It still needs some kind of reachability. My only guess is that there is some proxying or tunneling of the traffic and the /32 is not really a /32, but isolated through some mechanism from talking to anything but the zscaler device.
    Would be nice to not have to guess, and actually, you know, have it explained, would take less than a minute.
    Also since someone else was nitpicking, I might as well do it too. If you are going to draw networking symbols, drawing a core with a traditional router picture, that implies L3, that firewall hanging off is all but useless

    • @mdirfanpatel6478
      @mdirfanpatel6478 11 днів тому

      All the traffic will be sent to the default gateway similar to how it has been (with /32 as the netmask everything will be sent to default gateway). I am just curious though whether the appliances are capable enough or not from the Zscaler Airgap to handle that kind of traffic load.

  • @RbNetEngr
    @RbNetEngr 5 місяців тому +1

    A few comments:
    1. You did not provide any real details here. You imply that the ZScaler Airgap ‘client’ locks down each individual host, and the Airgap box (physical or virtual) manages the policy to lock down each host. But you didn’t provide enough details here.
    2. Unlike NSX, which applies policy to the virtual NIC shim that is not part of the VM, Airgap looks to be installed on the hosts. So, what would stop a bad actor from disabling or removing Airgap from that host?
    3. Nitpick. You started out by drawing the Core of what you said was a Data Center, and the first thing you drew was a User VLAN. Generally, user VLANs are out in the campus, or branch locations, and NOT in the Data Center. So, does the Airgap solution ONLY apply to Data Centers (as a replacement for functionality provided by NSX or similar), or is it also something that could/would be deployed on a campus or branch network as well?
    4. If this IS a solution for Data Center, Campus and Branch/Remote Office networks, does each location need a LOCAL ZScaler Airgap “policy box” to manage policy? Or would a smaller number of distributed or centralized “policy boxes” be deployed to manage policy for remote networks? And if the “policy boxes” are remote, what happens to policy enforcement and application if the Airgap-equipped hosts lose communication with the “policy boxes”?

  • @routeypackets2842
    @routeypackets2842 5 місяців тому

    So it appears to be a router on a stick, but still sharing the same broadcast domain? There aren't really details here but I'm trying to understand how you are truly isolating the clients on a same VLAN from each other, it can't just be at a layer 3 level, you blocking ARP's etc? They running clients? Just changing a host to a /32 would certainly contain that host but what about misconfiguration or bad actors also attached to that VLAN?

    • @Ruchikun
      @Ruchikun 4 місяці тому

      I mean. Zscaler pretends it's not just vpn/firewalling but in the end... Everyone relies on the same basic tech :p private vlans have been a thing for aaaaaages