This message was deleted.

You configure the PBR to isolate the management traffic. If you provide DNS in this dedicated NSIP subnet than you don‘t need the rule. But normaly DNS is not inside of this dedicated subnet and needs to use another route. Using the DENY rule you simply set it to use the normal routing table.

The only other way to get around it is to use a load balancing virtual server on the NetScaler to provide DNS resolution. In that case the NSIP will only try to contact the VIP. Once there, the SNIP of choice will take over, also using the default routing table or a specified IP address if you are using IPSET/NETPROFILE. The PBR kinda acts like an ACL of sorts.

I always thougth that it was cause the DNS Traffic (the first Request) in case that you use a non addressable DNS Load Balancer is going from NSIP to 127.0.0.2:53 and then the PBR would match and normally the gateway would not know what to do with a packet to 127.0.0.2

@Jan Tytgat Have I understood correctly, that your case also supposes lack of DNS resolution in management network?

In some cases, dns resolution is not available in the management network and it needs to be routed, indeed.

@Marion It's never mentioned in the original article that DNS is load balanced, it only says that DNS traffic is "special" 😁

balancing resources the NS consumes itself like DNS/LDAP/etc locally on the appliance had historically been considered a best practice so that's why docs tend to assume that config. It used to be the only way you could alter the behavior iirc