No problem, Dan. I don't believe the default behavior can be changed as that is hard coded but you can specify which PSN you want it to connect to via the discovery host attribute in the client provisioning profile.
If I'll "hard code" the PSN in the client profile, when would the agent try to connect to the PSN? Would the agent wait for redirection? Or any other trigger to cause the agent to contact the PSN?
I'm pretty sure that if you set a discovery host, the NAC agent will attempt to connect to it once it detects network access. Here is the NAC agent discovery sequence to ISE:
1. http discovery probe on port 80 to default gateway if no discovery host
2. http discovery probe on port 80 to discovery host, if configured (via HTTP Redirect)
3. https discovery probe on port 8905 to discovery host, if configured
4. http discovery probe on port 80 to default gateway (via HTTP Redirect)
5. https reconnect probe on port 8905 to previously contacted ISE Policy Services node
6. GoTo 1
Actually, it needs not be a PSN. I usually recommend one other than PSN but it depends on the web redirect ACL.
A Discovery Host is a DNS-resoluable FQDN or IP address by the client machine and by accessing it at HTTP port 80 will trigger web redirects to ISE PSN client provisioning portal along with a session ID from the network access device.
It does not actually need access to the Default Gateway, it is just sending a request out that is intercepted by the Switch/Controller that is then redirected using a redirect URL to the PSN (or other specified Discovery host).
Think Guest portal redirect, it may not have access to the website but it is still redirected to the portal.
What would be the destination IP address of the first HTTP(S) packet that the posture client sends?
EDIT: Maybe I should have also asked this: What is the order of operation on incoming packet to the switch? dACL -> WEB_redirec_ACL or is it WEB_Redirect_acl and only if its a deny, then dACL?
NAC agent or ISE posture module in AnyConnect will try a couple of different targets (DiscoveryHost, default gateway, previously connected ISE policy service nodes, and (AnyConnect only) enroll.cisco.com) to try discovering the current ISE policy service node that authenticating the client. The first one is likely the DiscoveryHost, but AnyConnect ISE posture does parallel probing.
The redirect ACL takes precedence over the DACL (per-user/-session), that over the port ACL configured in "ip access-group <ACL-name> in" per interface. Please note that "redirect ACL" works differently, so that a permit entry will trigger potentially trigger redirect while a deny entry will allow the traffic through.
Not exactly. I use an example below to explain this.
We use a redirect ACL to redirect certain connections. A sample redirect ACL from our ISE compliant training lab is as below:
ip access-list extended ISE-URL-REDIRECT
deny tcp any host 10.1.129.8 eq www
permit tcp any any eq www
where 10.1.129.8 is a web server to provide AUP and other packages used for remediation.
Then, what not being redirected (e.g. all non-TCP-80) will subject to DACL, so we may have a DACL like this:
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit icmp any any
permit tcp any host 10.1.100.21 eq 8443
permit tcp any host 10.1.100.21 eq 8905
permit udp any host 10.1.100.21 eq 8905
permit tcp any host 10.1.129.8 eq 80
where 10.1.100.21 is the ISE PSN.
Since this sample DACL does not end with "deny ip any any" so what permitted in the interface port ACL will allow through.