VPN with Office 365

[SkeletonManGabe]

Good morning, I wanted to reach out and see how others are accomplishing the setup I'm looking to do. 

In our organization, I'm trying to force all O365 traffic through our split vpn tunnel setup. I've applied the IP ranges here to my split tunnel policy on my firewall to force all O365 traffic towards our VPN tunnel instead of through a remote worker's home internet. 

When looking on the firewall logs, I can see that my VPN traffic for office.com connections are definitely going through my split vpn tunnel policy however whenever I look at Sign In logs on my Azure AD within O365, I still see my connections establishing from my home IP address rather than my corporate IP address.

How are others solving this problem? Do you simply do a full tunnel? We are doing this to help with our multi-factor setups for our end users. Not all end users have company provided phones so we aren't forcing them to install an authenticator app on their personal phones and by forcing all O365 traffic through our tunnel, we are able to setup policies in Azure AD to restrict users to only our public IP's and thus reducing the need for multi-factor for those users as they would be blocked anywhere outside of those few IP's. 

Thanks in advance for any advice.

[gfleming]

This is a perfect use-case for the Internet Services Database (ISDB). If you select "Microsoft-Office365.Published" you will split tunnel all traffic to anything related to MS365. The ISDB is always updated by Fortiguard, as well.

[SkeletonManGabe]

Thanks Graham, that'll be great instead of checking back and updating my lists.

I've created an additional split tunnel policy to take place first before any other policy for VPN, logged off all of my office products and then logged off the VPN. Established a new VPN session, opened office.com, authenticated and then opened Outlook, word, etc... 

I can see my VPN IP sending office logs over the new policy, however when I look in sign-in logs within Azure AD for those new sign-ins, it still shows my home internet IP as the IP that was used rather than my corporate IP's for the split tunnel policy. I'm baffled by this. Short of utilizing a full tunnel for VPN instead of split, I'm not sure how else to accomplish this. 

When I had a ticket open with support, they didn't indicate anything about the ISDB you provided so I'm not sure how to proceed to get this completed. Thanks!!

[gfleming]

When I go to sign in to office.com I am taken to login.microsoftonline.com. This domain and associated IP ranges is covered in the aforementioned ISDB entry.

I'm not sure what else might be occurring for you.

It would probably be best as next step to run a packet capture on your machine and see if you can look at which IP is being used to handle the authentication and confirm if its in the ISDB database.

[gfleming]

For the sake of experimentation I created a policy on my FortiGate that only allowed my computer access to certain ISDB addresses and then tried logging on to office.com.

I had to enable the following entries to make it work:

Microsoft-Office365

Microsoft-Web

Akamai-CDN

Microsoft-Azure

If you want to narrow it down I will leave it up to you to continue experimenting. :)

[SkeletonManGabe]

Do you have access to sign in logs within Azure AD for your company? That's where I'm seeing the problem. I don't see any issue with my actual getting connected and do see all sorts of "office 365" related traffic go over my newly created ISDB policy. I only see the problem when looking at the sign in logs and can see that my IP I'm presenting to Office 365 is my home IP and not my corporate IP. So, it won't fix my problem that I'm looking to solve with restricting users to only connect to O365 from within our few Corporate IP's even when connecting in via the VPN. Staff with multifactor setup can connect wherever and that isn't an issue.

I'm thinking I may need to go away from the split tunnel and just do a full tunnel to capture all traffic and see what that looks like. 

Thanks so much for your advice, information and testing for me, I do really appreciate it. 

[gfleming]

I don't think you understand how my experiment worked. I blocked all traffic for my endpoint except for those four ISDB entries. I was able to log in to Office.com.

This means login traffic matched one of those four ISDB entries. This means if your split tunnel policy includes those four entries, the login traffic will go across the VPN.

[SkeletonManGabe]

I understand that completely, however when going to Azure AD and looking at the sign-in logs, it still reported my home IP address rather than my corporate public IP address. 

I ended up disabling split tunnel to correct the issue. We only have about 10 users at maximum that remote in at a time and resources don't seem to be an issue. Thanks again for your time looking at it. 

[gfleming]

OK so just to confirm you set up your split tunnel policy and included all four of those listed ISDB entries in the policy? And it still showed login from your home public IP address?

If so there's probably something else going on and will be worth troubleshooting if you want to get split tunnel working still.