Office365 apps hang at launch for timeout ~26 seconds then start

[DavidRolfe]

Greetings,

I have users on a internal network with Internet access blocked. We have MS Office installed on their workstations and I authorized them on a different vlan *with* internet access. (They're the per-machine perpetual licenses that ship with Dells, so should be fine forever offline.)

After replacing a juniper with a fortigate when the no-internet users launch Word or Excel it hangs for roughly 26 seconds and then starts normally. Before installing the fortigate this didn't happen.

When I make a rule for these machines that gives them access to the internet the problem goes away, so I'm fairly convinced the problem has to do with Word/Excel phoning home and some kind of keep-alive or time-out issue. The migration was fairly painless and this is one of the only quirks that have come up.

Any advice on how to solve this without putting these machines on the Internet?

[AEK]

Hi David

Can these no-internet users resolve public FQDNs? If so, can you try point your clients to a local-only DNS server and do the test again?

[DavidRolfe]

Yes, they can resolve fqdns, and they only use DNS from the domain controller.

New wrinkle: When logged into the same machine as local admin the problem goes away (i.e., Excel launches immediately, how is the firewall implicated?), but the problem comes back when you log in as a domain user. The GPOs are the same whether a domain user is logged in or not, they are applied at the OU. Problem persists when a machine is moved to an empty test OU and logged in on domain. I'm totally stumped.

[AEK]

Can you try disconnecting the PC from the network and do the test again?

[DavidRolfe]

Sorry, I've been putting out other fires.

Current status is this, the local admin was a red-herring. On some boxes local admin doesn't have the problem and on others it does.

Disconnecting the PC from the network does solve it!! But I guess we already know it's some kind of search or timeout across the network that causes the problem.

[AEK]

Good.. that's why I suggested to configure you non-internet client with a DNS server that doesn't resolve internet addresses.

If you can't do that then as it is a Microsoft related issue, not FortiGate related issue, I'm pretty sure it is a known issue and should have some workaround available in Microsoft forums.

[johnathan · Accepted solution]

In my homelab, I block all connections going to AWS, Azure, Microsoft, etc. What I find is that some websites will take a very long time to load, as the browser is waiting for a timeout. If you actually set 'send-deny-packet enable' on a deny firewall policy, it will send a RST to the client instead of forcing it to timeout. What I would do in your case is make a deny policy from that device to the WAN, and then set that option. It should solve the issue.

[DavidRolfe]

Thanks, this is what I was expecting, and presume the version of this rule on the Juniper was doing that and the migrated rule on the Fortinet isn't. I'll look in that direction.

Thanks again.

[DavidRolfe]

Confirmed this as the solution, thanks again. The default deny-all policy we were letting these guys run into doesn't let you set the send-deny-packet. I got rid of the ISDB deny rule for Office 365 and made a new blanket deny-internet rule with send-deny-packet and it's working as expected.

Is it not the default because it's bad practice? If it's OK pass it along to the guys maintaining the migration tool that Juniper SRX default-deny resets connections but Fortinet will need a rule to mimic that.

[johnathan]

Ehhhh, I mean it is technically granting more visibility into what is and isn't specifically blocked. Timing out as default is the safer option, as it does not confirm a specific resource exists. Glad to see it solved the issue in our case.