Hello @Kieran Mckay,
We understand that you're experiencing an issue where GSA logs show traffic to on-prem resources like RDP and SMB, but the traffic fails to load.
To simplify troubleshooting, if you know the target IPs and ports that your app should be connecting to, you can filter the logs by these parameters to remove irrelevant traffic. For instance, if you're troubleshooting RDP connections, you could filter by "Destination Port == 3389." If you're unsure of the destination IPs or ports, you can filter by the process name, such as "mstsc.exe" for RDP traffic.
Some applications may require connectivity to multiple services with various destination IPs, ports, or protocols (TCP or UDP). It’s common to encounter scenarios where application traffic is being tunneled via segments (defined under Forwarding Profiles) but some destinations may be missed. If you know the application’s process name, you can filter by it and remove the default Action==Tunnel filter. This will help you identify any traffic the app is attempting to send that is being overlooked by the current rules.
For example, by removing the default Action==Tunnel filter, adding a process name filter, and reproducing the issue, you might notice that mstsc.exe tries to connect to the RDP server on port 3389/UDP. However, the GSA client might determine that this traffic should be bypassed because it doesn’t match a forwarding profile rule. In some cases, missing traffic can be harder to detect because the connection is initiated by a process other than the application itself.
Sharing relevant documents for more information: https://microsoft.github.io/GlobalSecureAccess/Troubleshooting/WindowsClientTroubleshooting/#packets-not-seen-by-the-gsa-client
Hope this helps. Do let us know if you any further queries.
Thanks & Regards
Janaki Kota
If this answers your query, do click Accept Answer
and Yes
for was this answer helpful. And, if you have any further query do let us know.