cancel
Showing results for 
Search instead for 
Did you mean: 

Traffic not honouring the split tunnel configuration.

Pulse-60bpm
New Contributor

Traffic not honouring the split tunnel configuration.

Hello, on Friday 19th, I implemented split tunnelling for O365 as per the Pulse documents and latest MS docs.  All seems to be going well and we have seen a noticable improvement in the Throughput and CPU usage of our 5K appliance.  However,  I have noticed that despite the rule in place, I still see quite a large amount of TEAMS traffic trying to traverse the VPN, where it will be proxied by the on prem proxy.  We are having a few authentication issues with our proxy today and as a result this has impacted on teams.   The destination I noticed in wireshark that was still traversing the VPN was  

neu1-api-teams.cloudapp.net [52.113.205.119] this should be covered by the 52.112.0.0/14 network and the two FQDN's *.teams.microsoft.com and teams.microsoft.com

Does anyone have any suggestions as to why the traffic is still traversing the VPN?
4 REPLIES 4
elevator4
Occasional Contributor

Re: Traffic not honouring the split tunnel configuration.

Your post caught my eye, as I've been involved in split-tunneling O365's "optimized" category on Pulse as well. Unfortunately I don't really have an answer for you (sorry), but I will share what I'm seeing as there is some weirdness (similar to what you describe).

 

Both 52.112.0.0/14 and 52.120.0.0/14 are set to be excluded from the tunnel on our policy.
Out of curiousity, I did some investigation and noticed that for users on Pulse with Split-Tunneling setup for O365, I see nbname traffic (udp 137) is still using the tunnel back to the data center [no idea if that traffic is important or used], but tcp traffic (essentially just 443) is being split-tunneled as desired (based on wireshark captures).  I also see some the udp 3478-3481 traffic coming back to the data center, when I expect that to be split-tunneled based on configuration.  Kinda strange.  I wouldn't expect protocol (tcp, udcp, icmp, etc) to play any role in how the traffic is routed...it should just get routed all the same!  Especially since it's the split-tunneling policy is set via IPv4 for this, so no FQDN bugs at play.

 

I would say the bulk of the traffic to these 52.112.0.0/14 and 52.120.0.0/14 subnets is in fact being split-tunneled and going straight to O365 and we have performance gains because of this -- however there's still some traffic coming back via tunnel as you mentioned.  Not sure why that is!  Certainly would like to hear others' comments or ideas as to why.

Pulse-60bpm
New Contributor

Re: Traffic not honouring the split tunnel configuration.

Cheers @elevator4 , It is the exact same senario, it is clear that in best, the split tunnelling IS working because the performance gains have been phenominal (not sure I've ever typed that word...)  But what made me query this, was due to the fact that we had an authentication issue with our Fortigateway / Web filter that was no automatically picking up authenticated users from AD/FSSO so everyone was being asked to re-authenticate..  This seemed to be having an adverse effect on our users being able to use teams, we'd either get a message saying that we weren't connected, or, the pressence side of things wasn't working (available, busy etc) or we couldn't send chat. (Video and audio seemed to not be affected)  I had also played with persisten routes on the routing table to ensure that the traffic was destined to the correct gateway, but launching teams seemed to overwrite some of the addresses that would fall into the 52.112.0.0/14 network and send them out over the VPN...    I agree, hearing from others would be great.  Thanks for your message.

zanyterp
Moderator

Re: Traffic not honouring the split tunnel configuration.

while it should be covered by the rule in place, can you test with adding the *.cloudapp.net rule?
Microsoft also recommends using IP-based rules rather than FQDN for handling this…though I am not sure why the rules are not triggering as expected. is it possible that the proxy is triggering the unexpected behavior?
if you have not already done so, please open a case with our support team
r@yElr3y
Moderator

Re: Traffic not honouring the split tunnel configuration.

@Pulse-60bpm @elevator4

 

Reference - https://community.pulsesecure.net/t5/Pulse-Connect-Secure/Packet-loss-over-tunnel-with-splittunnel-e...

 

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.

PCS Expert
Pulse Connect Secure Certified Expert