topic Re: Access problems via Globalprotect with AD group. in General Topics

Access problems via Globalprotect with AD group.

Amaro123 — Wed, 17 Feb 2021 14:28:05 GMT

Hello everyone,

I am relatively new to Palo Alto solutions and I face a problem that has been going on for over a week. Could anyone help me?

This is the scenario:
- I have gateways 01 and 02 for the GlobalProtect.
- AD groups called Grupo1 and Grupo2.
- Test user named Fred.

When user Fred is in Group1 he has normal access to the environment through the two gateways.
When that same user is in Group2 he has normal access only through gateways 01. If you use 02 he does not access anything.

I reviewed the LDAP settings but did not find any unique references to the groups I have.

What can I not be seeing?

Re: Access problems via Globalprotect with AD group.

Mick_Ball — Wed, 17 Feb 2021 16:58:42 GMT

the group settings can be found in Device\User Identification\Group Mapping\Group include

and try the following...

on both gateways enter via cli...

show user group list

and compare to ensure you are checking the same groups.

then on both gateways enter..

show user group name " enter group name from above here"

do this for both groups and check to see all members are displayed for both gateways,

Re: Access problems via Globalprotect with AD group.

Amaro123 — Wed, 17 Feb 2021 18:08:11 GMT

What do you mean "on both gateways enter via cli ..."? I must have explained it wrong, the GP gateways are related to internet links. I can access the VPN via the IP of one provider or the IP of another provider.

The command "show user group list" showed me that the list is very long, but I can identify the DN using "show user group list | match <group_name>".

However when I use the command "show user group name <group_name>" the result is always the same regardless of the group you are querying: User group 'group_name' does not exist or does not have members

Re: Access problems via Globalprotect with AD group.

Amaro123 — Wed, 17 Feb 2021 18:16:40 GMT

Re: Access problems via Globalprotect with AD group.

Mick_Ball — Thu, 18 Feb 2021 08:21:11 GMT

you have not used the "Included Groups" option.

This will force the firewall to collect all information for every group within your AD.

The firewall has limits on how many groups it can access and although this may not be the issue here I would still only include the required groups that you actually need to interrogate. this will also help with future diagnostics when using multiple groups.

This will also allow you to use "show user group name" and return valid entries.

snippet from PA

Re: Access problems via Globalprotect with AD group.

Mick_Ball — Thu, 18 Feb 2021 08:28:51 GMT

OK just re-read your reply, are both of these gateways on the same firewall?

If so then it should be OK as we have a similar setup of multi gateways on same firewall.

are both gateways using the same policy, or do you have a policy for each zone?

Re: Access problems via Globalprotect with AD group.

Amaro123 — Thu, 18 Feb 2021 19:47:58 GMT

Thanks for the tip with "Included Groups". It can be an interesting point for improvements and I will study the possibility of adjusting it!

Yes, both are on the same firewall and using the same policy.

Even with the user having problems, I see the communication attempt, but the log is presented as the "incomplete" status.

Re: Access problems via Globalprotect with AD group.

Mick_Ball — Fri, 19 Feb 2021 09:35:48 GMT

@Amaro123 is the communication attempt you are seeing allowed or denied? I would imagine that it's allowed or the sate would be not-applicable. it may help if you paste log snippet.

Re: Access problems via Globalprotect with AD group.

Amaro123 — Fri, 19 Feb 2021 18:37:32 GMT

Hello @Mick_Ball,

They are allowed, but in Application the status is "incomplete".

I used the command "show users user-ids match-user <user.name>" for the user who has been doing the tests and he recognizes the group I mention here in the example that presents the problem. In this case it is the third in the print list.

Re: Access problems via Globalprotect with AD group.

aleksandar.astardzhiev — Mon, 22 Feb 2021 08:44:09 GMT

Hi @Amaro123 ,

"When user Fred is in Group1 he has normal access to the environment through the two gateways.
When that same user is in Group2 he has normal access only through gateways 01. If you use 02 he does not access anything."

Having the above in mind and the logs you provide it looks to be like routing problem.

I am assuming that the two gateways are assigning different IP pools to the connected users, but do they assign different range based on the user group?

I can imagine that gateway01 and 02 are assinging differen IP addresses based on the group membership. So when user is assigned to Group2 and connects to gateway02 he is assigned with ip address that your internal network doesn't route properly. If you look at the log details (the magnifying glass on the very left of your log entry you sent earlier) you will probably see that traffic is only in one direction - packets/bytes received will be zero. Or if you have internal firewall that is blocking the range assigned to users in group2 connected to gateway2.

In short - check what IP range is assigned when connected any gateway with any group and check if your internal network handle these ip ranges the same way.

Re: Access problems via Globalprotect with AD group.

Amaro123 — Wed, 24 Feb 2021 18:34:00 GMT

Hi @aleksandar.astardzhiev ,

First of all, thanks for your interest in helping!

Initially I also thought about routing, but the pools in the group that has a problem use the same subnet. All others use different subnets. See the print.

Regarding the details of the logs you commented, there is really no answer from the other end.

Re: Access problems via Globalprotect with AD group.

aleksandar.astardzhiev — Thu, 25 Feb 2021 08:40:50 GMT

Hi @Amaro123 ,

I am not sure that using same IP pool for the two different gateways is good (not sure what word to use..) configuration.

I believe I have read somewhere while ago that if you assing same IP pool to two different agent config/user group this could cause IP conflict and firewall can assign the same ip to two different users. FW is monitoring the IP allocation "locally" for each agent config, without being aware of the all the pools configured on the GP gateway. I believe I read this mainly for same ip pool under one gateway, but in my humble opinion it should be a problem with two separate gateways. When you assign IP pool to gateway agent config FW will create static route (or split it to multiple static routes) pointing to the tunnel interface assosiated with gateway. If you assign same IP pool to two different gateways, I assume FW will try to create same static routes pointing to two different tunnel interfaces. Which could explain your issue -fw has static routes for IP pools pointing to tunnle.1 and tunnel.2, when you connect to gateway1 traffic is working as return traffic is taking first route. But when you connect to gateway2 return traffic is routed to wrong tunnel interface and traffic doesn't reach the user.

In any case I really don't like the idea of having same IP pool assigned to more than one gateway agent config (no matter if it is on same gateway or different). I just think FW will have problems with that.

But if you want, before trying with different IP pool, create a packet capture

- listening on the inside interface (the lan behind the fw)

- try connect to gateway2 with problematic group and generate traffic to inside (simple ping will do the trick)

- check the capture - do you see replies hitting the inside interface ( this will confirm that you have bi-directional traffic behind the firewall and that fw is receiving all the traffic, but after that it doesn't route properly or dropping return traffic)

Re: Access problems via Globalprotect with AD group.

Amaro123 — Thu, 25 Feb 2021 18:07:22 GMT

Hi @aleksandar.astardzhiev ,

Changing the subnet to a different one had no effect. I had already done this test and the scenario was the same.
And there is no other device for routing connected to the firewall.

Yesterday the firewall was rebooted by a power failure in the rack where it is and I did new tests today. Even if I am not successful in ping or telnet communications, I can see by the details of the logs that there is an answer.