Internal host detection not Working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Internal host detection not Working

L3 Networker

I have an external Gateway and I wish to setup always-on except when on local LAN. As a test i am doing this on my own username but it seems to always want to connect to external GW regardless of my settings.

 

I have turned on Internal Host detection and this is returning "0" in the PanGPS logs so i would assume then it would realise i was internal and not try and connect me to external gateway?

 

Connection type is currently - prelogon always on

 

(T1848) 09/24/18 11:16:36:219 Debug(1712): host TEST 
(T1848) 09/24/18 11:16:36:230 Debug(1729): DnsQuery returns 0
(T1848) 09/24/18 11:16:36:230 Debug(1744): Resolved X.X.X.X.IN-ADDR.ARPA for internal host detection with return value 0
(T1848) 09/24/18 11:16:36:230 Debug(1768): The host name is TEST.DOMAIN.local
(T1848) 09/24/18 11:16:36:230 Debug(4040): NetworkDiscoverThread: network type is external.
(T1848) 09/24/18 11:16:36:230 Debug(4109): NetworkDiscoverThread: Discover external network

11 REPLIES 11

Cyber Elite
Cyber Elite

@welly_59,

As I'm reading your logs it's actually not able to resolve the DNS name that you are using. Attempt to test this with just an IP, preferrably a load-balanced VIP if you can, and see if it works. 

L7 Applicator

@welly_59

Are you able to do a DNS (reverse)lookup for the IP that you configured and do you then get exactly the name that is configured?

Isn’t dnsquery = 0 meaning that it’s successfully resolved?

DMs lookup brings the whole fqdn- test.domain.local

I have just ‘test’ set as the name for internal host detection, but it’s returning dnsquery = 0 which means it has resolved ok?

Normally 0 means false while 1 equals true. So if you set the host also to test.domain.local the internal host detection should work and the client will not connect from internal.

not for this.

 

0 = succesful

9003 = not succesful

9852 = no dns servers configured

 

https://live.paloaltonetworks.com/t5/Management-Articles/Most-Common-DNS-Query-Responses-for-Interna...

 

I just tried this from home, where im obviously off-LAN, and i get this:

 

(T10216) 09/24/18 19:18:04:105 Debug(1729): DnsQuery returns 9003
(T10216) 09/24/18 19:18:04:105 Debug(1744): Resolved x.x.x.x.IN-ADDR.ARPA for internal host detection with return value 9003
(T10216) 09/24/18 19:18:04:105 Debug(4040): NetworkDiscoverThread: network type is external.
(T10216) 09/24/18 19:18:04:105 Debug(4109): NetworkDiscoverThread: Discover external network.

Good to know ... 

L0 Member

Hi,

 

Did you make any progress on this? I am going thru the exact same challenge. Should work but it does not. The only thing I have not tried yet is switching from On-Demand to User-Logon.

 

Thanks

Jim

You must use Always-on when implementing internal host detection.

Hello @welly_59 

 

We had similar problem earlier and PA TAC assisted us in resolving the issue.

Below are the things to check/configure:

--FQDN configured properly

--Try a portal config refresh:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClF1CAK

--Try latest GP version

L0 Member

Had the same issue, adding a PTR record for the internal gateway fixed it.

 

"When the user attempts to log in, the agent does a reverse DNS lookup of an internal host using the specified Hostname to the specified IP Address. The Dns server must have a PTR record in order to reply back to the reverse DNS query from the GP agent. In either case (failure or success) an entry would be made in the PanGPS.log file about the reverse DNS lookup result. "

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClsWCAS

  • 9013 Views
  • 11 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!