Pre Logon then On Demand

[Ben-Price]

Hi All,

I have a question regarding Pre-Logon and then on demand.

A client has reported they have setup pre-logon tunnel rename timeout to 90 secs. After the client logs in, the GP client goes into a disconnecting state and never times out. Client has to select refresh connection to resolve the issue, and then login manually. 

I have tested in our lab and get the below results:

When the pre-tunnel timeout is set to 90 seconds in our lab the tunnel stays connected through client login, is then renamed to user mode and stays connected, no manual login required. If I change the tunnel timeout to a value between 0 - 20 secs, the pre-logon tunnel is terminated as the user logs in and then the user has to login to GP manually.

I'm testing with:

PAN OS 9.1.11-h3 as 9.1.11 is not longer available.

GP 5.2.11-10

Client testing with: 

PAN OS 9.1.11

GP 5.2.11-10

What is the expected behavior here?

My understanding is that if I set a value between 0 - 600 secs for the pre-logon tunnel timeout, the pre logon tunnel will stay connected for that time, and once that time expires the tunnel is terminated and the client needs to login manually.

Any insight would be greatly appreciated. 

@BPry 

[S.Cantwell]

Hello

My understanding is that prelogin  uses a machine certificate to auth to the network, to establish a connection for troubleshooting/password expirations, etc.   After a person logs in, I would expect the pre-login to terminate and then the user would manually connect to the VPN.   I am not in agreement that after the pre-logon expires that the user must manually connect. 

I am not sure why there is a use case for manipulating the timer.. your 0 to 20 secs sounds more realistic/reasonable for the feature set that PANW created... boot a machine up... prelogin vpn created, user logs on... vpn terminates until user creates their vpn again.  What is the use case for needing to change any time out settings (just want to learn/expand my knowledge. :P)

[BPry]

@Ben-Price,

How long does it take for your login process to actually complete? If it's over the specified Pre-Login Tunnel Rename Timeout then I would expect to see it disconnect until the user connects. One the user authenticates on a Windows machine the tunnel just gets renamed as long as the Tunnel Rename Timeout hasn't been met. On a macOS endpoint the tunnel is torn down and re-created with the user credentials.

Have you taken a look at the PanGPS log on the client end to see what the logs are stating the disconnect reason is? That's the first place I would take a look to see why your entering that disconnected state.

[Ben-Price]

@BPry OK so what I am seeing in my lab seems to be correct, as per the below:

If the tunnel rename timeout timer expires during the login process, the pre-logon tunnel is terminated and I then need to manually connect via the GP agent. 

If the tunnel rename timeout timer does not expire during the login process, pre-logon tunnel is just renamed to the logged in user and the VPN connection stays connected.

Is that correct?

The logs show the tunnel disconnecting due to the grace period expiring (see below).

(P5124-T11096)Debug(11056): 03/31/22 12:37:37:469 CPanMSService::Disconnect(): reason is Grace period expires, do not set network discover event for on-demand mode.
(P5124-T11096)Debug(7068): 03/31/22 12:37:37:469 --Set state to Disconnected
(P5124-T11096)Dump (1020): 03/31/22 12:37:37:469 status is Disconnected

Client is saying that even though it disconnects here, they can not just go to the agent and click connect. They need to navigate to the hamburger menu and select refresh connection first and then click connect. I am not experiencing this issue in the lab. 

[rohill]

Has anyone solved this issue.  I have pre logon users experiencing the same errors.  The Prelogon is successful, tunnel established and then a disconnect. 

(P5132-T8412)Debug(5160): 03/14/23 08:36:19:041 Gateway, response to the hip report :

<response status="success">
<notification></notification>
</response>

(P5132-T8412)Info (5162): 03/14/23 08:36:19:041 sent HIP report to "gateway"
(P5132-T8412)Debug(5190): 03/14/23 08:36:19:041 Response status of HIP report is success, gateway 
(P5132-T8412)Debug(5192): 03/14/23 08:36:19:041 Hip report returns success.
(P5132-T8412)Info (4956): 03/14/23 08:36:19:041 Got hip notification from gateway 
(P5132-T8412)Debug(4964): 03/14/23 08:36:19:041 Hip notification is empty in the HIP report check response from gateway 
(P5132-T8412)Debug(4977): 03/14/23 08:36:19:074 SSL is disconnected. Returns TRUE.
(P5132-T8412)Debug(1677): 03/14/23 08:36:19:074 SendHipReportToGateway  returns TRUE.
(P5132-T8412)Info ( 991): 03/14/23 08:36:19:074 return without process!!!! socket=1372, os=14
(P5132-T8412)Debug(6333): 03/14/23 08:36:19:076 HipReportThread: wait for HIP report ready event.
(P5132-T7160)Debug(1134): 03/14/23 08:36:22:726 ipsec replay check failed: seq was received, replay_seq 2162, seq 2162
(P5132-T7160)Debug(1134): 03/14/23 08:36:23:728 ipsec replay check failed: seq was received, replay_seq 2198, seq 2198
(P5132-T5136)Debug( 348): 03/14/23 08:36:49:923 Received session change, event type 5, session 2
(P5132-T5136)Debug(1470): 03/14/23 08:36:49:923 Previous user count is 0
(P5132-T5136)Debug(1472): 03/14/23 08:36:49:923 First logon user.
(P5132-T5136)Debug(3641): 03/14/23 08:36:49:923 bDisabled 0, IsVPNConnected() 1, m_userName pre-logon
(P5132-T5136)Debug(3658): 03/14/23 08:36:49:923 Prelogon does not allow rename timeout
(P5132-T5136)Debug(1486): 03/14/23 08:36:49:923 First logon user not in grace period
(P5132-T5136)Debug(11057): 03/14/23 08:36:49:923 m_preUsername pre-logon
(P5132-T5136)Debug(1441): 03/14/23 08:36:49:923 m_msp->IsVPNConnected() is 1, CControlManager::GetInstance()->IsInRetry() is 0
(P5132-T5136)Debug(7095): 03/14/23 08:36:49:932 --Set state to Disconnecting...
(P5132-T5136)Info ( 991): 03/14/23 08:36:49:932 return without process!!!! socket=1372, os=14
(P5132-T5136)Info (2681): 03/14/23 08:36:49:932 Disconnect(First logon user not in grace period) called

[rohill]

I may have found my solution.  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000kGW6CAM

will provide update if it worked.