HTTPS Timeout for MSFP (exchange direct push)

...not that I want to be a pain in the ass but I wrote this question to this forum instead of opening a call because I think this concerns many many of the asl users in the near future when more and more windows mobile 5 devices will get the acu2 update.

Now heres the problem AGAIN: even if the internal webserver is set to allow connections with a timeout of half an hour my asl 6.200 won´t for some reason keep the connection open this long.

This issue has to be adressed because the first vendor (imate) already published acu2 and t-mobile (germany) will follow these days.

this is trange, I got 4 (!!) private mails of people having the same question and also escalated this to astaro but won´t get a solution. BTW in the past astaro staff was present in this forum nearly around the clock - nowadays things changed I guess..

I´m not shure if this helps but you might try to change the value read_timeout in /var/chroot-squid/etc/squid.conf-default and restart the squid after that with /var/mdw/scripts/squid restart

I´m not shure if this helps but you might try to change the value read_timeout in /var/chroot-squid/etc/squid.conf-default and restart the squid after that with /var/mdw/scripts/squid restart

Hurray, now you have enough time to fill up the connection table to mount a DOS attack.

Please his help immediately, https webadmin I could not be opened to pc client, requested his guidance. please...
or please contact to davkaboy@yahoo.com

Hurray, now you have enough time to fill up the connection table to mount a DOS attack.

Very helpfull. hope that your other comments are more valuable

@Joerg: Have you solved the problem or any idea where to look?
I got the same problem and haven't found any solutions yet.

Regards
Martin

Microsoft recommends to configure their ISA to use a timeout for this special HTTP listener of 1800 seconds.

ISA server has a reverse proxy that Astaro does not have therefore there is no increasing connection timeout for http or https incoming connections. Squid implementation that comes with astaro only does forward proxy. 

 Now as far as I thought how MSFP worked was that the cell phone sends a ping to the exchange server that replies to the device within 30 minutes if there is a change in the user's mailbox. But in case of astaro, you are dnatting/snatting all https incoming to your exchange box. The exchange box will initiate the connection back to the mobile device during that 30 minute time if the user's mailbox has changed even if the https session has expired on astaro. It might create some extra traffic but its not broken by any means.

If this is not correct, please enlighten me. 
Thanks[:)]

 Now as far as I thought how MSFP worked was that the cell phone sends a ping to the exchange server that replies to the device within 30 minutes if there is a change in the user's mailbox. But in case of astaro, you are dnatting/snatting all https incoming to your exchange box. The exchange box will initiate the connection back to the mobile device during that 30 minute time if the user's mailbox has changed even if the https session has expired on astaro. It might create some extra traffic but its not broken by any means.

I was reading up on this today, and the way it works is that the client (phone) creates an HTTP connection and keeps it open for 30 minutes (ideal timout for battery consumption), or until it gets closed by IIS or firewall timeouts. If a new email comes in, the open connection is used to trigger the phone to sync. Otherwise, when the time expires or a firewall closes the connection due to no traffic passing through, the phone will re-create the connection.

The important thing here in regards to DOS attacks, is that this is an HTTP connection, so after the 3 way handshake has taken place - so opening the firewall to not close HTTP connections with no traffic would still keep DOS attacks down. And since the connection is held open with no traffic AFTER authentication has taken place, someone trying to open those ports would get locked out due to failure to authenticate to the server.

So the question is, how does ASG handle established HTTP connections that have no traffic passing through them?

The important thing here in regards to DOS attacks, is that this is an HTTP connection, so after the 3 way handshake has taken place - so opening the firewall to not close HTTP connections with no traffic would still keep DOS attacks down. And since the connection is held open with no traffic AFTER authentication has taken place, someone trying to open those ports would get locked out due to failure to authenticate to the server.

Why do you think that this will keep DOS down?
Session on the Firewall gets established before authentication. And as far my info goes, there is no TCP Reset done by the Exchange if authentication fails (because the user just could have misstyped his password).

"how does ASG handle established HTTP connections that have no traffic passing through them"

We were told that the astaro kills established HTTPS connections after 5 minutes of having no traffic.