Native VPN client on android phone

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Native VPN client on android phone

L4 Transporter

I recently upgraded my PA 5050 to 7.1.9. Before that users could connect to the VPN could connect via their native VPN client on their android phones and today I got a call saying one user no longer could and it was failing on the encryption. Any ideas?

28 REPLIES 28

Could be ... Do you may be have something in the system logs when the clients tried to connect? Of if you don't know the connectiontimes: are there other messages which weren't there when a client tried to connect before the upgrade?

I do not have anything for the cisco client pre upgrade but I do for the global protect. the big difference seem to be  protocol GP uses tls and tcp where the cisco uses iksakmp. the GP looks like it is using a web browser type connection and the cisco as you said a straight ipsec tunnel

other issue is that even before the upgrade the mac version of global protect has never worked that is why people are using the native client

Same here. Not able to connect with the native iPhone vpn client connect to the GP-Gateway.  I am not passing the P1. P1 is ok but failing on the P2. Doing debug of the connection but still no joy:

 

2017-06-16 10:48:53.299 +0100 [PNTF]: {1000007: }: ====> PHASE-1 NEGOTIATION STARTED AS RESPONDER, AGGRESSIVE MODE <====
====> Initiated SA: 55.55.55.55[500]-10.10.10.10.DD[30199] cookie:7b1db97bc6b8fd1d:9cdf9cc1159f2d0f <====
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: FRAGMENTATION
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: RFC 3947
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: CISCO-UNITY
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: received Vendor ID: DPD
2017-06-16 10:48:53.300 +0100 [INFO]: {1000007: }: Selected NAT-T version: RFC 3947
2017-06-16 10:48:53.303 +0100 [INFO]: {1000007: }: Adding remote and local NAT-D payloads.
2017-06-16 10:48:53.303 +0100 [INFO]: {1000007: }: Hashing 10.10.10.10.DD[30199] with algo #4
2017-06-16 10:48:53.303 +0100 [INFO]: {1000007: }: Hashing 55.55.55.55[500] with algo #4
2017-06-16 10:48:53.303 +0100 [INFO]: {1000007: }: 2 fragments sent, total len 600.
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: Hashing 55.55.55.55[4500] with algo #4
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: NAT-D payload #0 verified
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: Hashing 10.10.10.10.DD[46937] with algo #4
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: NAT-D payload #1 doesn't match
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: NAT detected: PEER
2017-06-16 10:48:53.401 +0100 [INFO]: {1000007: }: reveived INITIAL-CONTACT notification.
2017-06-16 10:48:55.000 +0100 [INFO]: {1000007: }: Sending Xauth request
2017-06-16 10:48:55.000 +0100 [PNTF]: {1000007: }: ====> PHASE-1 NEGOTIATION SUCCEEDED AS RESPONDER, AGGRESSIVE MODE <====
====> Established SA: 55.55.55.55[4500]-10.10.10.10.DD[46937] cookie:7b1db97bc6b8fd1d:9cdf9cc1159f2d0f lifetime 3600 Sec <====
2017-06-16 10:48:55.171 +0100 [INFO]: {1000007: }: GP gateway GP-GW-N domain user () from 10.10.10.10.DD login rtn 2 lifetime 3600
2017-06-16 10:48:55.171 +0100 [PWRN]: {1000007: }: Ignored attribute INTERNAL_ADDRESS_EXPIRY
2017-06-16 10:48:55.172 +0100 [PWRN]: {1000007: }: Ignored attribute UNITY_BROWSER_PROXY
2017-06-16 10:49:11.483 +0100 [INFO]: {1000007: }: IKE ISAKMP KEY_DELETE recvd: cookie:7b1db97bc6b8fd1d:9cdf9cc1159f2d0f.
2017-06-16 10:49:11.505 +0100 [PNTF]: {1000007: }: ====> PHASE-1 NEGOTIATION STARTED AS RESPONDER, AGGRESSIVE MODE <====
====> Initiated SA: 55.55.55.55[500]-10.10.10.10.DD[30199] cookie:8de69a6a3cddc13f:0b788adbb7e9061e <====
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: FRAGMENTATION
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: RFC 3947
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: CISCO-UNITY
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: received Vendor ID: DPD
2017-06-16 10:49:11.505 +0100 [INFO]: {1000007: }: Selected NAT-T version: RFC 3947
2017-06-16 10:49:11.506 +0100 [INFO]: {1000007: }: Adding remote and local NAT-D payloads.
2017-06-16 10:49:11.506 +0100 [INFO]: {1000007: }: Hashing 10.10.10.10.DD[30199] with algo #2
2017-06-16 10:49:11.506 +0100 [INFO]: {1000007: }: Hashing 55.55.55.55[500] with algo #2
2017-06-16 10:49:11.566 +0100 [INFO]: {1000007: }: Hashing 55.55.55.55[4500] with algo #2
2017-06-16 10:49:11.566 +0100 [INFO]: {1000007: }: NAT-D payload #0 verified
2017-06-16 10:49:11.566 +0100 [INFO]: {1000007: }: Hashing 10.10.10.10.DD[46937] with algo #2
2017-06-16 10:49:11.566 +0100 [INFO]: {1000007: }: NAT-D payload #1 doesn't match
2017-06-16 10:49:11.566 +0100 [INFO]: {1000007: }: NAT detected: PEER
2017-06-16 10:49:12.000 +0100 [INFO]: {1000007: }: ====> PHASE-1 SA LIFETIME EXPIRED <====
====> Expired SA: 55.55.55.55[4500]-10.10.10.10.DD[46937] cookie:7b1db97bc6b8fd1d:9cdf9cc1159f2d0f <====
2017-06-16 10:49:12.000 +0100 [INFO]: {1000007: }: ====> PHASE-1 SA DELETED <====
====> Deleted SA: 55.55.55.55[4500]-10.10.10.10.DD[46937] cookie:7b1db97bc6b8fd1d:9cdf9cc1159f2d0f <====

