macOS developers successfully tested out accessing ZTNA segment applications via WSS Agent.
ZTNA admin pushed solution out to Windows users.
Windows users can access web sites via Cloud SWG, using this WSS Agent, but cannot access any ZTNA segment applications.
Segment applications accessing SQL back end servers seeing connectivity errors from client, and Web browsers seeing standard browser connectivity errors accessing ZTNA protected web servers - no custom errors reported back from ZTNA.
Accessing the same TCP or Web applications via the ZTNA portal from users not running the WSS Agent on Windows works fine.
Cloud SWG.
SAML Authentication.
ZTNA.
Segment based Applications.
MCU=1 enabled on the Windows WSS Agents.
Make sure that the Windows WSS Agents are installed with MCU=0 (default).
From Symdiag, the PCAPs show the requests to the back end Segment application (Secure Web server on 10.0.10.9) going out the PUBLIC and not TUNNEL interface. If any network level access control blocks the TCP communication internally, the connectivity will fail as shown below:
The policy pushed down to the Agent does appear to include the
The marked IP addresses, which are used by WSS Agent to flip bits in IP header does have the correct destination segment Application IP address
"markIpAddresses": [
:
"10.0.10.9/32",
:
],
The WSS Agent debug logs available to Broadcom support shows that the requests destined for this destination are unauthenticated, when the user has successfully authenticated.
Looking at the WSS Agent diagnostic logs gave a clue as to what was going on - multiple users were trying to login to the host at the same time, indicating that Agent was installed with MCU=1.
[07-16-2024 13:59:22 (UTC+1:00)]: CTC Response: ACTIVE(GEOIP) egress: #.#.#.# GGBLO-148.64.28.164 GGBDO-170.176.242.164 geolocation: UK
[07-16-2024 13:59:22 (UTC+1:00)]: Cloud Firewall Services: Enabled
[07-16-2024 13:59:22 (UTC+1:00)]: Attempting to connect to GGBLO via UDP
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#59(non-interactive-user): connecting to 148.64.28.164
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#59(non-interactive-user): status:SUCCESS-authorized
[07-16-2024 13:59:22 (UTC+1:00)]: Tunnel#59(non-interactive-user) connected to concentrator: 148.64.28.164 (GGBLO-UDP), Nat IP: 10.174.154.219, RcvBuf: 2097152
[07-16-2024 13:59:22 (UTC+1:00)]: Connection to WSS successful - Tunnel#59
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#60(User1): connecting to 148.64.28.164
[07-16-2024 13:59:22 (UTC+1:00)]: Tunnel#60(User1) connected to concentrator: 148.64.28.164 (GGBLO-UDP), Nat IP: 10.53.159.23, RcvBuf: 2097152
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#61(User2): connecting to 148.64.28.164
[07-16-2024 13:59:22 (UTC+1:00)]: Tunnel#61(User2) connected to concentrator: 148.64.28.164 (GGBLO-UDP), Nat IP: 10.45.162.152, RcvBuf: 2097152
[07-16-2024 13:59:22 (UTC+1:00)]: Waiting for user authentication (User1)
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#62(User3): connecting to 148.64.28.164
[07-16-2024 13:59:22 (UTC+1:00)]: Tunnel#62(User3) connected to concentrator: 148.64.28.164 (GGBLO-UDP), Nat IP: 10.46.161.175, RcvBuf: 2097152
[07-16-2024 13:59:22 (UTC+1:00)]: Waiting for user authentication (User2)
[07-16-2024 13:59:22 (UTC+1:00)]: CA Tunnel#63(User4): connecting to 148.64.28.164
[07-16-2024 13:59:22 (UTC+1:00)]: Waiting for user authentication (User3)
[07-16-2024 13:59:22 (UTC+1:00)]: Tunnel#63(User4) connected to concentrator: 148.64.28.164 (GGBLO-UDP), Nat IP: 10.169.148.207, RcvBuf: 2097152
[07-16-2024 13:59:22 (UTC+1:00)]: Waiting for user authentication (User4)
[07-16-2024 13:59:24 (UTC+1:00)]: Authentication succeeded (User3)
[07-16-2024 13:59:24 (UTC+1:00)]: Block notification channel connecting - Tunnel#62(User3)[11]
[07-16-2024 13:59:50 (UTC+1:00)]: Block notification channel connected - Tunnel#62(User3)[11]
The Application generating the request to the secure Web server was the non-interactive-user and hence was bypassing the WSS Agent tunneling.