Internal Host Detection Issue

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L1 Bithead

Internal Host Detection Issue

Hi there,

 

I have a question on the correct use of internal host detection and internal/external gateway config. The behaviour I want to achieve is when a client is internal to the LAN GlobalProtect will detect this and not bring up the tunnel and pass all network traffic transparently out the LAN connection, as if it wasn’t there. When external, the client tries to establish the tunnel. I have no requirement to tunnel internal traffic, it needs to traverse the LAN as if GlobalProtect wasn’t there.

 

I have an external gateway & portal configured, there is no internal gateway. A “no NAT” rule and policy are set up so the client machines can communicate with the external gateway, even if they are internal. I understand this is best practise so clients will get config changes from the firewall regardless of where they are connecting from. The NAT & policy that allow this are working as I can communication in the logs from internal clients. No direct access to the local network is enabled and app is in “always on” mode as I want all traffic to be forced down the tunnel if the client is external to the LAN.

 

When clients are external to the network, everything works fine and as designed.

 

However with internal clients, there can be a delay in connecting, sometimes 30 seconds or longer before it realises it is on the internal LAN, and GlobalProtect backs off. Sometimes the yellow “connecting” message appears, asking you to be patient. Some clients are fine, and immediately detect the internal LAN and back off.

 

A small number of clients will not detect they are on the internal LAN at all. After the user authenticates, the GlobalProtect client tries to do something, then falls back to disconnected state. Firewall logs show the authentication and client configuration was successful, so something strange is happening on the client side. In this situation the app appears to be allowing some outbound network traffic from the device to the local LAN, but no inbound, resulting in an internal client that is orphaned from the network.

 

Clearly something isn’t quite right, how can I achieve the behaviour I want?

 

On internal host detection the documentation says “The GlobalProtect app connects to the internal gateway after performing internal host detection to determine the location of the endpoint.”

 

What is the client behaviour once it detects it is internal to the network? I don’t have an internal gateway configured, could this be the problem? Is the client looking for an internal gateway?

 

Many thanks,

Highlighted
Cyber Elite

Hi @PKCCommsTeam 

For this you do not need an internal gateway. You wrote that you have configured always-on mode: pre-logon or user-logon? What globalprotect version do you use?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!