Blocking iOS 6.1 Devices on Exchange 2010

Hi Dan,

 

 

Thanks for the info. I thought the main iOS 6 bug with Exchange meetings was fixed in 6.0.1. Are you still seeing issues with iOS 6.1 clients?

 

 

http://news.cnet.com/8301-13579_3-57543794-37/apple-releases-ios-6.0.1-with-over-the-air-update-tool/

 

 

Aaron

Hi Aaron,

 

 

This is a newly discovered issue with iOS 6.1, more details (http://www.windowsitpro.com/blog/tony-redmonds-exchange-unwashed-50/exchange-server/apple-ios-61-upgrade-excessive-transaction-log-growth-145223)

 

 

Subsequently we have re-opened our environment to iOS 6.1 devices but disable the Meeting Response ActiveSync command from 6.1 devices as this appears to be the cause. The code below puts the effected devices calendar into Ready Only mode until Apple release an update.

 

 if {[HTTP::header "User-Agent"] matches_regex {^Apple.*1002.*} } {
 if { [HTTP::uri] contains "Cmd=MeetingResponse" } { 
reject 
}
 }

Please use this at your own risk.

 

 

Dan.

 

I'm a newb - Where do I add this code? I haven't seen our logs grow abnormally yet - but I'd like to use it just incase... I'm just not experienced enough to know where to put it. Guidance please?

 

 

Thanks in advance!

Posted By Gleep52 on 02/08/2013 10:51 AM

 

I'm a newb - Where do I add this code? I haven't seen our logs grow abnormally yet - but I'd like to use it just incase... I'm just not experienced enough to know where to put it. Guidance please?

 

 

This is iRule code for an F5 LTM virtual server. (This post has been referenced externally in several places now so people reading might not be aware this discussion is specifically referring to using iRules on F5 BIG-IP:LTM in front of Exchange).

 

This is just a snippet of code as well, it needs to be encapsulated in the HTTP_REQUEST event to form a complete iRule to be added to the virtual server. Gleep52, if by chance I have misinterpreted your request and you still need assistance with forming this into a complete iRule on an LTM, please post back.

 

when HTTP_REQUEST  {    
if {[HTTP::header "User-Agent"] matches_regex {^Apple.*1002.*} } {
if { [HTTP::uri] contains "Cmd=MeetingResponse" } { 
log 10.10.10.1 local0.info "Denied iOS 6.1 Device SNAT src=[IP::client_addr] src_port=[TCP::client_port], snat_src=[IP::local_addr] snat_src_port=[TCP::local_port], dst=[IP::server_addr] dst_port=[TCP::server_port]"
reject 
}
}  
}
 

Above is the complete iRule we placed in the TMG virtual server. We see several client IP's that are looped with above 60,000 denies and it goes down from there to about 7 cilents with denies above 3,000 the rest are below 300.

You have to know where to place this iRule in terms of execution order since there are other iRules running on the Exchange single virtual.

 

 

The easiest way is to give it higher priority than existing iRules used with the Exchange virtual.

 

By default an iRule event has a priority of 500. The lower the better, so we give this one a priority of 100.

 

 

To do that, add this command : "priority 100" before balias's irule above. So you get this:

 

 

priority 100

 

when HTTP_REQUEST {

 

if {[HTTP::header "User-Agent"] matches_regex {^Apple.*1002.*} } {

 

if { [HTTP::uri] contains "Cmd=MeetingResponse" } {

 

log 10.10.10.1 local0.info "Denied iOS 6.1 Device SNAT src=[IP::client_addr] src_port=[TCP::client_port], snat_src=[IP::local_addr] snat_src_port=[TCP::local_port], dst=[IP::server_addr] dst_port=[TCP::server_port]"

 

reject

 

}

 

}

 

}

 

 

 

See this Excellent article for information about iRule Events and Event priorities: https://devcentral.f5.com/tech-tips...RfEYlFAWdk

 

 

 

For anyone new to F5 LTM.

 

 

Copy iRule above.

 

 

Connect to BigIP GUI. Go to "Local Traffic/IRules". Choose "Create" at far right. Enter a name for iRule. (no spaces)

 

 

Paste iRule in input box then Hit Update.

 

 

Go to "Local Traffic/Virutals", a list of virtuals appears. Locate the Exchange virtual, Click on "Edit" under Resources Column at the far right side of screen.

 

 

IRule section appears. (middle of screen), click on "Manage" far right of screen. Add the recently created iRule.

 

 

HTH.

 

John,

 

 

We implemented the iRule as you suggested and saw an immediate drop in the thrashing of our transaction logs. Thanks for the great write up!

 

 

Jason Ford

First of all thank you for the iRule, we will implement it in our environment as well.

 

But does anybody knows the User-Agent for iOS 6.1.1, because I heard that the bug is not solved in this version. Is it also starting with 1002 and only the number behind the dot is different (I think so due to minor release).

 

Thank you!

 

 

Ciao Stefan :)

 

Hi Stefan,

 

 

Yes this solution does block iOS 6.1.1 as most of 6.1 was between 1002.140 > 1002.144 with 6.1.1 being .145. Until Apple clearly state the Exchange Bug has been resolved we will continue to use this interim soluion.

 

 

-Dan

 

I registered to this group as "Jealous" because we don't have an F5 switch but maybe wish we did to be able to solve this issue...

 

 

A couple questions: Are you using SSL with ActiveSync? If you are, how is the F5 able to read the HTTP headers to reject the requests?

 

 

We've considered using Snort to shun the requests but cannot read the packets because they are encrypted with SSL.