L2TP is disconnect after every 8 hours

Alexandrovav · Mon Aug 01, 2016 10:38 am

Hello.
There mikrotik 750GR2. Connecting to an Internet configured so. 2 ports are combined in the bridge. One port is plugged with a white asterisk ip. The second interface, set the other white ip LAN through which comes to internet. The 3-5 of the ports in the switch group and look to the local area network. Users go to the Internet through nat. On mikrotike set l2tp. Users connect windows (7 and xp) l2tp client and use the LAN resources. But every 8 hours connection unexpected disconnect. In this case, the log records mikrotik

failed to begin ipsec sa negotiation
<L2tp-test: terminating ...- hungup
<L2tp-test: disconnected

Help me please.

[admin@Mikrotik750GR2] /ip ipsec peer> print detail
Flags: X - disabled, D - dynamic
0 address=0.0.0.0/0 local-address=:: passive=no port=500 auth-method=pre-shared-key secret="111111111"
generate-policy=port-override policy-template-group=*FFFFFFFF exchange-mode=main-l2tp send-initial-contact=yes
nat-traversal=yes hash-algorithm=sha1 enc-algorithm=aes-256,aes-192,aes-128,3des dh-group=modp1024 lifetime=1h
dpd-interval=disable-dpd dpd-maximum-failures=5

[admin@Mikrotik750GR2] /ip ipsec proposal>> print detail
Flags: X - disabled, * - default
0 * name="default" auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-128-cbc,3des lifetime=30m pfs-group=modp1024

jeremyw · Wed May 24, 2017 4:58 pm

Following, I have having the issues with the same 8 hour disconnect

p3rad0x · Wed May 24, 2017 5:49 pm

You can try to change the profile from default-encryption to default and test if that solves the issue.

Sometimes the encryption gets out of sync and resulting that the tunnel gets terminated and the reconnects

mukeshchaubey · Thu Jun 01, 2017 10:54 am

Hi
I am facing similar issue . my l2tp client get disconnected after every 1 minute 14 sec. I have tried to check keepalive time and session time but could get success. can you guide me what could be the issue .
I get following log on l2tp client
disconnected
initializing
connecting.....
terminationg...---sesion closed
disconnected
....

hgonzale · Mon Jun 05, 2017 9:53 am

mukes, in your situation, you aren't connected ever. just ... connecting, but you never gets.... connected.

XTX · Mon Jul 17, 2017 9:36 am

Hi
I have exactly the same problem...all my L2TP/IPSEC session get disconnected after exactly 8 hours

Did someone manage to find a solution to this ?

Dejan · Tue Jul 18, 2017 8:12 am

Same here(Disconnect after 8h)...

Dejan · Thu Mar 08, 2018 3:41 pm

I have same problem. VPN is disconnected every 8h and then it can't be reconected for cca. 1 minute...

zingfrid · Sun Apr 15, 2018 8:29 am

Hello, I have exactly the same problem. My IPsec/L2TP connection drops every 8 hours. It takes it up to 50 minutes to recover. I've looks through the logs, but was not able to find anything wrong. I've checked on server side - timeout there 23 hours, on Mikrotik I did not found where timeout can be setup.

What else I could check/look at to fix this?

regi · Fri Apr 27, 2018 6:35 pm

seme here
rb1100ahx4 6.42.1
~8h on L2TP/IPSec

ingdaka · Sat Apr 28, 2018 12:41 pm

All of you: can you tell us what version of ROS you have, need to see if you are at same version, maybe there is a bug with!

Dejan · Sat Apr 28, 2018 1:00 pm

This is not ROS version related! I use it and have same issue from start using mikrotik products. Now Im on version 6.42.1 but issue is here in all version from 6.38 or maybe 6.36 I don't remember right but more than 3 years...

hgonzale · Sat Apr 28, 2018 2:00 pm

