In one environment, device enrolls fine, Restarts, VPN establishes and connects (As far as the user is concerned everything is working) But the device cannot actually connect to anything on the LAN. After much frustration, i pinged the device, and suddenly it can contact the LAN. Its consistently reproducible, So if i enroll a device and then use Yona Sync to pick up policies, Yona sync fails, I go onto the GW event logs and get the ip address for the device, and ping it. Then on the device i YonaSync and it works fine... 10 or 15 minutes later, it wont be able to connect again until i ping it first.
I've run network analysis on the device, Wireshark on GW and DM server. Nothing untoward there. It doesn't even seem to connect in.
Similarly if i connect to a lan website... eg. 192.168.1.80. It will time out, but once i ping the device, it can connect (Ping does not need to originate from the server the device is trying to contact, any lan server can send the ping.).
Tried this on the emulators, on a 6.1 Excalibur and on two devices with downloaded firmware (Hey, i had to double check).
Basically there is a a watchguard firebox, with an external IP bound to the ext interface of the GW server.
I haven't got any experience with Watchguard, but I have a colleague who says he has had a some challenges with them :)
Off the top of my head I can throw out some ideas. (While not the same as a definitive solution at least it's something I hope.) - Way back with a D-Link firewall and Exchange 2003 Direct-push I had an issue where push wouldn't work but manully synchronizing did work. Turns out the D-Link had a default setting which only enabled sessions to be kept alive for a few minutes so the http keep alive ActiveSync requires was killed of. Exchange best practices recommend a time out of at least 15 minutes if I remember correctly, and I'm guessing that would be ok for SCMDM as well. I believe I reconfigured my firewall to allow 30 minutes and that solved the problem. (I have gotten rid of the D-Link as it had other issues as well however.) - I experienced a strange problem with ISA server where I also had defined Any<->Any between to subnets but couldn't get all traffic through. Turns out that ISA did some packet inspection and rejected the traffic regardless of the rule allowing the ports. The traffic was encrypted data that I tried to tunnel through HTTP.
As your traffic is able to pass through I'm leaning more against the first scenario rather than the second, but it highlights those funny firewall issues nonetheless.
Marked as answer byDavid MadisonMonday, June 2, 2008 8:09 PM
I'm sure you'll have checked his, David, but can you confirm that you have Protocol 50 open in _both_ directions? Pat.Mobility Architect, Enterprise Mobile
For testing we even tried Any to Any for the rules.
This is what i don't understand, everything works fine once the device has been pinged. It is as if the traffic doesn't leave the device, Ie. I can see the device trying to contact an internal server in the firewall logs, but only after i've pinged it, before, the firewall doesnt see (Or possible doesnt log) any traffic.
Can't speak to watchguard, although IIRC we ran into one customer who thought they had everything open as directed but it wasn't until one of my esteeemed colleagues pulled a wireshark trace off the GW and proved to them that nothing was being seen on UDP 4500 that they went back and re-visited.
completely agree on the expected behavior with an Any-Any rule...
What about rules precedence? Or is the only rule in place an Any-Any? Just throwing it out there...
Interesting. Did the exact same setup but without the watchguard. Works fine. As i'd set before, we'd had an Any - Any rule. still no go.
And its not like it was limiting the traffic, as i'd said, after pinging the device everything works fine. But it required to ping the device first... Strange. Anyway, so taking the watchguard out of the equation, works great.
I don't know how the ping changes anything, as its not establishing any new sessions etc. but yes... without the watchguard, works.
I haven't got any experience with Watchguard, but I have a colleague who says he has had a some challenges with them :)
Off the top of my head I can throw out some ideas. (While not the same as a definitive solution at least it's something I hope.) - Way back with a D-Link firewall and Exchange 2003 Direct-push I had an issue where push wouldn't work but manully synchronizing did work. Turns out the D-Link had a default setting which only enabled sessions to be kept alive for a few minutes so the http keep alive ActiveSync requires was killed of. Exchange best practices recommend a time out of at least 15 minutes if I remember correctly, and I'm guessing that would be ok for SCMDM as well. I believe I reconfigured my firewall to allow 30 minutes and that solved the problem. (I have gotten rid of the D-Link as it had other issues as well however.) - I experienced a strange problem with ISA server where I also had defined Any<->Any between to subnets but couldn't get all traffic through. Turns out that ISA did some packet inspection and rejected the traffic regardless of the rule allowing the ports. The traffic was encrypted data that I tried to tunnel through HTTP.
As your traffic is able to pass through I'm leaning more against the first scenario rather than the second, but it highlights those funny firewall issues nonetheless.
Marked as answer byDavid MadisonMonday, June 2, 2008 8:09 PM
Heartbeats and keep alives were the first thing i looked at. Then after an hour or so of investigating it hit me that we already run push extremely efficiently through the same box for exchange.
