FortiClient 'compliance' preventing connection to FortiGate web interface?

[ispcolohost]

Has anyone run into a weird issue where when you're connected via FortiClient VPN, no split tunnel, no internet access, that you can't connect to a FortiGate's https interface for management?

I'm running FortiClient on Mac, 5.4.3.529.  Here's where it gets weird; I can ssh into the FortiGate just fine.  So, with that being the case, I ssh in, run a sniffer on port 443 and then try to connect.  If I try from Chrome or Safari, no luck, browser just says connection failed.  If I try from telnet on Mac command line to port 443, here's where it gets interesting.  The sniffer will show zero packets for 33 seconds, then, I get a syn/ack/fin and connection is opened and closed immediately from telnet's perspective.  The time between syn and fin is roughly a tenth of a second.

This seems to have something to do with the Compliance tab/feature in FortiClient.  If I click to disconnect, sometimes I can connect to the FortiGate.  Other times, I have to drop and restart the VPN one or more times, disconnect compliance, reconnect, etc.  I have not found the magic combination of what makes it work yet.

There IS a policy rule for source interface of the firewall admin dial-up VPN, to destination interface VLAN where the management IP lives, schedule always, service all, action accept.  That of course is what lets me ssh and ping the fortigate, and should let me https to it.  So it seems to have something weird to do with FortiClient or the Compliance tab, but we don't have any user policies so I'm not sure what to look at.

[ispcolohost]

Hmm, updating my own post; if I add a policy that permits internet access, the delay doesn't occur.  Perhaps FortiClient is trying to do some kind of DNS lookup or 'bad site' lookup for the IP I'm trying to connect to?  If I let it happen once, disable that rule, then try again, it still works so perhaps whatever it's trying to do also caches the result.

[ispcolohost]

Seems to be a DNS lookup issue, and the timeout just happens to occur right before the TCP connection timeout.  I ran a new packet cap and looked at everything instead of just port 443, and for the 33 seconds before the 443 connection occurs, my computer is repeatedly issuing DNS lookups.  I have to assume this is something FortiClient is doing because obviously using telnet to an IP address would involve no DNS lookups; it only happens for outbound port 443 attempts.  If I alter my internet rule to only permit DNS lookups, that also makes the delay go away.

So, now the question is, what is FortiClient trying to look up when connecting to a private 10.x IP address, and what's the point given a private range isn't going to have any useful information to begin with.