- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-06-2021 09:07 PM
Hi All,
I have a client that has recently run into an issue, after upgrading to PAN OS 10.1.2. When they connect to Global Protect with their username and then try to RDP through the GP tunnel to a server on site using a different user account that is not in the allowed GP user AD group, the GP tunnel looks to freeze (doesn't disconnect) and all users have to reconnect to GP.
Client advised that they were able to do this prior to upgrading. The traffic log detects the different username being used through the tunnel. The client has now added the different user into the allowed GP AD group and this looks to have resolved the issue. The client can now RDP through the tunnel with this different user, when logged onto GP with their user account.
It looks like the PAN is now smart enough to detect the different user trying to connect through the tunnel, where it may not have been before. GPS log has a gap in logging for approx. 10 mins when the different user tries to login over the tunnel, so not much there to go on by the looks.
So, I am wondering if this type of thing should be possible or not? Has anyone come across this type of thing before? Why does the whole tunnel seem to go down when they login as the different user?
Thanks.
04-30-2022 02:28 PM
Hi @GerardGlynn ,
What you experiencing only make sense if you have User-ID agent deployed in your network (either via separate agent installed on server or the integrated agent in the FW itself).
If that is the case it make sense to experience exactly what is described in the link you provide.
- When user login to GP, firewall will use that information to create ip-to-user mapping (since it already have the required information: authenticated user and allocated IP address)
- When user makes RDP login attempt, this will create security log under the Domain Controller. Which will be picked up by the User-ID agent and override the existing user-to-ip mapping with the username used for the RDP connection.
Apart from @OtakarKlier suggested approach I would add another two:
- As suggested in the article you can add the username used for the RDP to ignore list on the user-id agent. This will tell the agent to ignore any logon events and not create user-to-ip mapping for that user
- What I would suggest in your case is to add the GP network to user-id agent exclude network list. This will tell the agent to ignore all events for users connecting from that network. I believe this make sense, because you already have user-ip-mapping from GP, which is far more accurate from the agent, so it doesn't make sense to receive mapping from somewhere else, for something that FW already knows.
10-17-2021 04:24 PM
@nikoolayy1 Any chance you could comment on this?
04-27-2022 09:13 AM
Hi Ben,
Facing the exact same problem with GP at a customer site.
Did you manage to resolve the problem ?
I will try adding AD user-ID administrator to the AD Group GlobalProtect , but I think we are still facing that same problem where if I login to GP using AD user-ID "BobHope" , then RDP through the GP tunnel onto a server and login with AD user-ID "administrator" , it kills access through the tunnel
Any help or suggestions appreciated
thanks
ger
04-27-2022 12:56 PM
Hello,
Let me see if I understand:
User = john.doe logs in with global protect.
The PAN see's all traffic in the logs from that VPN IP address as john.doe
User tries to RDP to a server with jane.doe and the PAN now sees the traffic as jane.doe?
Regards,
04-28-2022 02:49 AM
Hi Otakar,
Yes thanks , that's the issue
I think it's also described in this article
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CleBCAS
Trying to come up with a workaround for this scenario. Remote user is logged into GP with userid-1, then that user opens a remote desktop session to a server through the GP tunnel and they login with userid-2
This activity stops their traffic going thru GP tunnel.
I think its a security feature within the GP design
04-28-2022 04:53 AM
Hi Otakar,
We decided to apply the “split-tunnel” config to their Global-Protect setup , where only traffic sent to their HQ internal networks is put into the GP tunnel.
This appears to have resolved the overall issue. In that they can now be logged into GP with AD User-ID-bob , then RDP onto an internal server with AD User-ID-jane and GP continues to work
Not exactly sure why split-tunnel has resolved it, but have tested a few times and all good
Cheers
Ger
04-28-2022 08:45 AM
Hello,
I have a better understanding now. We decided to use Exchange logs for user-id mapping as this seems to prevent this from happening, since the second user is not using exchange.
Regards,
04-30-2022 02:28 PM
Hi @GerardGlynn ,
What you experiencing only make sense if you have User-ID agent deployed in your network (either via separate agent installed on server or the integrated agent in the FW itself).
If that is the case it make sense to experience exactly what is described in the link you provide.
- When user login to GP, firewall will use that information to create ip-to-user mapping (since it already have the required information: authenticated user and allocated IP address)
- When user makes RDP login attempt, this will create security log under the Domain Controller. Which will be picked up by the User-ID agent and override the existing user-to-ip mapping with the username used for the RDP connection.
Apart from @OtakarKlier suggested approach I would add another two:
- As suggested in the article you can add the username used for the RDP to ignore list on the user-id agent. This will tell the agent to ignore any logon events and not create user-to-ip mapping for that user
- What I would suggest in your case is to add the GP network to user-id agent exclude network list. This will tell the agent to ignore all events for users connecting from that network. I believe this make sense, because you already have user-ip-mapping from GP, which is far more accurate from the agent, so it doesn't make sense to receive mapping from somewhere else, for something that FW already knows.
05-03-2022 02:34 AM
Hi Astardzhiev,
Thanks for your post which is very helpful. Of course, the split-tunnel idea did not fully resolve the issue so have abandoned that for now
I will try your suggestion with excluding the GP-remote-LAN from the user-ID detection, which seems like a good solution
05-03-2022 03:20 AM
Hi Astardzhiev,
If you apply your workaround below, do you also have to remove source user-id matching from the security policies relating to inbound Global-Protect traffic ?
- What I would suggest in your case is to add the GP network to user-id agent exclude network list. This will tell the agent to ignore all events for users connecting from that network. I believe this make sense, because you already have user-ip-mapping from GP, which is far more accurate from the agent, so it doesn't make sense to receive mapping from somewhere else, for something that FW already knows.
Thanks
ger
05-03-2022 03:58 AM
Ignore that last message about the security policies, I had forgotten to add an "include-list" of 0.0.0.0/0 to accompany the "exclude-list"
seems to be working now
thanks again
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!