Error message "Assign Private IP address failed" with GlobalProtect 5.0 app.

[Bittereinder]

Hi, everybody!

I have a question regarding GlobalProtect 5.0 and the error message "Assign Private IP address failed" a user is getting when trying to connect from a mobile phone (both Android and iPhone).

I tried to explain to the user that this could be caused by IP overlapping, as this link tells:

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

But he rejects that possibility and insists he has the error every time he tries (not just once in a while) and that the internal addresses he uses for VPN are only used for that.

What other things apart from IP overlapping could be causing this "Assign Private IP address failed" error?

Thanks a lot!

[hshawn]

You could also be getting that error message if you require the user to be in a certain AD group and this user is not a match. I recommend watching your system logs when they attempt to connect:

( subtype eq globalprotect )  and (time_generated in last-24-hrs) and ( description contains 'theirusername' )

[BPry]

@Bittereinder,

IP Overlap is the only time that I've ever known this message to popup. An easy check would be to have them connect to a hotspot from say your phone and try that, so that you can verify that the IP pools don't overlap. 

I've never seen this for what @hshawn is describing and won't expect this message if they weren't an authorized user as that's a completely seperate error message. 

[hshawn]

@BPry We see it from time to time. In fact the user gets authenticated and has an IP address of 0.0.0.0 then we tell the help desk to add them tot he VPN AD group and *poof* they have a real IP. When they have the 0.0.0.0 IP showing we see that message in the logs and we see them get booted and reconnect over and over again (we are using always on configs). We have also seen this with the overlap when someone is at a hotel that happens to use the same subnetting scheme for their internal network.

[BPry]

@hshawn,

Hmm. Have you raised that with support at all? When the tunnel attempt to switch from the always-on user to the named user tunnel you shouldn't get stuck at 0.0.0.0 IP like that. 

[Paolo_Mercado]

You are getting this message if the IP Pool is already full or runs out already.