GlobalProtect prelogon and internal gateway detection

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

GlobalProtect prelogon and internal gateway detection

L2 Linker

I've been doing mixes of internal and external gateways with customer forever (I usually forget that "always-on" must be enabled for internal gateway detection to even be allowed in the first place).

 

I'm working on a pre-logon implementation that also would benefit from leveraging internal gateways/no-tunnel while inside the enterprise network. I'm seeing some wild behavior at the moment...

 

THIS TEST IS OCCURRING WITH CLIENT CONNECTED TO CELLULAR HOTSPOT WITH IP ADDRESS ON PUBLIC INTERNET, OUTSIDE MY NGFW

 

  1. Device, while on internet/outside UNTRUST zone on my NGFW, is configured to connect to my portal as "prelogon" : me.example.com.
  2. Device successfully connects to prelogon portal, then EXTERNAL GP gateway, and is shown in NGFW GP-Gateway remote-users pane as "pre-logon" user as expected. On the device at logon screen, however, it shows "Internal Gateway (Connected)".  ... [this is curious since the device is outside my WAN boundary]
    NGFW globalprotect external gateway statusNGFW globalprotect external gateway status
    internal gateway, while pre-logon is outside WANinternal gateway, while pre-logon is outside WAN
  3. I am able to login successfully on client, and GP client immediately shows that it is connected to internal gateway. On NGFW, it still shows "pre-logon" user on the external gateway.
    gateway statusgateway status
  4. On client, doing test to www.ifconfig.co , it shows WAN address of my GP external gateway, as if it were connected to the external gateway. The GP settings show no IP information, consistent with it thinking it is connected to internal GW. ipconfig /all shows NO tunnel interfaces, no tunnel information, no IP address other than the wifi address and gateway of my LTE hotspot I am connected to.

    ROUTE INFO ON CLIENT DURING THIS EVENT:

    C:\Users\me>route print
    ===========================================================================
    Interface List
    3...94 65 9c 1b be 1d ......Microsoft Wi-Fi Direct Virtual Adapter
    15...94 65 9c 1b be 1c ......Intel(R) Dual Band Wireless-AC 7265
    1...........................Software Loopback Interface 1
    ===========================================================================

    IPv4 Route Table
    ===========================================================================
    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.168.83.144 192.168.83.138 35
    127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
    127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
    127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
    192.168.83.0 255.255.255.0 On-link 192.168.83.138 291
    192.168.83.138 255.255.255.255 On-link 192.168.83.138 291
    192.168.83.255 255.255.255.255 On-link 192.168.83.138 291
    224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
    224.0.0.0 240.0.0.0 On-link 192.168.83.138 291
    255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
    255.255.255.255 255.255.255.255 On-link 192.168.83.138 291
    ===========================================================================
    Persistent Routes:
    None

    IPv6 Route Table
    ===========================================================================
    Active Routes:
    If Metric Network Destination Gateway
    1 331 ::1/128 On-link
    15 291 fe80::/64 On-link
    15 291 fe80::a107:9e6c:1abc:8153/128
    On-link
    1 331 ff00::/8 On-link
    15 291 ff00::/8 On-link
    ===========================================================================
    Persistent Routes:
    None


    192.168.83.0 is the internal network on my cellular hotspot and exists entirely outside of NGFW. NGFW knows nothing about this network from security, routing, NAT etc.

NGFW logs show no traffic from source IP of this client. The only indications of connectivity on this client from the NGFW side is that I see a "pre-logon" user connected on this device through the external GP gateway. No traffic logs are generated from anything this client does. From the client side, I am able to access all "internal" resources as if I were connected via external GP gateway. ifconfig.co web page shows IP egress address as if I were connected to external GP gateway.

 

My concern and misunderstanding is with how internal gateway detection works. It seems like at the pre-logon stage, the client successfully reaches the portal, gets a portal config which includes an internal gateway detection element and internal gateway defined. It seems like it is reaching out to an internal DNS server at the pre-logon stage (which I need it to be able to do in order to talk to Active Directory for user authentication at login prompt), and it thinks it is actually inside. The user supplies credentials at login window and GlobalProtect shows "internal" after they login.

 

Is there some other way to handle this "internal detection" phase with pre-logon in the mix such that "pre-logon" is able to access AD for auth, but not allow the PTR lookup to succeed? Short of some DNS trickery where I create a zone that cannot be resolved in my pre-logon CIDR, I can't imagine how else to make this work. I've seen nothing in PAN documentation that suggests anything other than including an internal gateway is possible.

1 REPLY 1

L2 Linker

oof. so my "test" hotspot had wifi turned on while in hotspot mode. chaos ensued. In my defense, in previous hotspot, it did not allow wifi to be enabled prior to enabling the hotspot while this one lets it happen.

With proper hotspot, the internal detection has happened more reliably now. My question still stands regarding "if prelogon's connection to its respective gateway happens, which by definition implies internal access to AD/DNS, what does the user-side do regarding the internal/external detection if it is defined in a portal agent config?"

  • 342 Views
  • 1 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!