undead schedule has been deleted: 'quick_i1prep' : What is 'quick_ilprep' ?????
Two FVS318N routers; latest available firmware.
I have an odd entry in my VPN log file between two FVS318N routers.
I won’t bore you with log files but want to ask if the entry below is odd to you.
an undead schedule has been deleted: 'quick_i1prep'.
Subject: Logs From FVS318N
[EHT_VPN_FVS318N]Mon Dec 12 15:01:20 2022(GMT-0500) [EHT_VPN_FVS318N][System][VIPSECURE] Ignore information because the message has no hash payload.
[EHT_VPN_FVS318N]Mon Dec 12 15:01:30 2022(GMT-0500) [EHT_VPN_FVS318N][System][VIPSECURE] Phase 2 negotiation failed due to time up. 0ce895c93a4c2c96:a42f7cfa2650210e:0000b8f9
[EHT_VPN_FVS318N]Mon Dec 12 15:01:30 2022(GMT-0500) [EHT_VPN_FVS318N][System][VIPSECURE] an undead schedule has been deleted: 'quick_i1prep'.
[EHT_VPN_FVS318N]Mon Dec 12 15:01:31 2022(GMT-0500) [EHT_VPN_FVS318N][System][VIPSECURE] Using IPsec SA configuration: 10.1.10.0/24<->10.1.18.0/24
What is ‘quick_ilprep’ ? Is that a phrase generated by the Netgear router?
It showed up 6 times in 24 hours. In 20 years I have not seen that expression used in Netgear log files and coincidently the ROUTER to ROUTER VPN TUNNEL is failing once a day for the past 2 days.
'quick_i1prep' is not the name of any policy or client ID I’ve created.
Can you shed light on why it is in my log file? Is this a Netgear generated key word?
Also, one other anomaly I’ve discovered is a user VPN profile with the Remote ID of “AbbyR_EHT_Remote” that connects OK but the ID gets renamed to “AbbyR_EHT_Remote9” in the VPN log file.
None of my other Netgear Clients end up with the Remote ID DNS being modified.
I’m using the Netgear VPN Client 6.40.004 client.
I’m concerned by the ‘quick_ilprep’ and AbbyR_EHT_Remote Remote ID having the ‘9’ appended to it because my routers got hacked 10 days ago and I had to pin reset and then re-image both routers and reprogram them both.
I accidently left the ‘remote administration’ option enabled.
Apparently someone got in and created two USER accounts that couldn’t be deleted. But after rebuilding both routers I have an issue where one router indicates the Tunnel is established when in fact it is not; and the opposite router does see that the Tunnel is NOT established. I have to power cycle the one router that incorrectly claims the Tunnel is established to clear the issue. Disabling the policy and re-enabling the policy wont fix the issue, nor does using the DISCONNECT button. Yet about 24 hours later the tunnel stops working again with the same symptom.
I’m replacing the router that seems to be confused with another FVS318N.
Any comments or guidance you can offer will be very much appreciated.
