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
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!
AutoFill username for Office 365 Federation
Hi. This is a simple question but I can't find a solution and ee are just getting started with our F5 implementation. I have deployed the office 365 federation using the f5.microsoft_office_365_idp.v1.1.0 iApp. I've got things working but when it redirects to my login page on the F5 the username field is blank, is this normal? is there any way to get the username from O365 and pre-populate that field? Thanks for any help JonAPM 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
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.adfs 3.0 and APM O365
We are in the early stages of the design of an adfs 3.0 implementation, and we would like to use APM to provide the functionality of the adfs proxy in our dmz. According to this article https://devcentral.f5.com/articles/big-ip-and-adfs-part-2-ndash-ldquoapmndashan-alternative-to-the-adfs-proxyrdquo It should work. However this document says that ssl termination is not an option: https://blogs.technet.microsoft.com/applicationproxyblog/2014/07/04/ssl-termination-with-web-application-proxy-and-ad-fs-2012-r2/ It is still unclear to me regarding the full ecosystem, but from what I gather a sticking point might be activesync, as the authentication for activesync will be proxied from the cloud to our adfs, and a client certificate of o365 might need to be passed to the backend adfs servers. Can anyone speak of replacing the wap/adfs proxy in adfs 3.0 implementation with F5 apm, and any possible sticking points that they have experienced? Terry
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 2016 Activation Prompt
Hello, Our organisation implemented F5 APM as the IDP for O365, using the below guide: Microsoft Office 365 SAML IdP (BIG-IP v11, v12, v13: APM) https://f5.com/solutions/deployment-guides/microsoft-office-365-saml-idp-big-ip-v11-apm However, now users are getting an office activation prompt requesting to enter their email address to activate (which works successfully). Although, previously using ADFS this would not happen, as the Office 2016 client would auto sign in and activate without requiring any user interaction. We are using the Shared computer activation model for MS Office 2016. From investigating the traffic flow, in our situation the MS Office client does not follow the redirection to the IDP URL during the activation process. Has anyone else experienced this issue? Thanks.
