APM Cookbook: SAML IdP Chaining
As an APM subject mater expert at F5 I often find myself in situations where a customer or colleague needs an example of a particular configuration. While most of these requests are easily handled with a call or WebEx I'm a firm believer in sharing knowledge through documentation.. and I don't like getting calls at 3 AM. If you're like me you grew up with the O'Reilly Cookbook series which served as a great reference document for various development or server configuration tasks. My goal is to create a similar reference resource here on DevCentral for those one-off scenarios where a visual example may help your complete your task. For the first APM Cookbook series I'll discuss SAML IdP chaining. Overview Security Assertion Markup Language, more commonly known as SAML, is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember... or in my experience as a security engineer the number of passwords written on a post-it note stuck to their monitor. There are two major services in a SAML environment: IdP - Identity Provider SP - Service Provider The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user's identity. F5's APM performs both IdP and SP services and allows customers to easily deploy federated authentication in their environment. In more complex scenarios you may run across a requirement where multiple SAML IdPs need to be chained together. This comes up from time to time when customers have contractors that utilize federated authentication for authorization to corporate resources. Example For our configuration we have the Globex Corporation that uses APM to authenticate uses to Office 365. Globex hire contractors from Acme Corp. who authenticate using the Acme Corp. ADFS environment. However, since Office 365 is configured to authenticate against the Globex APM we need to convert the Acme Corp. SAML assertion into a Globex SAML assertion, which is known as IdP chaining. The step ladder for this process is shown below: 1. User requests https://outlook.com/globex.com 2 - 3. Office 365 redirects user to idp.globex.com 3 - 4. idp.globex.com determines user is a contractor and redirect user to sts.acme.com 5 - 8. User authenticates using Acme credentials and is then redirect back to idp.globex.com 9. idp.globex.com consumes the Acme SAML assertion and creates a Globex SAML assertion 10. User is redirected back to Office 365 11 - 12. Office 365 consumes the Globex SAML assertion and displays the user's mail Configuration To configure your APM SAML IdP to accept incoming assertion from sts.acme.com we need to create an external SP connector. Under the Access Policy -> SAML -> BIG-IP as SP configuration section: 1. Create a new SAML SP Service 2. Export the SP metadata and configure sts.acme.com accordingly (follow your IdP vendor's documentation) 3. Click the External IdP Connectors menu at the top 4. Click the dropdown arrow on the create button and choose From Metadata (import the metadata from sts.acme.com) 5. Bind the Local SP service to the external IdP connector Now that idp.globex.com and sts.acme.com are configured to trust one another we need to configure the APM IdP to consume the sts.acme.com SAML assertion. The IdP's Visual Policy Editor should look similar to the image below: 1. The Decision Box asks the user what company they're with. This is a simple example but more elaborate home realm discovery techniques can be used. 2. The SAML Auth box is configured to consume the sts.acme.com assertion 3. Since we no longer have a login form on the IdP we need to set a few APM session variables: session.logon.last.username = Session Variable session.saml.last.identity session.logon.last.logonname = Session Variable session.saml.last.identity 4. Create an Advanced Resource Assign that matches your existing IdP Advance Resource Assign. Conclusion This particular post was a little longwinded due to the steps required but overall is a fairly simple configuration. So the next time someone asks if your F5 can do IdP chaining you can confidently reply "Yes and I know how to do that".
Office 365 iApp on 13.1.1?
I'm about to setup a Office365 webtop on 13.1.1.4, and I've noticed that the iApp does not officially support that version. According to the README the iApp only supports up to 12.0. This is the top of the README: Version: f5.microsoft_office_365_idp.v1.1.1rc1 Last modified: January 2019 iApp requires: BIG-IP version 11.3 - 12.0 The deployment guide (listing the exact version, 1.1.1rc1, of the iApp file) says "11.3 - 13.0". There's also a note in the README saying an issue was resolved in the iApp for 14.1 users, leading me to believe 13.1 should be fine: Corrected an issue that caused TCL iApps using client-ssl profiles to break when the iApp was reconfigured. This issue only affected iApps running on BIG-IP 14.1. So... am I safe using this in 13.1? The BIGIP in question is in production and it's uptime is important, I don't want to make any mistakes on this.
Office 365 iApp on 13.1.1?
I'm about to setup a Office365 webtop on 13.1.1.4, and I've noticed that the iApp does not officially support that version. According to the README the iApp only supports up to 12.0. This is the top of the README: Version: f5.microsoft_office_365_idp.v1.1.1rc1 Last modified: January 2019 iApp requires: BIG-IP version 11.3 - 12.0 The deployment guide (listing the exact version, 1.1.1rc1, of the iApp file) says "11.3 - 13.0". There's also a note in the README saying an issue was resolved in the iApp for 14.1 users, leading me to believe 13.1 should be fine: Corrected an issue that caused TCL iApps using client-ssl profiles to break when the iApp was reconfigured. This issue only affected iApps running on BIG-IP 14.1. So... am I safe using this in 13.1? The BIGIP in question is in production and it's uptime is important, I don't want to make any mistakes on this.
APM OTP not being received
We're investigating an issue where OTP isn't being recieved by users. The logging just seems to to suggest a black hole. User confirms not in junk etc. This doesn't happen all the time, it is quite sporadic. Apr 6 10:46:19 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:82caf589: Username '*removed*' Apr 6 10:46:39 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:82caf589: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr 6 10:52:54 BIGIP1 notice tmm2[22524]: 01490502:5: /Common/Citrix_XenDesktop:Common:82caf589: Session deleted due to user inactivity. A successful one reads as: Apr7 05:03:48 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Username '*removed*' Apr7 05:04:21 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Successful' from item 'OTP Verify' to terminalout 'Success' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490220:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Pool '/Common/Pool_A' assigned Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490005:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'fallback' from item 'Pool Assign ALGCTXA' to ending 'Allow' Is there any additional logging that can be put on to see what is going on with sending the OTP email? Thanks in advance
Redirect to pool to bypass SSL offloading for Exchange Hybrid setup - syntax issue(s)
Hello DevCentral Community, We recently configured a hybrid setup between Exchange2010 and O365 but we're running into issues migrating mailboxes between the two environments. After some googling and testing various 'solutions' we've narrowed down the cause. The on-prem Exchange2010 environment is behind the F5 and was setup via iApp (working great!) - when migrating a mailbox O365 connects to on-prem via the CAS MRSProxy in EWS: the issue with this is that this particular connection cannot (per MS documentation) be SSL offloaded and must make a connection directly to one of the CAS servers. I am trying to modify the current OWA redirect iRule to looks for traffic that's trying to hit the mrsproxy.svc and directs it directly to the CAS pool but I'm running into syntax issues: Error: line 1: [wrong args] [when HTTP_REQUEST when HTTP_REQUEST { if {switch -glob [string tolower [HTTP::uri]]} { "/ews/mrsproxy.svc" SSL::enable serverside pool exchange2010_cas_pool CACHE::disable return } } elseif { ([HTTP::uri] == "/") } { HTTP::redirect https://[HTTP::host]/owa/ } This is my first attempt at creating an iRule and I'm not having much luck with the syntax (and possibly other things). Could someone take a look and offer advice on how to fix this - essentially the goal is anything hitting the /ews/mrsproxy.svc goes to CAS pool directly and all other traffic follows the standard iApp behaviour to redirect (the elseif statement). Thanks!
SSL VPN Split Tunneling and Office 365
UPDATE: Apr 9, 2020 A colleague, Vinicius M. , put together a Configuration guide: Optimizing Office 365 traffic on Remote Access through VPNs when using BIG-IP APM.pdf As we shift to a much larger remote workforce than ever before, additional strains are being placed on the remote access infrastructure of many organizations around the world. Over the past several weeks we have seen organizations adapt quickly, and as it relates to APM, implement split tunneling configurations to specifically allow Office 365 traffic to egress a client's local interface instead of the corporate network via the VPN tunnel. Microsoft publishes their Office 365 endpoints (URLs & IPs) via an API but occasionally they make changes and keeping on top of those changes can be an administrative nightmare. To make the ongoing maintenance of the Network Access Lists / split tunneling configuration as seamless as possible, I’ve adapted a Python script (see GitHubRepo) we commonly use for SSL Orchestrator deployments to fetch Office 365 endpoints and update one or more Network Access Lists. Used in conjunction with iCall, this script will periodically check for and apply updates to your Network Access List(s) without any administrative intervention, allowing you to focus on other mission critical tasks. The script is maintained and documented in this GitHub repository: https://github.com/f5regan/o365-apm-split-tunnel Microsoft has provided us with a statement concerning their recommendations for Office 365 and split tunneling: "Microsoft recommends excluding traffic destined to key Office 365 services from the scope of VPN connection by configuring split tunneling using published IPv4 and IPv6 address ranges. For best performance and most efficient use of VPN capacity, traffic to these dedicated IP address ranges associated with Office 365 Exchange Online, SharePoint Online and Microsoft Teams (referred to as Optimize category in Microsoft documentation) should be routed directly, outside of the VPN tunnel. Please refer to Microsoft guidance for more detailed information about this recommendation." Microsoft’s recommendations have been incorporated into the script published in the aforementioned GitHub repository. See the changelog for details. More Resources In addition to considering how the steps in this article may relieve some strain on your organization’s remote access infrastructure, I’d highly recommend visiting How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU for further guidance on optimizing SSL VPN connections.Office 365 Tenant Restrictions
Introduction This use case allows you to access Company Office 365 resources while blocking access to personal/non-company Office 365 resources. In this scenario, SSL Orchestrator injects Microsoft "Tenant-Restriction" HTTP headers into outbound HTTP flows. The concept of Tenant Restrictions provides a mechanism to allow or deny access to Office 365 resources based on organizational requirements. For example, you may wish to allow access to Company Office 365 Outlook mail but deny access to the same resource when using a personal account. Detailed information from Microsoft on Tenant Restrictions is available here[1].In order to configure Tenant Restrictions, you need your company's ‘Restrict-Access-To-Tenants’ and ‘Restrict-Access-Context’ values.You can obtain these from the Microsoft Azure portal by signing in as the Administrator here[2]. After logging in select View under Azure Active Directory. Your Tenant Domain and Tenant ID will be shown like in the image below. Restrict-Access-To-Tenants – a value of permitted tenant lists, which is a comma-separated list of tenant domains that users are allowed to access.Any domain that is registered with a tenant can be used to identify the tenant in this list. For example, to permit access to both Contoso and Fabrikam tenants, the name/value pair would look like this: Restrict-Access-To-Tenants: contoso.onmicrosoft.com,fabrikam.onmicrosoft.com Restrict-Access-Context - a value of a single directory ID, declaring which tenant is setting the Tenant Restrictions. For example, to declare Contoso as the tenant that sets the Tenant Restrictions policy, the name/value pair would look like this: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. This article assumes you have a working SSL Orchestrator Deployment configured and wish to add Office 365 Outlook Tenant Restrictions. Steps 1. Create a Custom URL category – this will hold the Microsoft login URLs that require the Tenant Restrictions headers. 2.Create the ICAP service - the ICAP service is a flexible, transactional service type. We’ll use this as the framework for injecting Tenant Restrictions headers. 3.Create a security policy - the SSL Orchestrator security policy is the engine that maps traffic flows to actions (allow/block, decrypt/bypass, service chain). We’ll create a Security Policy that looks for the Microsoft login URLs (from the custom category) and assigns this traffic to the modified ICAP service. 4.Create an iRule - this iRule actually does the work of injecting the HTTP headers and will be applied to the modified ICAP service. 5.Test the Tenant Restrictions Step #1 Create a custom URL category From the SSL Orchestrator Configuration screen select Policies > URL Categories Click Create Give it a Name, Office365 in this example Uncheck the box for Global Pattern Match.Add all of the following: https://login.microsoftonline.com/ https://login.microsoftonline.com https://login.microsoft.com/ https://login.microsoft.com https://login.windows.net/ https://login.windows.net Click Finished when done Step #2 Create an ICAP Service in existing Topology From the SSL Orchestrator Configuration screen select Services then click Add Note: if you do not have a Topology created you can still use this guide and create the ICAP Service at the time the Topology is created.The order of events will be slightly different. Scroll to the bottom, select Generic ICAP Service and click Add Give the ICAP Service a name, Office365_Tenant in this example.For ICAP Devices click Add. Enter an IP Address, 198.19.97.1 in this example and click Done. Note: the IP address you use does not have to be the one above.It’s just a local, non-routable address used as a placeholder in the service definition.This IP address will not be used. IP addresses 198.19.97.0 to 198.19.97.255 are owned by network benchmark tests and located in private networks. Scroll to the bottom and click Save & Next. On the next screen click Add to create a new Service Chain Give it a name, O365_Service_Chain in this example.Select your existing Services and click the right arrow to move them to Selected.Add the ICAP Service last. Note: It’s important to know why you’re creating a new Service Chain. The custom category will be applied to a Security Policy rule to match on requests for specific Office 365 login URLs. If that condition matches, the traffic must be intercepted (decrypted), and sent to a Service Chain with the Office 365 Service. Multiple Services can be in this Service Chain. However, if you put the Office 365 Service in any other service chain, the tenant restrictions headers will be sent to other sites incorrectly. It should look like the following.Click Save. Note: the new Service Chain should look like your previous Service Chain with the addition of the Office365 ICAP Service at the end.It is important to do it this way to ensure Login activity to Office 365 is still inspected. Click Save & Next Click Deploy You should receive a Success message. Step #3 Create a security policy From the SSL Orchestrator Configuration screen select Security Policies then click on the name of the Policy to edit, ssloP_Secure_Outbound this example. Click the Add button to add a new rule Name the Rule, O365_Tenant_Restrict in this example.Under Conditions click Select and choose Category Lookup (All). Choose the Custom Category created previously, Office365 in this example.Type the name into the field and it will filter the results. Set the Action to Allow.For SSL Forward Proxy Action select Intercept.Set the Service Chain to the one created previously, O365_Service_Chain in this example. Note: it is critical that the Action be set to Intercept so SSL Orchestrator can decrypt the connection and insert the Tenant Restriction headers. Scroll down and click Deploy at the bottom The changes should be successfully deployed Step #4 Create an iRule From Local Traffic select iRules > iRule list Click Create on the Right Give the new iRule a name, TenantRestrictions in this example Enter the following for the Definition: when HTTP_REQUEST { HTTP::header replace Restrict-Access-To-Tenants "f5labs.com" HTTP::header replace Restrict-Access-Context "ee3dfd2f-6a3b-40d1-9be0-bf8327d81d90" } Note: The restrict-Access-To-Tenants header should contain your Tenant’s domain(s), comma-separated if more than one.Example: “contoso.onmicrosoft.com,fabrikam.onmicrosoft.com” The Restriction-Access-Context header must contain the Tenant ID as shown in the Azure Portal. Click Finished From the SSL Orchestrator Configuration screen select Services.Click the padlock to Unprotect Configuration. Note: Disabling Strictness on the ICAP Service is needed to modify it for Tenant Restrictions header insertion.Strictness must remain disabled on this service, and disabling strictness on the service has no effect on any other part of the SSL Orchestrator configuration. Click OK to Unprotect the Configuration From Local Traffic select Pools > Pool List Select the Office365_Tenant Pool Under Active Health Monitors select tcp and click >> to move it to Available Click Update Note: The Health Monitor needs to be removed because there is no actual ICAP service to monitor. From Local Traffic select Virtual Servers > Virtual Server List Locate the Office 365 ICAP service that ends in “-t-4” virtual server and select it Set the Request Adapt Profile and Response Adapt Profile to None to disable the default ICAP Profiles Click Update at the bottom Click the Resources tab Click the Resources tab >Manage Select the iRule created previously, TenantRestrictions in this example and move it to the left under Enabled Click Finished Step #5 Test the Tenant Restrictions Attempt to login to https://outlook.office.com with your Tenant Restrictions domain. Note: you must attempt to login with an email address and password in order to see the following error page: Footnotes: [1] Detailed information from Microsoft on Tenant Restrictions https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions [2] Microsoft Azure portal https://portal.azure.com/SSL Orchestrator Advanced Use Cases: Office 365 URL Management
Introduction F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases. If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility. SSL Orchestrator Use Case: Office 365 URL Management If you're reading this article, it's a good bet that your organization relies on Office 365 for your Office productivity, email, and/or collaboration tools. It's also a good bet that you're concerned about encrypted malware, and thus how to deal with malware that sneaks its way into Office 365. Given the shear number of products available to address it, it shouldn't take much to convince you there's a potential threat there. Of course, the service itself is not inherently insecure. But within Office 365, you create, manage and share documents, and send and receive emails with attachments. The issue is that the documents and attachments themselves are malware vectors, and email phishing attacks are hard to catch. Moreover, as the bulk of that traffic is all encrypted, you're faced with a dilemma. Do you rely solely on Microsoft's security to protect your organization, or endpoint security tools? Hopefully your answer is a resounding 'no' to both of these, and that you do indeed decrypt and inspect in active defense against malware and data exfiltration. But therein lies another problem. What and when do you decrypt? What about Office 365 components that don't play well with decryption tools, or where Microsoft recommends to bypass decryption for the sake of performance? At a most recent count, Office 365 encompasses around 350 unique resource URLs, and roughly 160 IPv4 and IPv6 addresses. These URLs represent the different Office 365 services, and are dynamic (i.e. frequently changing). So then I will ask again. What and when do you decrypt and inspect Office 365 traffic based on the revelation that not all Office 365 URLs should be managed the same way, and they're ever-changing. If at this point you're still not completely clear on the complexity of this scenario, that's okay. I'll refer you to a few Microsoft resources that go into great detail on the subject: https://techcommunity.microsoft.com/t5/office-365-blog/announcing-office-365-endpoint-categories-and-office-365-ip/ba-p/177638 https://techcommunity.microsoft.com/t5/office-365-blog/getting-the-best-connectivity-and-performance-in-office-365/ba-p/124694 https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide Microsoft also now tags URLs with an internal category system, as defined here: https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#new-office-365-endpoint-categories Those categories are: Optimized URLs - endpoints required for connectivity to every Office 365 service, and the most sensitive to network performance, latency and availability. Allow URLs - endpoints required for specific Office 365 services, but not as sensitive to latency as the Optimized URLs. Default - endpoints that represent Office 365 services that do not require optimization. Fortunately, F5's SSL Orchestrator can provide an elegant solution to this complex problem. Intelligent traffic classification allows you to define rules that can be used to control availability (allow or block), decryption (intercept or bypass), and steering through dynamic sets of security devices (service chaining). Bypassing TLS decryption on an Office 365 resource can be as simple as a single rule that matches on all Office 365 URLs. Or, you can decrypt some and bypass others, as Microsoft recommends. And you can choose to pass traffic through the service chain of security devices irrespective of decryption. Managing Office 365 URLs To make all of this work, you first need the Office 365 data source. As previously illustrated, Office 365 URLs and IP addresses are dynamic, updating roughly every 30 days. This feed isn't built into the BIG-IP, but there's an easy way to add it with a simple Python script: https://github.com/f5devcentral/sslo-o365-update Basically, a Python script is configured to run periodically on your BIG-IP to keep local custom URL categories and/or data groups in sync with the Office 365 URL source. These collections can then be consumed natively by the SSL Orchestrator security policy. You can then use these new URL categories as you would anything else in the security policy, like bypassing decryption for the set of "optimized" Office 365 URLs, or perhaps bypassing a proxy security device in an SSL Orchestrator decrypted service chain. Figure 1: SSL Orchestrator security policy with O365 category rule The Github repo has all of the instructions, but setup is pretty straightforward: Download the Python script - download on both devices in an HA pair: curl -k https://raw.githubusercontent.com/f5devcentral/sslo-o365-update/main/sslo_o365_update.py -o sslo_o365_update.py Install the script with the --install flag, and provide an interval for the script to run: python sslo_o365_update.py --install 3600 When the installation is complete, edit your SSL Orchestrator security policy and add a traffic condition to match on one of the new Office 365 managed URL categories. That's it. In a HA pair, the script runs independently on each unit. If you need to make adjustments to the configuration, jump on a BIG-IP console/SSH session and edit the json config data as described in the repo: tmsh edit sys file ifile o365_config.json If you mess something up or just want to rebuild, run the script again manually with the --install flag (and time interval). You can configure the script to: Create all or some of the URL categories, for different customer endpoints and different service areas Create just data groups and/or just categories Manage just URLs and/or just IPs Include and exclude URLs and IPs. ** Note that you will also need to configure system DNS and a gateway route on the BIG-IP to access this remote Microsoft content. ** And there you have it. In just a few steps you've configured your SSL Orchestrator security policy to identify and take action on the dynamic set of Office 365 URL/IP resources, and along the way you have hopefully recognized some of the immense flexibility at your command.F5 APM VPN Support For Microsoft O365 Split-Tunneling
We ran into a significant issue with remote VPN client performance when our Microsoft Office products moved to the O365 cloud offering. Our current limitation of "no split-tunneling" per corporate policy, prevented our users from establishing connectivity to their geographically preferable O365 cloud. Instead, their traffic could/would route back to the corporate F5 APM VPN BigIP and then out to the internet. Much longer path and real-time services such as Teams/Skype calls suffered greatly. Other vendors were also having issues with this such as ForcePoint (Websense) and McAfee. Those vendors released O365 specific patches to permit a better performance through various rules and methods. Our F5 APM VPN was the bottle-neck and we had to address this quickly. Approval was granted to permit ONLY O365 products to be split-tunneled. Luckily, Microsoft has fielded this question/requirement many times and they had a ready answer: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges Unfortunately, there's +500 IPv4 networks alone. Many are overlapping and some could be combined into a supernet. Not pretty, but workable. Using node.js, we developed a script that will pull-down the Microsoft IPv4 space, perform a CIDR clean on the networks, log into the F5 BigIP and push the Network Access exclude IP list, then apply the Access Policy in one shot. You can see the repo here: https://github.com/adamingle/f5O365SplitTunnelUpdateScript If you'd like to use the repo, please note the "settings.json" file. You will need to update according to the README.md Additionally, you will need to configure the allowable/tunneled traffic for the Network Access on VPN. If you only specify the exclusion space, there will be no inclusion space and no traffic will traverse the tunnel. Enable split-tunneling by checking the "Use split tunneling for traffic" radio button Add ALL networks to the "IPV4 LAN Address Space" with the IP Address 0.0.0.0 and Mask 0.0.0.0 Specify wildcard/asterisk for the "DNS Address Space" After you have the split-tunneling enabled on your Network Access Lists in F5 APM and you have correctly modified the "settings.json" file of your local f5O365SplitTunnelUpdateScript repo, you should be able to execute your O365 split-tunneling address exclusion changes. Use Jenkins or other automation tool to run the script automatically. Definitely worth a watch: https://channel9.msdn.com/Events/Ignite/2015/BRK3141 *This has been tested/used successfully with the Edge 7.1.7.1 client on v13.1.1
