@bartley If you're seeing O365 traffic sent through the VPN tunnel, then I'd say it's expected to see such behavior as the non-sensitive traffic still continue to use tunnel where the rest of the traffic (sensitive to latency) will use physical interface.
When using application like MS TEAMS, I have seen issues where the Split tunnel DENY resources are passing through both interfaces (known issue with TEAMS app). MS recommendation is to block access to certain TCP/UDP ports to fix that issue.
@bartley Removing FQDN split tunnel policies and making the tunnel mode as FULL works without any issues?
As per Microsoft, Split tunnel deny would make the high-sensitive traffic to go out using the physical interface and rest of the non-sensitive traffic continue to use the VPN tunnel and that should not cause any delays with the O365 applications.
what version of pulse client being used? is it 9.1R8.2 or above?
@bartley Thank you for sharing the details. I have used the same list in my lab and did not face any issues with my Teams application (replication is only with Teams app, did not test other office apps).
However, intermittenly noticed packets sent to destination 52.11X.XX.XX (part of 52.112.0.0/14) through both virtual and physical interface at the same time i.e. somehow MS TEAMS is not honoring the route table and sends the traffic using all active interfaces.
Are you seeing the same behavior in your environment?
@bartley Correct! You're seeing the same behavior. Though split tunnel is enabled, which adds the most matching route on the client machine'r route table, MS TEAMS continues to use all active interface for communication. This is under investigation by MS, as informed by MS support.