Yeah, it doesn't matter the version.
It happens to me sometimes with some "routers".
Did you check if the IP is changing in one side. Maybe the problem (i didn't check it) is the IP changing from the ISP...

Dejan · Sat Apr 28, 2018 2:09 pm

No ip is not changed because both sites have static IP's, links has not been disconnected. It is Mikrotik related and disconnect is done after exact 8h after connection is made.

hgonzale · Sat Apr 28, 2018 2:42 pm

Yes. It happens to me also, but know I didn't care about the disconnection because "now" it could happens to my links, but someday I will need a continuous link

Paternot · Sat Apr 28, 2018 3:50 pm

I have some L2TP over IPSec links. They don't have this behaviour. The weirder part is taking 50 minutes to reconnect.

/ppp active print detail
Flags: R - radius 
 0   name="victor" service=l2tp caller-id="---.---.126.90" address=0.0.0.0 uptime=2d10h48m15s encoding="cbc(aes) + hmac(sha256)" session-id=0x81200026 limit-bytes-in=0 limit-bytes-out=0 
 1   name="alfandega2" service=l2tp caller-id="---.---.8.65" address=0.0.0.0 uptime=21h50m45s encoding="cbc(aes) + hmac(sha256)" session-id=0x81200032 limit-bytes-in=0 limit-bytes-out=0 
 2   name="alfandega1" service=l2tp caller-id="---.---.166.68" address=0.0.0.0 uptime=14h49m54s encoding="cbc(aes) + hmac(sha256)" session-id=0x81200039 limit-bytes-in=0 limit-bytes-out=0

It must be some kind of timeout, or scheduled change on the ISP's network.

hgonzale · Sat Apr 28, 2018 4:23 pm

In my house now: (receiving)

Flags: R - radius
0 name="casavzla" service=l2tp caller-id="186.xx.xx.xx" address=192.168.16.11 uptime=3d14h33m3s encoding="cbc(aes) + hmac(sha256)"
session-id=0x81002F85 limit-bytes-in=0 limit-bytes-out=0

1 name="mayjo" service=l2tp caller-id="95.xx.xx.xx" address=192.168.16.10 uptime=9h31m1s encoding="cbc(aes) + hmac(sha256)" session-id=0x8100301C
limit-bytes-in=0 limit-bytes-out=0

I don't know how to print the outgoing ppp/pptp...

sindy · Sat Apr 28, 2018 9:53 pm

hgonzale, what are the clients in your case?
The thing is that as this topic made me curious, I've started an L2TP/IPsec connection using the embedded VPN client of Windows 10 and used it so that there would be real traffic through the L2TP session, and it broke down as well. In my case, it didn't take exactly 8 hours but something like 7:36 until the Windows client has decided to renew the IPsec phase 1, but it took it so long between tearing down the old one and starting to establish the new one that Mikrotik has managed to tear down the L2TP layer on inactivity in the meantime. See the commented tour below.

The DHCP lease time on the laptop side is 10 minutes so it is unlikely that this would be related, as there were tens of DHCP renewals which didn't break the IPsec. So I'll try another round during the night, this time with an Android device.

On top of that, there is no ISP involved - the laptop is connected using WiFi to one 'Tik (uptime much longer than between now and the L2TP breakdown), and the L2TP/IPsec connection passes through NATting OpenWRT device and gets to the other 'Tik which is the L2TP/IPsec server.

When the IPsec connection is initially established, the client declares sincerely the Phase 1 lifetime limitation to 8 hours:

11:22:22 ipsec,debug Compared: Local:Peer 
11:22:22 ipsec,debug (lifetime = 86400:28800)

28800 seconds means 8 hours

11:22:22 ipsec,debug (lifebyte = 0:0) 
11:22:22 ipsec,debug enctype = AES-CBC:AES-CBC 
11:22:22 ipsec,debug (encklen = 256:256) 
11:22:22 ipsec,debug hashtype = SHA:SHA 
11:22:22 ipsec,debug authmethod = pre-shared key:pre-shared key 
11:22:22 ipsec,debug dh_group = 2048-bit MODP group:2048-bit MODP group 
11:22:22 ipsec,debug an acceptable proposal found.

After this, the connection establishes and just works, only Phase 2 is renegotiated from time to time without impact.
Nothing indicates a problem just before the breakdown:

18:57:21 ipsec,debug KA: 192.168.10.88[4500]->10.0.0.5[4500] 
18:57:21 ipsec,debug 1 times of 1 bytes message will be sent to 10.0.0.5[4500] 
18:57:21 ipsec,debug,packet ff

KA means KeepAlive and it is an IPsec keepalive here. These are sent three times a minute.

18:57:29 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:57:29 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=456, nr=4 
18:57:29 l2tp,debug,packet     (M) Message-Type=HELLO 
18:57:29 l2tp,debug,packet rcvd control message (ack) from 10.0.0.5:1701 to 192.168.10.88:1701 
18:57:29 l2tp,debug,packet     tunnel-id=1263, session-id=0, ns=4, nr=457

This is an L2TP keepalive - the server sends HELLO and the client responds with ack. These are sent once a minute and they're asynchronous to the IPsec KeepAlives

18:57:41 ipsec,debug KA: 192.168.10.88[4500]->10.0.0.5[4500] 
18:57:41 ipsec,debug 1 times of 1 bytes message will be sent to 10.0.0.5[4500] 
18:57:41 ipsec,debug,packet ff 

18:58:01 ipsec,debug KA: 192.168.10.88[4500]->10.0.0.5[4500] 
18:58:01 ipsec,debug 1 times of 1 bytes message will be sent to 10.0.0.5[4500] 
18:58:01 ipsec,debug,packet ff 

18:58:21 ipsec,debug KA: 192.168.10.88[4500]->10.0.0.5[4500] 
18:58:21 ipsec,debug 1 times of 1 bytes message will be sent to 10.0.0.5[4500] 
18:58:21 ipsec,debug,packet ff

Here below the trouble begins:

18:58:24 ipsec,debug ===== received 92 bytes from 10.0.0.5[4500] to 192.168.10.88[4500] 
18:58:24 ipsec,debug,packet 2a859f74 83bfff84 66b1ac17 dc1967e4 08100501 227b959d 0000005c 35e16fc6 
18:58:24 ipsec,debug,packet 227f11e3 5d1d573e 97169e66 7d53809e 1c2cf21d e2a39f2d 55a276b0 2f09b4b2 
18:58:24 ipsec,debug,packet b9ccda68 403e04f4 d4f31281 4ab50866 ce73f92a 25b48241 04fba3be 
18:58:24 ipsec,debug receive Information. 
18:58:24 ipsec,debug compute IV for phase2 
18:58:24 ipsec,debug phase1 last IV: 
18:58:24 ipsec,debug 108b0de7 933fdadc c36cb287 3ee353ad 227b959d 
18:58:24 ipsec,debug hash(sha1) 
18:58:24 ipsec,debug encryption(aes) 
18:58:24 ipsec,debug phase2 IV computed: 
18:58:24 ipsec,debug c625865e d69af68e d7672100 66f32a20 
18:58:24 ipsec,debug encryption(aes) 
18:58:24 ipsec,debug IV was saved for next processing: 
18:58:24 ipsec,debug 4ab50866 ce73f92a 25b48241 04fba3be 
18:58:24 ipsec,debug encryption(aes) 
18:58:24 ipsec,debug with key: 
18:58:24 ipsec,debug 180cc989 150aa766 f2f526af bb0819cd c17f8f66 6632fc13 2eba948d c143a772 
18:58:24 ipsec,debug decrypted payload by IV: 
18:58:24 ipsec,debug c625865e d69af68e d7672100 66f32a20 
18:58:24 ipsec,debug decrypted payload, but not trimed. 
18:58:24 ipsec,debug 0c000018 7badbada 4bd6bb2c 2aaf50c0 56d9c747 d2b78da3 0000001c 00000001 
18:58:24 ipsec,debug 01100001 2a859f74 83bfff84 66b1ac17 dc1967e4 00000000 00000000 00000000 
18:58:24 ipsec,debug padding len=1 
18:58:24 ipsec,debug skip to trim padding. 
18:58:24 ipsec,debug decrypted. 
18:58:24 ipsec,debug 2a859f74 83bfff84 66b1ac17 dc1967e4 08100501 227b959d 0000005c 0c000018 
18:58:24 ipsec,debug 7badbada 4bd6bb2c 2aaf50c0 56d9c747 d2b78da3 0000001c 00000001 01100001 
18:58:24 ipsec,debug 2a859f74 83bfff84 66b1ac17 dc1967e4 00000000 00000000 00000000 
18:58:24 ipsec,debug HASH with: 
18:58:24 ipsec,debug 227b959d 0000001c 00000001 01100001 2a859f74 83bfff84 66b1ac17 dc1967e4 
18:58:24 ipsec,debug hmac(hmac_sha1) 
18:58:24 ipsec,debug HASH computed: 
18:58:24 ipsec,debug 7badbada 4bd6bb2c 2aaf50c0 56d9c747 d2b78da3 
18:58:24 ipsec,debug hash validated. 
18:58:24 ipsec,debug begin. 
18:58:24 ipsec,debug seen nptype=8(hash) len=24 
18:58:24 ipsec,debug seen nptype=12(delete) len=28 
18:58:24 ipsec,debug succeed. 
18:58:24 ipsec,debug 10.0.0.5 delete payload for protocol ISAKMP

So the client has sent us a request to delete the IPsec Phase 1 (ISAKMP), which consequently takes down Phase 2 (ESP in this case) as well.

18:58:24 ipsec,info purging ISAKMP-SA 192.168.10.88[4500]<=>10.0.0.5[4500] spi=2a859f7483bfff84:66b1ac17dc1967e4. 
18:58:24 ipsec purged IPsec-SA proto_id=ESP spi=0xeb151c6 
18:58:24 ipsec purged IPsec-SA proto_id=ESP spi=0x7670525 
18:58:24 ipsec,debug an undead schedule has been deleted. 
18:58:24 ipsec removing generated policy

The line above is important - as we've removed the policy, the L2TP packets won't be matched and sent via the SA although it still exists by now.

18:58:24 ipsec purged ISAKMP-SA 192.168.10.88[4500]<=>10.0.0.5[4500] spi=2a859f7483bfff84:66b1ac17dc1967e4. 
18:58:24 ipsec,debug purged SAs. 
18:58:24 ipsec,info ISAKMP-SA deleted 192.168.10.88[4500]-10.0.0.5[4500] spi:2a859f7483bfff84:66b1ac17dc1967e4 rekey:1 
18:58:24 ipsec KA remove: 192.168.10.88[4500]->10.0.0.5[4500] 
18:58:24 ipsec,debug KA tree dump: 192.168.10.88[4500]->10.0.0.5[4500] (in_use=1) 
18:58:24 ipsec,debug KA removing this one...

Demolition of the IPsec connection completed. The L2TP transport packets cannot get anywhere until the IPsec connection gets established again. But it's almost the time to send an l2tp HELLO...

18:58:29 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:29 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:29 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:30 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:30 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:30 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:31 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:31 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:31 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:33 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:33 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:33 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:37 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:37 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:37 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:45 l2tp,debug,packet sent control message to 10.0.0.5:1701 from 192.168.10.88:1701 
18:58:45 l2tp,debug,packet     tunnel-id=5, session-id=0, ns=457, nr=4 
18:58:45 l2tp,debug,packet     (M) Message-Type=HELLO 
18:58:53 l2tp,debug tunnel 1263 received no replies, disconnecting

You can see that the L2TP HELLOs are retransmited, doubling the delay with each retransmission (0.5 s, 1s, 2s, 4s, 8s), so after 23.5s in total, the server gives up waiting for an

ack

and initiates the disconnection process.

18:58:53 l2tp,debug tunnel 1263 entering state: dead 
18:58:53 l2tp,debug session 1 entering state: dead 
18:58:53 l2tp,ppp,debug <10.0.0.5>: LCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: LCP closed 
18:58:53 l2tp,ppp,debug <10.0.0.5>: CCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: BCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: BCP down event in starting state 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPCP closed 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPV6CP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPV6CP down event in starting state 
18:58:53 l2tp,ppp,debug <10.0.0.5>: MPLSCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: CCP close 
18:58:53 l2tp,ppp,debug <10.0.0.5>: BCP close 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPCP close 
18:58:53 l2tp,ppp,debug <10.0.0.5>: IPV6CP close 
18:58:53 l2tp,ppp,debug <10.0.0.5>: MPLSCP close 
18:58:53 l2tp,ppp,info l2tp-server-dedecek: terminating... - hungup 
18:58:53 l2tp,ppp,debug <10.0.0.5>: LCP lowerdown 
18:58:53 l2tp,ppp,debug <10.0.0.5>: LCP down event in starting state 
18:58:53 l2tp,ppp,info,account dedecek logged out, 27387 24129137 55951331 123213 106836 
18:58:53 l2tp,ppp,info l2tp-server-dedecek: disconnected 
18:58:53 ipsec,debug unbind ::ffff:192.168.99.1

Three seconds later, which is 32 seconds after it has shot down the previous Phase 1, the client initiates establishment of a new session:

18:58:56 ipsec,debug ===== received 408 bytes from 10.0.0.5[4500] to 192.168.10.88[4500] 
18:58:56 ipsec,debug,packet 42b08e69 f8f6c26e 00000000 00000000 01100200 00000000 00000198 0d0000d4 
18:58:56 ipsec,debug,packet 00000001 00000001 000000c8 01010005 03000028 01010000 80010007 800e0100 
18:58:56 ipsec,debug,packet 80020002 80040014 80030001 800b0001 000c0004 00007080 03000028 02010000 
18:58:56 ipsec,debug,packet 80010007 800e0080 80020002 80040013 80030001 800b0001 000c0004 00007080 
18:58:56 ipsec,debug,packet 03000028 03010000 80010007 800e0100 80020002 8004000e 80030001 800b0001 
18:58:56 ipsec,debug,packet 000c0004 00007080 03000024 04010000 80010005 80020002 8004000e 80030001 
18:58:56 ipsec,debug,packet 800b0001 000c0004 00007080 00000024 05010000 80010005 80020002 80040002 
18:58:56 ipsec,debug,packet 80030001 800b0001 000c0004 00007080 0d000018 01528bbb c0069612 1849ab9a 
18:58:56 ipsec,debug,packet 1c5b2a51 00000001 0d000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000009 
18:58:56 ipsec,debug,packet 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 90cb8091 3ebb696e 
18:58:56 ipsec,debug,packet 086381b5 ec427b1f 0d000014 4048b7d5 6ebce885 25e7de7f 00d6c2d3 0d000014 
18:58:56 ipsec,debug,packet fb1de3cd f341b7ea 16b7e5be 0855f120 0d000014 26244d38 eddb61b3 172a36e3 
18:58:56 ipsec,debug,packet d0cfb819 00000014 e3a5966a 76379fe7 07228231 e5ce8652 
18:58:56 ipsec,debug Marking ports as changed 
18:58:56 ipsec,debug Marking ports as changed 
18:58:56 ipsec,debug === 
18:58:56 ipsec,info respond new phase 1 (Identity Protection): 192.168.10.88[4500]<=>10.0.0.5[4500]

It then took another 2 seconds until new SAs were negotiated and installed:

...
18:58:58 ipsec,debug call pk_sendupdate 
18:58:58 ipsec,debug encryption(aes-cbc) 
18:58:58 ipsec,debug hmac(sha1) 
18:58:58 ipsec,debug call pfkey_send_update_nat 
18:58:58 ipsec IPsec-SA established: ESP/Transport 10.0.0.5[4500]->192.168.10.88[4500] spi=0x1f67a4 
18:58:58 ipsec,debug pfkey update sent. 
18:58:58 ipsec,debug encryption(aes-cbc) 
18:58:58 ipsec,debug hmac(sha1) 
18:58:58 ipsec,debug call pfkey_send_add_nat 
18:58:58 ipsec IPsec-SA established: ESP/Transport 192.168.10.88[4500]->10.0.0.5[4500] spi=0xf1a4f34 
18:58:58 ipsec,debug pfkey add sent. 
18:58:58 ipsec,debug ===== received 76 bytes from 10.0.0.5[4500] to 192.168.10.88[4500] 
18:58:58 ipsec,debug,packet 2a859f74 83bfff84 66b1ac17 dc1967e4 08100501 db32ba58 0000004c f1e52518 
18:58:58 ipsec,debug,packet baeb8459 5c9cdab5 29193055 b74da572 854a337a be9c47ed 70ba26e1 0004899f 
18:58:58 ipsec,debug,packet e0e045e9 bfbb4850 fb354c32 
18:58:58 ipsec 10.0.0.5 unknown Informational exchange received.

And it took another 8 seconds until the client started sending its own HELLO keepalives still within the old session (see the

ns

,

nr

values), which is however too late to help anything.

18:59:06 l2tp,debug,packet rcvd control message from 10.0.0.5:1701 to 192.168.10.88:1701 
18:59:06 l2tp,debug,packet     tunnel-id=1263, session-id=0, ns=4, nr=457 
18:59:06 l2tp,debug,packet     (M) Message-Type=HELLO 
18:59:16 l2tp,debug,packet rcvd control message from 10.0.0.5:1701 to 192.168.10.88:1701 
18:59:16 l2tp,debug,packet     tunnel-id=1263, session-id=0, ns=4, nr=457 
18:59:16 l2tp,debug,packet     (M) Message-Type=HELLO 
18:59:26 l2tp,debug,packet rcvd control message from 10.0.0.5:1701 to 192.168.10.88:1701 
18:59:26 l2tp,debug,packet     tunnel-id=1263, session-id=0, ns=4, nr=457 
18:59:26 l2tp,debug,packet     (M) Message-Type=HELLO

As Android client also limits the Phase 1 lifetime to 8 hours, I'll first check how the renegotiation looks like in Android case, and then I'll try whether configuring a shorter lifetime limit at RouterOS side won't make the client(s) behave differently.

hgonzale · Sat Apr 28, 2018 10:18 pm

All mines are other mikrotiks..

I have a dialup pptp to my server without encryption but is not in the list.
They are only dial in, I need to extract the dial out, but I don't know to do

sindy · Sun Apr 29, 2018 8:10 pm

The results with my version of the embedded Android client are even more cryworthy than with Windows 10.

The Android client, like the Windows 10 one, declares a 28800 seconds Phase 1 lifetime in its Phase 1 proposal, and when this time expires, RouterOS drops the connection, without any attempt from Android side to re-establish it before or after the drop. But the Andriod still shows the VPN connection as active and stubbornly attempts to use it, so you can see "packets/bytes sent" on it to grow but "packets/bytes received" stay unchanged, several hours after the connection went down.

I've limited the Phase 1 lifetime at Mikrotik side, assuming that it might actively terminate the Phase 1 security association and thus provoke the client for a renewal, or that the client might proactively renew the session from its side once the end of the lifetime announced by Mikrotik approaches; well, none of this happens. Mikrotik keeps the session alive (presumably because it is configured to server mode and is thus unable to renew it), and Android doesn't bother to renew it either, so the session continues to run. And the Windows client behaves the same way. I expect both sessions to end the same way like when 24 h lifetime is set on Mikrotik side, after 8 hours.

So I assume that gents in Redmond became aware of the issue and have added the auto-renewal into the WIndows10 client (which explains that these sessions do not last exactly 8 hours as reported before), but the auto-renewal takes it too much time (so far?) for the l2tp server not to give up.

If someone here happens to own some iThing, it might be interesting for the audience here to check how the iOS clients behave in this regard.

indnti · Tue Aug 28, 2018 5:27 pm

Same. After >>> exact 27387 seconds <<< the connection is disconnected. You can see the this number of seconds in sindys article:
"18:58:53 l2tp,ppp,info,account dedecek logged out, 27387 24129137 55951331 123213 10683"
My Router:
15:54:27 l2tp,ppp,info,account xxxxxx logged out, 27387 4952753 7800188 32252 34194
15:59:50 l2tp,ppp,info,account yyyyyy logged out, 27387 15171069 53018599 106079 108003
It only happens with Windows clients it seems. Other Mikrotik router don't hangup
Strange

sindy · Tue Aug 28, 2018 6:07 pm

Other Mikrotik router don't hangup
Strange

Nothing strange about Mikrotik not hanging up - it simply renegotiates continuation of the IPsec session when it is about to expire. What is strange is that the Windows client starts the renegotiation attempt but so late that the l2tp session times out, so it seems someone at Microsoft did realize that it was a problem and started addressing it but failed to do so efficiently. With Windows updates coming almost every other day, I would expect to see a difference 4 months later but probably no one has reported the issue to Redmond in the meantime

mrz · Tue Aug 28, 2018 6:30 pm

What is your ipsec configuration? Especially proposal part?
Windows require specific algorithms selected for rekey to work properly.

sindy · Tue Aug 28, 2018 6:38 pm

@mrz, look at the log in my post #18 above - the Windows client actively terminates Phase 1 and then re-establishes it, it is not a matter of Phase 2 rekey. I've done some tests with shorter Phase 1 lifetime at RouterOS side (post #20), didn't help.

mrz · Wed Aug 29, 2018 3:21 pm

I am talking about phase1 rekey not phase2

sindy · Wed Aug 29, 2018 3:28 pm

OK, do you have any particular suggestion regarding the /ip ipsec peer proposal in that case? The only recommendation regarding Windows clients in the manual is to set pfs-group to none which is related to phase 2.

regi · Wed Aug 29, 2018 5:32 pm

What is your ipsec configuration? Especially proposal part?
Windows require specific algorithms selected for rekey to work properly.

i have the same problem

Code: Select all

/ip ipsec peer

add address=0.0.0.0/0 dh-group=modp1024 enc-algorithm=aes-256,aes-192,aes-128,3des exchange-mode=main-l2tp generate-policy=port-override passive=yes \

    send-initial-contact=no

ip ipsec proposal is default without any changes
6.42.7 RB1100AHx4
all windows connections are droped after 7-8 hours
on old firmware aka ~6.20 it works

mrz · Wed Aug 29, 2018 7:58 pm

try to set lifetime on the router lower than 8hours so that router will initiate rekeying. If it does not help contact support.

sindy · Wed Aug 29, 2018 11:56 pm

@mrz, if I set /ip ipsec peer lifetime to less than 8h but keep the default value of proposal-check (obey), the router cannot initiate the phase 1 rekey because the Windows client tears the phase 1 down a bit earlier than after 28800s; if I set proposal-check to claim, both the Android (6.0.1) embedded client and the Windows10 embedded client fail to establish the connection. No point in trying any of the two remaining settings (exact, strict) as these cannot work by their nature.

on old firmware aka ~6.20 it works

Do you want to say it works right now (with the current version of the Windows client) with 6.20 or that you remember it worked back when you were running 6.20 in the past? I mean, unless you confirm that a contemporary Windows client works with 6.20 but doesn't with 6.42.7, the actual reason may be a change on Windows client side.

Cvan · Thu Aug 30, 2018 3:56 am

I have an L2TP connection between countries and it has been up steady for 6d 22:34:41 .. no issues.. the only problem it has is when the ISP connection on either side drops out, but then it re-connects as soon as the line is back. However, I do have to fix the fw rules to re-select the L2TP interface when that happens...

Dejan · Thu Aug 30, 2018 7:58 am

Cvan if I understand you right you have sucessfully run 6 days L2TP connection which has been done between Mikrotik router and Windows client? If yes please post configuration...
L2TP between two mikrotiks work fine and without any problems...
have this problem that connection is broken for more than 2 years and regulary update Mikrotik FW(If remember right from 6.29 maybe 6.27 when Im start using mikrotik)... It is same on Windows 7 and Windows 10 computer.

Cvan · Thu Aug 30, 2018 8:25 am

No, between 2 MT routers works great and between my iPhone and MT router I have had it stay connected for a day w/o dropping

Dejan · Thu Aug 30, 2018 8:57 am

Please read thread. We are talking about problem with combination Mikrotik<->Windows ...

Dejan · Fri Aug 31, 2018 9:15 am

@mrz Setting lower lifetime do not help. Im set lifetime in proposal to 30 min and lifetime in peer to 1 hour and still disconnect connection. It happen on all Mikrotiks which I have:
- 2011UiAS-2HnD
- 2011UiAS
- 953GS-5HnT
- RouterBOARD 1100Dx4
- RouterBOARD 3011UiAS
- RouterBOARD 962UiGS-5HacT2HnT
- RouterBOARD 952Ui-5ac2nD

So is not related to model or platform(ARM, MIPSBE...) but related to RouterOS ...

indnti · Thu Sep 13, 2018 9:05 am

[quote=sindy post_id=682621 time=1535468868 user_id=110692]
[quote=indnti post_id=682612 time=1535466477 user_id=10406]
Other Mikrotik router don't hangup
Strange
[/quote]
Nothing strange about Mikrotik not hanging up - it simply renegotiates continuation of the IPsec session when it is about to expire. What [b]is[/b] strange is that the Windows client starts the renegotiation attempt but so late that the l2tp session times out, so it seems someone at Microsoft did realize that it was a problem and started addressing it but failed to do so efficiently. With Windows updates coming almost every other day, I would expect to see a difference 4 months later but probably no one has reported the issue to Redmond in the meantime

[/quote]
No nothing strange with Mikrotik. I mean it's strange that Windows Clients hang up after exactly 27387 seconds

indnti · Thu Sep 13, 2018 10:35 am

[quote=Dejan post_id=682915 time=1535608660 user_id=79483]
Please read thread. We are talking about problem with combination Mikrotik<->Windows ...
[/quote]

Why didn't Mikrotik talk to Microsoft directly to dispose this incompatibility ?

rivonhsu · Tue Nov 06, 2018 5:31 am

Hi guys,

I'm dealing with the same problem here, that the windows client always got disconnected around 7.5 hours (L2TP over IPSec), and it took ~10min for it to recover. From the server side (mikrotik) ipsec debug logs, it shows almost the same as @sindy posted in #18. I'm wondering if anyone here had found a workaround or even a fix already?

sindy · Wed Nov 07, 2018 4:57 pm

I wonder whether it is clear enough from what I wrote that it is a Windows (and Android) issue, not a Mikrotik one. Other than that, have you tried the IKEv2 approach? At the moment, IKEv2 is equally user friendly as L2TP except that you have to deal with certificates, and it uses one encapsulation layer less so it is more bandwidth-efficient than L2TP if using the same encryption strength. And the RouterOS release candidate even promises to feed Windows with a list of subnets to access using the VPN the way Windows understand it (which could be done also for L2TP exactly the same way but Mikrotik has made no related statement). Plus it doesn't suffer from the "not more than one L2TP client behind the same public IP" issue which otherwise requires a brain damaging workaround. There are also drawbacks but for simple scenarios it may be enough.

regi · Wed Jan 02, 2019 2:10 am

Hi guys,

I'm dealing with the same problem here, that the windows client always got disconnected around 7.5 hours (L2TP over IPSec), and it took ~10min for it to recover. From the server side (mikrotik) ipsec debug logs, it shows almost the same as @sindy posted in #18. I'm wondering if anyone here had found a workaround or even a fix already?

workaround is to use cisco/fortigate/WinSrv as IPSec/L2TP server or downgrade mikrotik to ~6.20. I don't know exact version where it stops working - probably 6.25-6.30. ofc downgrading mikrotik is v. insecure.
finding exact version where it stopped working correctly is on my todolist

but most of community is ignoring this problem and official version is "this is Windows 7, Windows 8, Windows 8.1, Windows 10 1503-1809, Android 4.0-9.0 and other publishers and vendors problem. Miktorik to Mikrotik tunnels works fine" .. so im not motivated to help because i will waste my time only.

PS
maybe there is one more workaround but u need to look for it by yourself. i found something one day by accident. changing some peer or/and policy settings extended online connections time over 8h somehow.
maybe when settings are changed some internal action is triggered. probably something is reloaded or IPSec SA was reestablished without closing L2TP connection - dunno.
so u can look for IPSec settings which dont force L2TP connections to reconnect and tray to change them by script every 6h.
pls. give me feedback if u tray

rivonhsu · Wed Jan 02, 2019 5:18 am

@regi @sindy,
Thank you guys for the feedback and replies.
I understand this is caused by WIndows side, and I also confirm this behavior/issue only happens with Windows clients. Unfortunately I don't have other VPN routers (ex. Cisco) to set as L2TP/IPSec server, then test and see how Windows clients would behave, but still from the current behavior and logs I surely can't say it has anything to do with Mikrotik, especially when it works pretty well with other type of clients.

As for the workaround, since my application is relatively easy and simple, so at the beginning we just set the server to terminate the connection on every 7hrs (after the tunnel is established), and set the Windows client to automatically re-connect the L2TP/IPSec once again. At least the re-connection takes just seconds instead of the original ~minutes if we leave it there till 7.5hrs. In the end, we just replaced the Windows client with a Linux client couple of weeks ago to solve this problem once for all. This might not work for other people, because like i said, my application and the usage of the VPN is relatively easy and simple...

I'll share them here if I found any more clues in the future, but for now, I agree with what @segi said it's not worth the time for further investigation or action, since there is no evidence showing it has something to do with Mikrotik at the moment.

ploquets · Tue May 28, 2019 11:37 pm

Whats the solution or workaround?

ploquets · Tue May 28, 2019 11:45 pm

As for the workaround, since my application is relatively easy and simple, so at the beginning we just set the server to terminate the connection on every 7hrs (after the tunnel is established), and set the Windows client to automatically re-connect the L2TP/IPSec once again. At least the re-connection takes just seconds instead of the original ~minutes if we leave it there till 7.5hrs.

Could you tell us how you did this exactly ?
By scripting ? Or some attribute ?

What about Windows ? How to dial again automatically ?
I'm using Windows 10 and searched about it, but no clue.

sindy · Wed May 29, 2019 12:12 am

What about Windows ? How to dial again automatically ?
I'm using Windows 10 and searched about it, but no clue.

When I needed to make sure that a VPN type interface stays on and re-connects even if there is a network outage between the client and the server, I had to use a powershell script whose key element was rasdial vpn-interface-name, started at boot and running forever. One thing is L2TP's self-sufficient disconnection after 7.5 hours, another thing is network outages, so even with IKEv2 which seems not to suffer from the same 7.5 hour illness, you need the powershell script if the VPN should recover from the network outages automatically.

ploquets · Thu May 30, 2019 11:19 pm

What I did was:

At VPN Server side:

 /ppp profile set VPN session-timeout=7h

And at Windows side (Windows 10)
Imported this task (xml) on Windows Task Scheduler:

Save this code as a XML File

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <URI>\VPN Reconnect</URI>
  </RegistrationInfo>
  <Triggers>
    <EventTrigger>
      <Enabled>true</Enabled>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Application"&gt;&lt;Select Path="Application"&gt;*[System[Provider[@Name='RasClient'] and EventID=20226]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
      <Delay>PT1S</Delay>
    </EventTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions>
    <Exec>
      <Command>C:\Windows\System32\rasdial.exe</Command>
      <Arguments>VPN-NAME VPN-USER VPN-PASSWORD</Arguments>
    </Exec>
  </Actions>
</Task>

Please, replace:
VPN-NAME
VPN-USER
VPN-PASSWORD

Working like a charm.

kevinsaye · Tue Jul 02, 2019 7:20 am

Did you ever get a solution to the disconnect after 1 minute 14 seconds?

Hi
I am facing similar issue . my l2tp client get disconnected after every 1 minute 14 sec. I have tried to check keepalive time and session time but could get success. can you guide me what could be the issue .
I get following log on l2tp client
disconnected
initializing
connecting.....
terminationg...---sesion closed
disconnected
....

sindy · Tue Jul 02, 2019 6:09 pm

@kevinsaye, only logging can reveal what really happens.

Switch on the detailed logging of IPSEC and L2TP:
/system logging
add topics=ipsec,!packet
add topics=l2tp

Then, run /log print follow-only file=vpn-startup where topics~"ipsec|l2tp" and let the client try to connect. After it fails, break the /log print ... command and read the contents of the file.

modrik · Wed Jul 24, 2019 2:01 pm

What is your ipsec configuration? Especially proposal part?
Windows require specific algorithms selected for rekey to work properly.

Hello. Can u tell us about this specific algorithms?

modrik · Wed Jul 24, 2019 2:33 pm

What is your ipsec configuration? Especially proposal part?
Windows require specific algorithms selected for rekey to work properly.

Hello. Can u tell us about this specific algorithms? I have same problem and i also try to set lifetime on MT lower than 8 hrs, but i don't get positive result. (after change lifetime on MT, in logs i see that really lifetime value remains the same (8hrs))

Alexandepz · Fri Feb 21, 2020 8:53 am

Hi everyone!

Sorry for necroposting, but I have the exact same problem. Well, almost the exact same. I've got a VPN client inside office network - a Synology NAS box, which serves as a file share, chat server and so on. Also, there are a few remote clients which connect to the server by router's static WAN ip address. But if a client has been connected to the L2TP server for more than 7 hours ± 10-15 minutes, then the server will forcibly disconnect said client. Always. Zero exceptions. PPP \ L2TP \ IPsec logs go like this (apoligies for logs being backwards, Synology syslog server messes with the order):

1. A rekey happens about a minute before the disconnect. Maybe that's a coincedence, but IS IT? *vsauce music plays*

2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,info,ISAKMP-SA deleted 192.168.1.1[500]-192.168.1.3[500] spi:10ad5ea117d92fde:ce8a60fbab317f14 rekey:1
2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,purged ISAKMP-SA 192.168.1.1[500]<=>192.168.1.3[500] spi=10ad5ea117d92fde:ce8a60fbab317f14.
2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,removing generated policy
2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,purged IPsec-SA proto_id=ESP spi=0x6daf242
2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,purged IPsec-SA proto_id=ESP spi=0xb6458873
2020-02-19,06:20:59,Notice,192.168.1.1,user,ipsec,info,purging ISAKMP-SA 192.168.1.1[500]<=>192.168.1.3[500] spi=10ad5ea117d92fde:ce8a60fbab317f14.

2. After that the server starts to send echo requests, a peer doesn't respond and after 5 missed requests server shuts down the connection (and NAS own logs always clearly say that it was the server that closed the connection, not the Synology's VPN client).

