We are seeing a lot of packet over the VPN tunnel with split tunneld enabled.
We only see packet loss when a destination hits and ip address that's in the split tunnel list and then we only see packet loss to connection that goes over the tunnel.
by default we are only split tunnel stuff that needs to go out locally on the end users internet, like O365 products. Does anybody has any idea what the issue can be? If we disable split tunnel we don't see packet loss.
@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.
We deny all traffic over the physical interface except the subnets and FQDN lists in the split tunnel list.
We now discovered that the issue is related due to FQDN in the split tunnel list. If we remove the entire FQDN list, no traffic is dropped anymore nor we see high latency.
This is weird behaivor in my opinion.
@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?
At the moment most of the users are on 9.1R9. I'm testing with 9.1R11.
We only split tunnel on subnets now. We deny access over the tunnel for next subnets.
13.80.125.22
13.91.91.243
13.107.6.0/23
13.107.9.0/24
13.107.18.0/24
13.107.140.0/24
20.190.128.0/21
40.81.0.0/16
40.90.218.0/24
40.96.0.0/12
52.120.0.0/14
52.174.56.180
52.183.75.0/24
52.184.165.0/24
52.238.106.0/24
52.238.119.0/24
52.244.0.0/16
52.247.150.0/24
104.42.230.0/24
131.253.33.0/24
204.79.197.0/24
13.107.128.0/22
13.107.136.0/22
104.146.128.0/17
52.96.0.0/14
13.107.64.0/18
132.245.0.0/16
150.171.32.0/22
150.171.40.0/22
191.234.140.0/22
23.103.160.0/20
52.104.0.0/14
52.112.0.0/14
@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?
[email protected] to be able to see the issue you need to apply the FQDN list so don't allow any of the names going over the tunnel. We experienced high latency and packet loss for traffic that was going over the tunnel. (other traffic that was allowed going over the tunnel) So other traffic was experiencing issues that had nothing to do with the split tunnel list.
login.live.com
login.msa.msidentity.com
prda.aadg.msidentity.com
*.api.microsoftstream.com
api.microsoftstream.com
web.microsoftstream.com
*.lync.com
*.broadcast.skype.com
broadcast.skype.com
*.skypeforbusiness.com
*.sfbassets.com
*.urlp.sfbassets.com
*.trafficmanager.net
*.keydelivery.mediaservices.windows.net
*.streaming.mediaservices.windows.net
ajax.aspnetcdn.com
mlccdn.blob.core.windows.net
aka.msamp.azure.net
*.users.storage.live.com
*.adl.windows.com
*.skypeforbusiness.com
*.spo-msedge.net
*.msedge.net
*.a-msedge.net
*.b-msedge.net
*.c-msedge.net
*.e-msedge.net
*.m-msedge.net
*.k-msedge.net
*.s-msedge.net
*.mstea.ms
*.secure.skypeassets.com
mlccdnprod.azureedge.net
*.tenor.com
*.skype.com
*.cloudapp.net
weu.trouter-teams-prod.akadns.net
*.microsoft.com.akadns.net
*.online.office.com
*.officeapps.live.com
office.live.com
*.cdn.office.net
*.onenote.com
*.microsoft.com
*.msecnd.net
*.office.net
outlook.office365.com
outlook.office.com
*.outlook.office.com
splm.onmicrosoft.com
splm.sharepoint.com
splm-my.sharepoint.com
splm-files.sharepoint.com
splm-myfiles.sharepoint.com
siemens.onmicrosoft.com
siemens.sharepoint.com
siemens-my.sharepoint.com
siemens-files.sharepoint.com
siemens-myfiles.sharepoint.com
[email protected] To answer your question regarding the 52.11x.xxx.xxx.
I only see this traffic going out over the physical interface.
@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.