Detailed understanding of "Zero trust Egress"
-
I have been reading up on how Zero Trust Egress works, and it's really an extremely usefull feature when it comes to tight client security. I just need to understand one thing because I cannot confirm that by looking at the UI:
1: I have surmised this must be working using hidden floating match rules that tags traffic, is this correct?
2: Does that mean CoreDNS dynamically creates one new floating rule for every client that does a DNS lookup, and it also creates a dynamic list of IP's that client has resolved. The hidden floating match rule then has the client IP as source, and the clients DNS resolved list as destination, and this tags the connection as "coredns_allow"?
3: There is also a lower priority floating match rule that tags anything NOT matched by the above as "coredns_deny"
I assume the decision to hide these rules was based on the VERY long list of floating rules it can create?
-
ZTE is easily the most interesting functionality of CoreDNS in my opinion. A novel use of
pf's packet 'tagging' that could augment/coexist nicely with pfBlockerNG.For posterity, documentation on ZTE configuration (https://docs.netgate.com/pfsense/en/latest/recipes/nexus-coredns-zero-trust-egress.html) and a recipe(https://docs.netgate.com/pfsense/en/latest/recipes/nexus-coredns-zero-trust-egress.html) are already available in the official docs.
-
@tinfoilmatt I agree and I have read them. I would just like to know how it has been implemented in the back so I can make an educated guess on performance.
I’m mostly worried about the thousands of lists of resolved IPs CoreDNS needs to maintain (one for each client), and the risk of the client attempting to pass correctly resolved traffic before CoreDNS and pfFilter is updated with the correct list of resolved IP’s for that client.
Privacy Policy · Cookie Policy