2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,info,<l2tp-ppp1>: disconnected
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,info,account,""ppp1 logged out, 24583 45876 46034 822 825"""
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP down event in starting state
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,info,<l2tp-ppp1>: terminating... - peer is not responding
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: MPLSCP close
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPV6CP close
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPCP close
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: BCP close
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: CCP close
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: MPLSCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPV6CP down event in starting state
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPV6CP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPCP closed
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: IPCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: BCP down event in starting state
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: BCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: CCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP closed
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP lowerdown
2020-02-19,06:21:25,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP missed echo reply
2020-02-19,06:21:24,Notice,192.168.1.1,user,l2tp,ppp,debug,packet,    <magic 0x6c2c4102>
2020-02-19,06:21:24,Notice,192.168.1.1,user,l2tp,ppp,debug,packet, <192.168.1.3>: sent LCP EchoReq id=0x4
2020-02-19,06:21:24,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP missed echo reply
2020-02-19,06:21:23,Notice,192.168.1.1,user,l2tp,ppp,debug,packet,    <magic 0x6c2c4102>
2020-02-19,06:21:23,Notice,192.168.1.1,user,l2tp,ppp,debug,packet, <192.168.1.3>: sent LCP EchoReq id=0x3
2020-02-19,06:21:23,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP missed echo reply
2020-02-19,06:21:22,Notice,192.168.1.1,user,l2tp,ppp,debug,packet,    <magic 0x6c2c4102>
2020-02-19,06:21:22,Notice,192.168.1.1,user,l2tp,ppp,debug,packet, <192.168.1.3>: sent LCP EchoReq id=0x2
2020-02-19,06:21:22,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP missed echo reply
2020-02-19,06:21:21,Notice,192.168.1.1,user,l2tp,ppp,debug,packet,    <magic 0x6c2c4102>
2020-02-19,06:21:21,Notice,192.168.1.1,user,l2tp,ppp,debug,packet, <192.168.1.3>: sent LCP EchoReq id=0x1
2020-02-19,06:21:21,Notice,192.168.1.1,user,l2tp,ppp,debug,<192.168.1.3>: LCP missed echo reply
2020-02-19,06:21:20,Notice,192.168.1.1,user,l2tp,ppp,debug,packet,    <magic 0x6c2c4102>
2020-02-19,06:21:20,Notice,192.168.1.1,user,l2tp,ppp,debug,packet, <192.168.1.3>: sent LCP EchoReq id=0x0

The hardware is hex S, RouterOS and Routerboard firmware version is 6.46. All IPsec settings (policy, proposal, identity and so on) are system default or autogenerated.

 /ppp profile
add change-tcp-mss=yes comment="DEFAULT PROFILE" dns-server=8.8.8.8 local-address=192.168.2.1 name=l2tp_ipsec only-one=yes remote-address=vpn_pool use-encryption=no

/ppp secret
add comment="remote client 1" name=name1 profile=l2tp_ipsec remote-address=192.168.2.2 service=l2tp
add comment="Office NAS" local-address=192.168.2.1 name=name2 profile=l2tp_ipsec remote-address=192.168.2.2 service=l2tp

 /interface l2tp-server server
set authentication=mschap2 default-profile=l2tp_ipsec enabled=yes ipsec-secret=secret max-sessions=30 use-ipsec=required

Everything else works fine and dandy (btw, Synology VPN client has a very nice auto-reconnect option for VPN client, makes me really wonder why Microsoft can't do such a simple thing), clients and server can ping eachother with no problem, and the only weird hiccup are these disconnects.

BTW, is the default max MTU\MRU value (1450 bytes) is ok for L2TP connections, or I should try changing it to 1500?

cosminfaur · Thu Apr 09, 2020 4:57 pm

Hello,

@Sindy, thanks for your in-depth analysis. post #18
I am experiencing similar issues with Windows clients connecting to MikroTik L2TP.

Currently looking for a fix or workaround.
Using a CCR1009-7G-1C-1S+ with firmware 6.42.12 and 6.45.8 RouterOS version.

sindy · Fri Apr 10, 2020 1:05 am

Currently looking for a fix or workaround.

My suggestion for much more than a workaround is in post #38. Since the writing of that post, the delivery of the routing table to the Windows client via DHCPINFORM has made it at least to the "stable" version, if not to the "long-term" one.

For Android, you need Strongswan for IKEv2, and Strongswan has unusual requirements about the certificate (it looks for the identity authenticated by the certificate in the SAN field of the certificate, not in the CN), but that's not a big deal.

ssantos · Wed May 27, 2020 8:38 am

So it seems that there isn't any situation to fix the problem permanently. Personally, i did the following and fixed this problem, although it has a gap since i lose about 3 minutes of connection.
Windows 10 will hangup the connection at exactly 7h36m16s. I did checked it over 5 times. I already had a task in the windows task scheduler saying the pc to connect automatically to the vpn in a restart. You can create a task by following this post (and maybe alternating it a bit to meet your exact needs) : https://superuser.com/questions/737799/ ... at-startup
To the above steps i also made the task to repeat itself every 460min (7h 40m) just to be sure that it is indeed disconnected first because the task won't work if the connection is up at the time. I also changed the "stop" time to 60d (it has options up to 3d but you can type the number by yourself). It worked fine with no problems. By the way i hope they fix this in the future.

ronal01 · Tue Oct 13, 2020 8:23 pm

I had a similar problem, and it was, the DHCP offer, when the ip address expired