Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_Guyear
Explorer

80.40 L2TP remote access users dropped after renegotiation

On a 77.30 standalone gateway ( using an 80.40 management server ) our L2TP remote access users could stay connected for an unlimited amount of time.

After upgrading the gateway to 80.40 our users are getting dropped after about 8 hours. This happens right after the renegotiation of  Phase1+phase2. I have been through all of the vpn debug logs and it looks like the renegotiation completes successfully but the connection is still dropped.

Has anyone found a solution to this problem in 80.40? I have been applying hotfixes as they come out and am now up to Ongoing 131.  These have fixed some issues with L2TP but not this one.

At the time of the drop in the firewall log i see  these 2 entries


Id: 98610405-6120-0000-61a8-6fa200000000
Marker: @A@@B@1638427242@C@1277101
Log Server Origin: 152.x.x.x
Time: 2021-12-02T07:02:58Z
Id Generated By Indexer: false
First: false
Sequencenum: 20
Category: Session
Event Type: Login
Name: L2TP
Login Option: Standard
Failed Login Factor Number:0
User DN: Unknown
User Groups: All Users
Re-authentication every: 8 hours
Login Timestamp: 2021-12-02T07:02:58Z
Source: 99.125.x.x
IP Protocol: 6
Destination Port: 443
Data Protocol: IPSec
Methods: 3DES + SHA1
Status: Success
Suppressed Logs: 0
Mobile Access Session UID: 61A86FA2-0000-0000-9861-040561200000
Data Encryption: 3DES + SHA1 + Group 2, Pre shared secrets
Last Update Time: 2021-12-02T07:02:58Z
Action: Log In
Type: Log
Blade: Mobile Access
Origin: fw2.sewanee.edu
Service: TCP/443
Product Family: Access

Followed by:

Id: 98611316-e39e-7e0f-61a8-6faab8cf0012
Marker: @A@@B@1638427242@C@1284570
Log Server Origin: 152.x.x.x
Time: 2021-12-02T07:03:06Z
Interface Direction: inbound
Interface Name: eth4
Id Generated By Indexer:false
First: true
Sequencenum: 19
Source: 99.125.x.x
Source Port: 1701
Destination: 152.x.x.x
Destination Port: 1701
IP Protocol: 17
User: <L2TP_machine_user>_10658159151012685838_1120329598916211330
Message: Cannot control L2TP tunnel owned by <L2TP_machine_user>_
VPN Feature: L2TP
Action: Drop
Type: Connection
Policy Name: new_rules_2
Policy Management: cpmanage
Db Tag: {696A09B6-67EB-6C4D-87D7-38AD5CFF65F9}
Policy Date: 2021-12-01T18:12:36Z
Blade: VPN
Origin: firewall2
Service: UDP/1701
Product Family: Access
Logid: 1
Interface: eth4
Description: Cannot control L2TP tunnel owned by <L2TP_machine_user>_

 

The only thing I see unusual in the vpn debug log is that on initial connection  I see HandleNatDPayloads: I am not behind a NAT!.
But after the renegotiation I see HandleNatDPayloads: I am behind a NAT!
The peer is always behind a NAT.

0 Kudos
1 Reply
mhuettig
Participant

Hi @Michael_Guyear ,

might be not a solution but a fix for your problem:

Have you increased the renegotiation time under "Global properties / Remote Access / SecureClient Mobile / Re-Authenticate user every " 1440 minutes or the time which fills your preference?

Regards

Michael

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events