Testing non-http mfa feature with GP

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.

Testing non-http mfa feature with GP

L3 Networker

Hi there.

 

Documentation is rather slim here. I've set ut MFA for web site access, and it works. When testing it for non-http, accessing a SSH server, it kills the SSH connects, but no 2FA challenge on my GP. 

 

What am I doing wrong? What's needed?

 

I've done this: "Set Enable Inbound Authentication Prompts from MFA Gateways to Yes"

 

https://www.paloaltonetworks.com/documentation/80/globalprotect/globalprotect-admin-guide/authentica...

 

Nothing on port 4501 in the logs. No pop-up on the GP client.

11 REPLIES 11

Community Team Member

Hi @gtomte,

 

I haven't played with that myself but here are a few things you could check :

 

When GP receives the UDP notification message from firewall with the Captive Portal URL link in it, GP compares this URL with the configured IP/FQDNs in the Trusted MFA Gateways list.  GP will drop the message if the URL doesn’t match this list.  So check if it matches.

 

Is UDP 4501 open on your client ?

 

Can you confirm if the firewall is sending out the UDP MFA notification messages ?

This should be visible in the global counters :

 

 

> show counter global filter delta yes | match mfa

appid_mfa_gp_notification 1 0 info appid pktproc notification message sent to GP client for MFA

 

On the GP client side you can check the GP Service client logs and GP Agent client logs (with debug level) for more details on how the GP client is handling this (if received).

 

Cheers !

-K.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

hi @kiwi 

 

i have tested this feature using SSH and my GP did prompt me to authenticate. However, after successful MFA authentication, the SSH client (using putty) will get an timeout error.  When I try to trigger the SSH session again, I get another notification for MFA authentication. Despite successful MFA authentication, I never get to access my server via SSH. 

 

If I am using RDP, the RDP session immediately gets terminated with the following error but I still get a MFA authentication notice on GP. Seems like RDP and SSH is unable to hold the session while waiting for the MFA authentication to complete. MFA for http service is working fine.  Any idea what is wrong here? 

Screen Shot 2017-07-26 at 12.08.44 PM.png   

Hi, were you able to make this working ?

L4 Transporter

I am having the same issue I believe. I have 8.1.3 and 4.0.7 GP and 4.1.5 GP clients all the same. If I packet capture I do see a UDP packet recevied on client over port 4501 as configured. However the source IP address appears to be the IP address of the protected resource, not of the trusted MFA Gateway.

 

I had this all working many many months ago and during the Beta of 8.0. I refreshed my MFA token knowning it was expired and then found it no longer works to prompt via GlobalProtect.

 

Everything is working just fine if it is a web site protected resource and use the standard man-in-the-middle style response page method.

I am getting a counter value for it on the firewall also:

 

> show counter global filter delta yes | match mfa

appid_mfa_gp_notification                  1        0 info      appid     pktproc   notification message sent to GP client for MFA

I'm seeing this exact same behavior (counter values on firewall going up, and packet capture on client shows udp messages received with correct mfa gateway name), did you ever get a resolution?

No, never have! TAC engineer lab'd it up but not the same scenario that I am using. HTTP/HTTPS works fine but noting that prompts the GP client. Sure seems like something is broken in the GP client. I was going to see if I had the 4.0.0 beta client that I know worked when I participated in the beta trials of that feature.

 

I have implemented a full workaround with the HTTP auth method in the meantime so the priority of this has dropped considerably.

 

What is bad about this is that the whole reason I went this route is RADIUS with MFA for the VPN authentication doesn't work. Then followed that with a workaround of non-HTTP(s) MFA not working and having to go with a third option. That is quite unacceptable. No home runs here on this project.

This anyone got this working?

MP

Help the community: Like helpful comments and mark solutions.

I haven't tried recently but I'm guessing it is still a no. Maybe I'll give it a try in 9.1 beta and GP beta I'm running in the lab now.

Hi guys,

   everyone was able to see it working?

 

Walter

If I remember correctly, the last time I saw it work was when the feature was introduced in beta. I haven't ever seen it successfully prompting in the client with production releases. Working with the support team never amounted to any fixes.

  • 10216 Views
  • 11 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!