GlobalProtect Client Stuck at Connecting when Workstation is on the Local Network

Printer Friendly Page

Symptoms

When users whose computers installed with GlobalProtect Client are on the internal network, they are not able to successfully connect to the GlobalProtect Gateway or Portal.  Whereas, users attempting to connect from the Internet work fine.

 

Issue

The most common situation is when the GlobalProtect Client users on the internal network attempt to connect to the gateway or portal on the external interface.  The communication fails because the firewall identifies the communication as internal to external zone communication and the firewall chooses the outbound NAT rule which translates the source address of the packet to the external interface IP address. Since, the destination in the packet is already the IP address of the external interface the packet now appears to have the same source and destination IP address which would create an unintentional LAN attack, thus the Palo Alto Networks firewalls drops these sessions.

 

See the following link for more information: Unable to Connect to or Ping a Firewall Interface

 

Resolution

If the GlobalProtect Portal license is enabled on the firewall, the best option may be to setup internal gateways and enable to GlobalProtect Client to discover the internal gateway and connect to it so that traffic is not tunneled when the user is already on the internal network.

To understand how internal gateways work, see: GlobalProtect Configuration Tech Note

 

However, the above does not enable the internal user to connect to the external GlobalProtect Portal. If access to the portal is still required, or if there is no license, then a NAT policy can be configured which acts as an exception to the default outbound NAT when the communication is only to the firewall external interface:

  1. Make a clone of the outbound NAT rule.
  2. Place it above the current outbound NAT rule.
  3. Change the name of the rule.
  4. Add the IP address of the external interface to the original packet destination address field.
  5. Change the source translation field to None.

This allows internal users to connect to the external gateway or portal without going through a source translation and getting dropped.  If the users are connecting to an external gateway, their tunnel traffic will still be encrypted and sent through the internal network toward the external interface.

 

owner: astanton

Tags (5)
Comments

I'm still having problems accessing the GP Portal interface (which is the external interface on my PAN) from my Internal LAN computers.  I read all of the above information plus all of the related posts.  I made the new NAT rule for Internal computers accessing the External interface IP address and can Ping and SSH to the interface from my LAN computers.  However, when I try to HTTPS to it to pull up the Portal Page, it just sits there and then times out.  I can access the Portal Page no problem from the Internet just fine and GP works externally.

I tried doing the debug commands to see if packets are getting dropped by the dataplane got this the following statement.

> show counter global filter packet-filter yes delta yes severity drop

Global counters:

Elapsed time since last sampling: 21.770 seconds

name                                   value     rate severity  category  aspect    description

--------------------------------------------------------------------------------

flow_fwd_l3_bcast_drop                     2        0 drop      flow      forward   Packets dropped: unhandled IP broadcast

flow_fwd_l3_mcast_drop                     2        0 drop      flow      forward   Packets dropped: no route for IP multicast

flow_host_service_unknown                  4        0 drop      flow      mgmt      Session discarded: unknown application to control

plane

proxy_offload_check_err                    5        0 drop      proxy     pktproc   The number offload proxy setup check failed becaus

e of not SYN or no certificate

--------------------------------------------------------------------------------

Total counters shown: 4

--------------------------------------------------------------------------------

Can someone take a look and let me know what could be the problem?  I even did a Wireshark capture and only see TCP SYN requests from the LAN computer to the External PAN interface.  Nothing comes back, so I know something is getting dropped before it could even get to the Session Setup in the PAN.

Thanks

Hi,

I don't think the packet filter you applied is working since we see drops for multicast.  I would add only a single filter from your IP to the public IP.  Make sure to turn it on.  Run the command, but without the drops filter.  The first run of the command will include all non-filter hits, but subsequent runs of the command will include only the filtered packet count changes.  Then we can see the counters perhaps a little better.

(show counter global filter delta yes packet-filter yes)

Also, I understand you said you read the other post and this one and checked that you were not running into the same behavior, but can you provide more information about each item you checked from to be sure?

Also, was the packet capture you took from the PC or the Firewall?

I'm guessing, but I'm a little suspicious your packet is getting dropped for the third reason listed there.  If so, we'll probably need more information to work on.  A debug log might help, and you could change the IPs in the txt, and post it here if that problem is keeping you from adding detail. Or, I'd recommend opening a case with support since it appears your not running into a typical issue.

~ Andrew

Andrew,

I created a filter for just LAN computer IP and dest External IP address.  I also did a Packet Capture on the FW this time.  Below is the output from the Global Counters.

> show counter global filter packet-filter yes delta yes severity drop

Global counters:

Elapsed time since last sampling: 27.419 seconds

name                                   value     rate severity  category  aspect    description

--------------------------------------------------------------------------------

proxy_offload_check_err                    6        0 drop      proxy     pktproc   The number offload proxy setup check failed because of not SYN or no

certificate

--------------------------------------------------------------------------------

Total counters shown: 1

--------------------------------------------------------------------------------

The Packet Capture only shows the one-way SYN packets from the LAN computer to the External Interface IP.  I don't know why the Ext Int is not responding to the SYN packets.  This is only when it's an HTTPS session.  I can PING & SSH to the Ext Int from the LAN computer no problem.

The External Interface happens to be the GP Portal & Ext Gateway Interface.  Like I said in my previous post, from the Outside everything works perfect.  It's only when I try to connect from the Internal LAN.

This is definitely mind-boggling!

I'd probably do a debug log at this point as more troubleshooting is needed.  See for help with that.  It is really important to have your filter set well when running debug logs as we write a lot of output to a file.  It looks like with your filter you are doing well, but I can't be 100% sure since you have given the command with "severity drop" still.  Again you might want to open a case for help with this.

Andrew... I can't open a case because I'm running Beta 5.0 and I was told that PAN Support will not help me as long as I'm on beta code.  Even though I don't think my problem is related to beta software.  So, I'm going to have to troubleshoot this one on my own.  If you can help with a checklist, it would be very much appreciated.

Thx

I would continue to recommend the debug log as you can paste the output here.  You can edit any IPs out you want as it is text output.  Also, you might move the discussion to a forum page and paste the forum # here, so I am notified...