@TranceforLife

Yes exactly what I am seeing that it is failing before phase 2, not sure what changed in the upgrade to 7.1.9 that would make this happen. What os version are you on? The GP client for mac is not working either does your's?

The issue is visible on 8.0.0 

l  am doing now an upgrade to my lab firewall to 8.0.2 . Will report back later

@TranceforLife

I wonder if it started with the 7.1 series, I am thinking it can't pass the pre-shared key corrected and do its phase 2 but not sure how that can be fixed

But again I cannot get the global protect client for mac does not work either

TAC found the answer to the issue is that with the upgrade to 7.1 there is a capital A under the portal/client authentication OS Any in the GUI and it was a lower case a in the 7.0 version. Once matched that up to what he saw in the command line it started working again with the native clientany.PNG

Hi,

 

Thanks for the update. I am still battling. Must be an issue with the configuration .....................

Here it the resolution from the TAC case

 

We found errors for the invalid proposal from the client and it was due to changes in Global Protect fields post the upgrade of PAN OS 7.1 (Bug 94883)

>> Checked the configuration on the firewall for the Global Protect and found OS field contain value "any" instead of "Any" was the root cause of connectivity issue using the Native Client.

> configure
# set global-protect global-protect-gateway <gateway_name> client-auth <client_auth_name> os Any
# commit

>> Post the above changes for the OS field the native clients were able to connect to the Global Protect Gateway and we have verified the connectivity

@TranceforLife

I just posted the tac case resolution information

@jdprovine You made my day!

On the GUI l had "Any" so anyway decided to override the config specifying again "Any". Commit. Boom all good))

 

IOS.PNG

 

@TranceforLife

TAC came through for both of us

I can confirm that i was able to solve the same issue with PANOS 7.1.10.

In my case in the CLI there was "any" and "Any" available.

We choosed Upper Case (which is not available in the GUI) and the Clients were able to connect again.

  • 8437 Views
  • 28 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!