You need to understand how the discovery piece of posturing works to answer some of you questions. This link has it all explained:
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.htmlPost 2.2 there are two stages to posture discovery. Stage 1 is the legacy methods that require posture redirection or require that you have reported posture before:
Probe 1 - HTTP get /auth/discovery to default gateway IP. You should remember that MAC OS devices does not have default gateway on VPN adapter. Expected result for the probe is redirect-url.
Probe 2 - HTTP GET /auth/discovery to enroll.cisco.com. This FQDN needs to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel. Expected result for the probe is redirect-url.
Probe 3 - HTTP get /auth/discovery to discovery host. Discovery host value is returned from ISE during installation in AC posture profile. Expected result for the probe is redirect-url.
Probe 4 - HTTP GET /auth/status over SSL on port 8905 to previously connected PSN. This request contains information about client IPs and MACs list for session lookup on ISE side. This proble is not presneted during the first posture attempt. Connection is protected by ISE admin certificate. As a result of this probe ISE can return session ID back to the client if node where probe landed is the same node where user has been authenticated.
So when you say your client works on wired without redirection and Call home list. That is because of #4. You have reported posture before so you aren't running a valid new client test. If you want to test a fresh client then delete your posture config file and stop and start the service. Again if I am in a Cisco environment, I prefer to use stage 1 methods with redirection to ensure the fastest possible policy server discovery.
Stage 2 was added for environment that don't support URL redirection or I guess if you don't want to configure it.
Probe 1 - During first probe AC posture module tries to establish with IP/FQDNs from "Call Home List". List of the targets for the probe has to be configured in AC posture profile on ISE side. You can define IPs/FQDNs separated by commas, with colon you can define port number for each Call Home destination. This port needs to be equal to the port on which client provisioning portal is runs. On the client side information about call home servers is located in ISEPostureCFG.xml, this file can be found in folder - C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\
Call home target might not own the session and at this stage session owner lookup needs to happen. Posture module instructs ISE to start owner lookup by using special target URL - /auth/ng-discovery, request as well contains client IPs and MACs list. After this message is recieved by PSN session lookup is first done locally. If session is not found PSN initiates MNT node query. This request contains clint IPs/MACs list, as a result FQDN of the owner should be obtained from MNT. After this PSN returns owner FQDN back to the client. Next request from client is sent to session owner FQDN with auth/status in URL and list of IPs and MACs.
Probe 2 - At this stage posture module tries PSN FQDNs which are located in ConnectionData.xml. You can find this file in C:\Users\
\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\. Posture module retrievs this file at time of first posture attempt. File contains list of ISE PSNs FQDN. Content of the list might be dynamically updated during next connection attempt. End goal of the probe is to get FQDN of current session owner. Implementation is identical to Probe 1 with the only difference in probe destination selection.
