I am in the process of rolling out a change in our GP VPN configuration to use “always-on” mode with pre-logon (not sure if I said that right). I have mostly everything working except I am having issues getting GP client to recognize when the endpoint is connected to an internal network. This is mainly when the endpoint is powered on and the user logs in while connected to the internal network. I have set the internal host detection up, made sure the DNS reverse lookup is setup, made sure the hostname in the record and the setting are both matching in case, and also added the host as an internal gateway (this was per support’s suggestion).
So far, all I am seeing when turning on logging in debug level for the GP client is that it is trying to connect to external portal address and failing. I don’t see any indication of it trying to resolve the address of the internal gateway and detect whether its internal or not.
I have a lot riding on this project and feel like I am pulling my hair out over this. The only time it seems to detect when its internal is if I change the connection from wired to wireless or the reverse of that. Please help!
UPDATE: I was able to get this working. Had to set up internal gateways and DNS records for the external portal addresses. The external portal records in our internal DNS seemed to fix the issue.
It needs to connect to the portal before trying internal host detection. If it’s failing to connect to the portal, internally you might be getting blocked from your GP IP/URL
We got this working after a lot of hair pulling, too. The trick was setting up another, portal that was for internal only. We used certificate authentication for it and had the internal dns name resolve to the new portal.
DM me if you want to exchange info and I can explain it over the phone.
I know you mention it already, but internal host detection is based on the client’s ability to do the reverse lookup on the ihd host. So on the internal dns side, that’s making sure there’s a one and only one ptr record for the ihd host.
So on a laptop without gp connected, connect it to the internal network and try to do a reverse lookup for the ip and make sure it’s actually resolving to the fqdn you specified. It has to match exactly and to only 1 thing.
I can ping the internal hostname/ip from the internal network no problem. The external hostname of the portal and gateway are resolvable on the public internet. However, I do not believe they are resolvable internally. My understanding of this internal host detection was for the GP client to figure out that its on the internal network and to not try and establish a tunnel with the gateway but it seems to want to do just that when I power up the laptop while it is connected on the internal network.
The problem with this is that if our users bring their laptops into the office to connect at their desk, they will be unable to access anything on the network because GP effectively blackholes all traffic if it fails to connect or figure out that its internal. So far the solutions I’ve seen in this thread seem like workarounds for a feature that is very buggy or flat out doesn’t work like its supposed to. I have a ticket open with TAC and I am going to see what they say about it in the morning.
reverse lookup was working. oddly enough, I ended up adding DNS records for the external portal addresses in our internal DNS and somehow that seemed to do the trick and everything is working now.
For us, it would not have worked. We use radius for Auth on the public side, so we needed the internal portal to prevent the prompt. We just authenticate via certificate, internally.
Why don’t you add the dns record so the host can connect to your gp portal and detect they are internal? We use internal host detection and have this setup and it works.
In addition, I believe the internal host detection is a function provided by the firewall, so if you don’t make a successful connection, the firewall can’t determine the host is internal. Hopefully that makes sense, I’ve had a few beers
