360 VPN Will Not Connect, But Norton Log Says It Did?

TWO identical PC's configured as below on the same network.
Norton Lifelock 360 Version 22.21.1.151
Windows 10 Home 1909 18363.1256
Windows Defender and Firewall Deactivated via Norton WSC
WiFi network profiles are set to PRIVATE; Netbios and IPV6 are disabled

Prior to March 23rd: Open My Norton, select region, start VPN, surf and stream at leisure, stop VPN, no problems.


Starting March 23rd the following occurs:

Problem 1


PC1 - Select region, activate VPN, surf and stream at leisure.
HOWEVER when disconnecting from VPN, network connection NO INTERNET, cannot navigate the web aka is lost in DNS Never Never Land. Windows troubleshooter indicates the DNS server isn't responding.


Running this batch file from Command Prompt Admin level
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns
ipconfig /registerdns
and a restart fixes the issue, UNTIL the next time VPN is EXITED which is an annoying mobius loop.


Problem 2
PC2 Select region, attempts to start VPN yield following message: "Connection Error: Secure VPN has experienced a connection failure. Please try again later."


Network connection falls to NO INTERNET, cannot navigate the web aka lost in DNS Never Never Land. Windows troubleshooter indicates the DNS server isn't responding.


Running the batch file listed above and a restart fixes the DNS issue, but NOT the VPN connection error issue.

Now here is where things get interesting...


Norton logs on BOTH PC's reveal:
Firewall Rule NORTON VPN is in place and functional allowing UDP traffic on Port 500 and 4500
Protecting newly detected network NortonSecureVpn
IP Address disappears from NortonSecureVpn

PC #2 never makes a connection, so why are those dated and time stamped entries present?
Somebody's watchdog is sleeping on the job.


Remedies attempted:


#1 CHANGE DNS SERVERS
Wireless router and both PC IP4 adapters were set statically to primary Google 8.8.8.8; secondary Cisco OpenDNS 208.67.222.222 
Switched DNS to Primary Quad 9 9.9.9.9 and Secondary CloudFlare 1.1.1.1 on both PC's and Router.
Surfs faster, but no difference as above errors are persistent.


#2 Power cycle modem and wireless router
#3 Uninstall and reinstall WAN Miniport drivers
#4 Reset network adapter and TCP/IP stack (see batch file)
#5 Root certificates for Norton Secure VPN all check out.
#6 Uninstall Norton remove all user data, restart, reinstall


None of the above resolve either issue.
If my ISP was blocking the VPN, NEITHER PC would connect.
Turning off the SMART FIREWALL changes nothing, so we don't have a firewall rule conflict
Nothing was changed on either PC or the network, except NORTON virus def and product updates.

It appears that a Norton Update changed something, which in both PC1 and PC2 is stepping on the DNS function, and...

in the case of PC1 disallowing a VPN connection, yet maintaining log entries to the contrary.

Any thoughts, answers or help are appreciated.
Update #20


NOTE: The following observations are from May 8th which is POST roll out of Norton Lifelock 360 version 22.21.3.48


Uninstall Norton VPN standalone 4.1.0.149

Uninstall and reinstall WAN Miniport drivers

Reset network adapter and TCP/IP stack (see batch file above)

PC wifi off, airplane mode on, airplane mode off, wifi on 

Power cycle modem and wireless router

Restart PC


Result: Norton Lifelock 360 VPN now appears to be functioning normally with either orderly turn off prior to zone switch OR autojumping zones without turning off.  Run update see if that hoses it. Defs were updated, program not required. Post def update VPN still functioning normally.



We will now install and run Norton VPN standalone 4.1.0.149, all general settings OFF, adblocker ON, autoupdate OFF,  forget split tunnel.


1st connect to local zone goes OK, turn off. Autoselect zone 809 error, US 809 error, constant 809 errors, its hosed.


Uninstall and reinstall WAN Miniport drivers

Reset network adapter and TCP/IP stack (see batch file above)

PC wifi off, airplane mode on, airplane mode off, wifi on 

Restart PC


Result: Norton VPN standalone 4.1.0.149 now functions normally with either orderly turn off prior to zone switch OR autojumping zones without turning off.


End result: It appears that mixing the two products during the same session, will result in one stepping on the others IP stack.  When one tells the Doctor, it hurts when I do that, the Doctor replies: don't do that. Said mix n match issue remains to be worked out by software development.


We wait to hear if Norton are refunding 2021 subscription fee with a 45 day extension AND providing compensation to the customer for: 


1. inconvenience, harassment and annoyance


2. time lost due to:


3. multiple organizational deficiencies in product development and technical support;


4. subsequently associated CRM gap analysis;


5. software related ad hoc, comparison (two products) and smoke testing;


6. documentation and report services for all the above (provided above).
   


Will Mr. Clarkson and Norton management step up, take ownership and make things right with the customer?  Hopefully we won't have another deficiency to report.
Update #19


Following are corresponding RASCLIENT (Windows Event Viewer - Windows Logs - Application) and NORTON HISTORY log entries during testing on April 24.


NOTE: Norton Lifelock 360 version 22.21.2.50 - which is PRIOR to roll out of version 22.21.3.48


SOE in RASCLIENT for an unsuccessful Norton 360 VPN attempt:


1. 4/24/2021 13:14:32 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The user SYSTEM has started dialing a VPN connection using a per-user connection profile named NortonSecureVpn. The connection settings are: 


Dial-in User = 
VpnStrategy = IKEv2
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = Machine Certificate 
Ipv4DefaultGateway = Yes
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = 
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.


2.  4/24/2021 13:14:32 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The user SYSTEM is trying to establish a link to the Remote Access Server for the connection named NortonSecureVpn using the following device: 

Server address/Phone Number = 18.185.116.99
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.


3. 4/24/2021 13:14:32 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The user SYSTEM has successfully established a link to the Remote Access Server using the following device: 

Server address/Phone Number = 18.185.116.99
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.


4. 4/24/2021 13:14:32 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The link to the Remote Access Server has been established by user SYSTEM.


5. 4/24/2021 13:14:33 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The user SYSTEM has dialed a connection named NortonSecureVpn to the Remote Access Server which has successfully connected. The connection parameters are:

TunnelIpAddress = 10.252.0.106
TunnelIpv6Address = None
Dial-in User = .:


6.  4/24/2021 13:14:33 CoId={488B2469-CE67-4B8A-9F45-27DF9D7036C3}: The user SYSTEM dialed a connection named NortonSecureVpn which has terminated. The reason code returned on termination is 631.


Note SOE: 1. Start dial; 2. Try to establish; 3. Successful link server IP; 4. Link established by system; 5. Connection Tunnel IP addr;  


However, successful connection was 6. terminated by the program which is what error 631 means.



Corresponding NORTON HISTORY SOE:


1. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:14:32,Info," Rule \"VPN UDP Rule\" allowed  UDP(17)  traffic with de.nsv4w.com (18.185.116.99  Port (500) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "VPN UDP Rule"<br> Rule Action: allowed<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  UDP(17) <br> Direction: outbound<br> Local Host: JCVAIO<br> Local IP: 192.168.1.104<br> Local Service:  Port (500) <br> Remote Host: de.nsv4w.com<br> Remote IP: 18.185.116.99<br> Remote Service:  Port (500) <br> Remote MAC:  -- <br> Adapter Index: 19<br> <br> Process Information:<br> Process ID: 4768<br> Process Path: C:\Windows\System32\svchost.exe<br> 


2. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:14:32,Info," Rule \"VPN UDP Rule\" allowed  UDP(17)  traffic with de.nsv4w.com (18.185.116.99  Port (4500) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "VPN UDP Rule"<br> Rule Action: allowed<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  UDP(17) <br> Direction: outbound<br> Local Host: JCVAIO<br> Local IP: 192.168.1.104<br> Local Service:  Port (4500) <br> Remote Host: de.nsv4w.com<br> Remote IP: 18.185.116.99<br> Remote Service:  Port (4500) <br> Remote MAC:  -- <br> Adapter Index: 19<br> <br> Process Information:<br> Process ID: 4768<br> Process Path: C:\Windows\System32\svchost.exe<br> 


3. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:14:33,Info," Rule \"Default Block Windows File Sharing \" rejected  TCP(6)  traffic with  (0.0.0.0  Port (0) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "Default Block Windows File Sharing "<br> Rule Action: rejected<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  TCP(6) <br> Direction: inbound<br> Local Host: <br> Local IP: 10.252.0.106<br> Local Service:  Port (139) <br> Remote Host: <br> Remote IP: 0.0.0.0<br> Remote Service:  Port (0) <br> Remote MAC:  -- <br> Adapter Index: 0<br> <br> Process Information:<br> Process ID: 4<br> Process Path: System<br> 


4. Category: Firewall - Network and Connections
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:14:33,Info,"Protecting your connection to a newly detected network on adapter \"NortonSecureVpn\" (IP address: 10.252.0.106).",Detected,No Action Required,Firewall - Network and Connections
Protecting your connection to a newly detected network on adapter "NortonSecureVpn" (IP address: 10.252.0.106). 


5. Category: Firewall - Network and Connections
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:14:33,Info,IP address has disappeared from adapter NortonSecureVpn (IP address: 10.252.0.106).,Detected,No Action Required,Firewall - Network and Connections
IP address has disappeared from adapter NortonSecureVpn (IP address: 10.252.0.106). 


Note SOE: 1. Firewall UDP 500; 2. Firewall UDP 4500; 3. Default BLOCK file sharing 0.0.0.0; 4. Protecting connection; 5. IP has disappeared from adapter NortonSecureVPN. 



SOE in RASCLIENT for an successful Norton Standalone VPN attempt:


1. 4/24/2021 13:23:27 CoId={857B88E3-D6F1-4E7B-9A9E-4DFA8FDFD3CC}: The user SYSTEM has started dialing a VPN connection using a per-user connection profile named NortonSecureVpn. The connection settings are: 

Dial-in User = 
VpnStrategy = IKEv2
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = Machine Certificate 
Ipv4DefaultGateway = Yes
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = 
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.


2. 4/24/2021 13:23:27 CoId={857B88E3-D6F1-4E7B-9A9E-4DFA8FDFD3CC}: The user SYSTEM is trying to establish a link to the Remote Access Server for the connection named NortonSecureVpn using the following device: 
Server address/Phone Number = 185.94.193.186
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.


3. 4/24/2021 13:23:27 CoId={857B88E3-D6F1-4E7B-9A9E-4DFA8FDFD3CC}: The user SYSTEM has successfully established a link to the Remote Access Server using the following device: 
Server address/Phone Number = 185.94.193.186
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.


4. 4/24/2021 13:23:27 CoId={857B88E3-D6F1-4E7B-9A9E-4DFA8FDFD3CC}: The link to the Remote Access Server has been established by user SYSTEM.


5. 4/24/2021 13:23:27 CoId={857B88E3-D6F1-4E7B-9A9E-4DFA8FDFD3CC}: The user SYSTEM has dialed a connection named NortonSecureVpn to the Remote Access Server which has successfully connected. The connection parameters are:
TunnelIpAddress = 10.252.1.164
TunnelIpv6Address = None
Dial-in User = .


Note SOE: 1. Start dial; 2. Try to establish; 3. Successful link server IP; 4. Link established by system; 5. Connection Tunnel IP addr;  




Corresponding NORTON HISTORY SOE:


1. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:23:27,Info," Rule \"VPN UDP Rule\" allowed  UDP(17)  traffic with ipsec.nsv4w.com (185.94.193.186  Port (500) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "VPN UDP Rule"<br> Rule Action: allowed<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  UDP(17) <br> Direction: outbound<br> Local Host: JCVAIO<br> Local IP: 192.168.1.104<br> Local Service:  Port (500) <br> Remote Host: ipsec.nsv4w.com<br> Remote IP: 185.94.193.186<br> Remote Service:  Port (500) <br> Remote MAC:  -- <br> Adapter Index: 19<br> <br> Process Information:<br> Process ID: 4768<br> Process Path: C:\Windows\System32\svchost.exe<br> 


2. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:23:27,Info," Rule \"VPN UDP Rule\" allowed  UDP(17)  traffic with ipsec.nsv4w.com (185.94.193.186  Port (4500) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "VPN UDP Rule"<br> Rule Action: allowed<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  UDP(17) <br> Direction: outbound<br> Local Host: JCVAIO<br> Local IP: 192.168.1.104<br> Local Service:  Port (4500) <br> Remote Host: ipsec.nsv4w.com<br> Remote IP: 185.94.193.186<br> Remote Service:  Port (4500) <br> Remote MAC:  -- <br> Adapter Index: 19<br> <br> Process Information:<br> Process ID: 4768<br> Process Path: C:\Windows\System32\svchost.exe<br> 



3. Category: Firewall - Activities
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:23:27,Info," Rule \"Default Block Windows File Sharing \" rejected  TCP(6)  traffic with  (0.0.0.0  Port (0) )",Detected,No Action Required,Firewall - Activities
Firewall rule was matched:<br> Rule Name: "Default Block Windows File Sharing "<br> Rule Action: rejected<br> Rule Severity: normal<br> <br> Traffic Details:<br> Protocol:  TCP(6) <br> Direction: inbound<br> Local Host: <br> Local IP: 10.252.1.164<br> Local Service:  Port (139) <br> Remote Host: <br> Remote IP: 0.0.0.0<br> Remote Service:  Port (0) <br> Remote MAC:  -- <br> Adapter Index: 0<br> <br> Process Information:<br> Process ID: 4<br> Process Path: System<br> 



4. Category: Firewall - Network and Connections
Date & Time,Risk,Activity,Status,Recommended Action,Category
4/24/2021 13:23:27,Info,"Protecting your connection to a newly detected network on adapter \"NortonSecureVpn\" (IP address: 10.252.1.164).",Detected,No Action Required,Firewall - Network and Connections
Protecting your connection to a newly detected network on adapter "NortonSecureVpn" (IP address: 10.252.1.164). 



5. Category: Firewall - Network and Connections
Date & Time,Risk,Activity,Status,Recommended Action,Gateway IP Address
4/24/2021 13:23:30,Info,Connected to a public network. (0.0.0.0),Protected,No Action Required,0.0.0.0
Your computer is currently protected from the local network. To allow all the computers on this network to communicate with your computer, in the <b>Actions</b> panel, click <b>Trust</b>. To block all the computers on this network from communicating with your computer, in the <b>Actions</b> panel, click <b>Restrict</b>.  This will not interfere with your other online communications. 


Note SOE: 1. Firewall UDP 500; 2. Firewall UDP 4500; 3. Default BLOCK file sharing 0.0.0.0; 4. Protecting connection;


In the unsuccessful connection the IP addr disappears, it does not here. Instead 5. a connection to 0.0.0.0 local network. 



Update #18 - DAY THIRTY OF AN EXPERIMENT IN TERROR


After several days Norton VPN standalone 4.1.0.149 connects but usually only if you DISCONNECT after each VPN connection, then RECONNECT.  Although it will work, AUTO hopping between zones is NOT advisable as it will eventually yield Rasclient Error 87.


VPN Error 87: The parameter is incorrect
This error shows up when there is a problem with the Windows networking stack as a whole.


The odd thing is even after invoking an error 87, you can still connect to some zones. By waiting several seconds and attempting to reconnect, success.  After several successful attempts finally an error 87, checking the Rasclient log indicates an IP server address in the destination country belonging to M247 which is the provider for Norton in that zone, and a subsequent handoff to a locally masked Tunnel IP; then shows the error code returned on failure is 0


We found this antique gem re: error code 0


http://www.chicagotech.net/netforums/viewtopic.php?t=1944


By rapidly AUTO switching zones we blew it up several times in succession, and it finally went into the spin mode, where it doesn't know its own IP, so we killed the process with Task Manager. The last connection attempt which invoked the spin was to New Zealand; "what is my ip" indicates a New Zealand IP address, DNSleak confirms.  The stack is hung, but only temporarily as within a minute, we are now back to a local IP from our ISP with DNS leaking.


After a  reset and restart, we invoke an error 87 trying to go to the Ukraine, Rasclient says success, what IP says is Ukraine with no DNS leaks.  Attempting to reconnect to Ukraine, good night Irene, SPIN CITY, kill process, stuck in a Ukrainian tunnel but only for a minute, back to local ISP with leaks.


At the end of the day, if you disconnect after each connection no problem.  If you go SLOW on AUTO hopping, occasional error squeaking. If you go fast on AUTO hopping, many problems, errors and eventually KABOOM.  The problem has to be a combination of VPN server response latency or lag, and the process watchdog.

The only good thing we can say is, at least in standalone VPN you CAN get a connection and it will hold.


And now this...


After several days Norton 360 VPN cannot connect period, failure error with Rasclient log entries that indicate successful connection to the destination country server i.e. US an IP for Amazon who is Nortons US ISP provider, and subsequent hand off of a masked Tunnel IP address. NO ERRORS LISTED in Norton or Rasclient and no such connection.


Resetting WAN Miniport IP drivers, running the batch file which resets winsock, stack and DNS, and a restart do nothing for Norton 360 VPN.


We are in a fixed state in which errors can be reproduced on standalone VPN, non functionality is confirmed on 360 VPN, and as a result we have ISOLATED the source of the problems. 


The "connectivity" of the standalone VPN product allows for this luxury. Note the ONE thing we have NOT done in the recent tests, uninstall and reinstall Norton 360. Which tells us the source of ALL the problems = NORTON.  Otherwise, the standalone product would not function either.


FYI, I have been offered a complete refund with a 30 day extension to the one year license. 


40 years of customer service in delivering IT based business solutions includes: We enjoy getting to the root of client problems and providing solutions as much as the next professional.


However, even at full retail price the refund would be nowhere near my time taken up by Norton support to date.  Much less my time invested in testing and reporting in detail about it here for the benefit of the customer base and Norton supports KNOWLEDGEBASE.  


We registered for the Voltage Secure Email, no bank details required. And now they want to make another appointment so they can call me to set up a connect session, to attempt to recreate what I have done and log it. This is an experiment in terror re: CRM = CUSTOMER RELATIONSHIP MGMT. 


From the copious forums with this problem listed OVER THE YEARS, I cannot be the ONLY person in the world with this problem, nor am I THE FIRST.  Where the hell are all the other past life "experiences" with this same or similar issue stashed?  Not on these forums, because NONE of the threads have a stable resolution. There are words for storing experience which include repository and knowledgebase.  And what is being demonstrated here?  A lack thereof mandates recreating the wheel each and every time.  There are words for that, amongst them - profit sink.


Suggestion: Perhaps Norton engineering might want to bench "stress" test their own product? Set up a PC or virtual machine configured as detailed in the posts above, follow the procedure, run the same tests and figure it out. OR ship me a copy of your troubleshooting diags and toolset, the one which Chat, 1st and 2nd line downloaded, I'll run the procedure and recreate the errors at my leisure and ship you back the logs.


Better yet, why don't you let me enhance your CRM org? Been there done that, and your bottom line would thank me for it. It's a win-win. Just sayin. Again, Mr. Clarkson and Norton are going to get one hell of a bill.
Update #17 04/19/21 received confirmation of a product rollback over the weekend, as predicted above, from Norton Escalation Team Europe, Middle East, Africa and Latin America.


"Thank you for your patience. I have confirmation from Engineering received about the RASClient error 31. This was fixed through a rollback on the weekend. Can you please check on your device and perform a Live Update on your Norton 360? "


Our response:


Thank you for the heads up. The product rollback was downloaded prior to a long weekend of testing.


Please read entries #13 through #17 at the linked forum for an update on the referenced roll back mods.


Test observations of current undocumented features aka BUGS for both Norton 360 VPN AND Standalone Norton VPN products are included in the notes.


We recommend a copy of the notes be forwarded to Engineering, along with the referenced case numbers.


Please be advised:


1. our testing and notes are neither exhaustive nor all inclusive, and only relate to the DNS and VPN connectivity issues in our current service case opened 26 days ago 03/24/21.


2. Mr. Robert Clarkson, customer service management, the Norton customer base, and I await a resolution to these long standing issues.


Please keep me posted.


Regards


https://community.norton.com/en/forums/360-vpn-will-not-connect-norton-log-says-it-did


Until our next installment, and the saga continues.


Update #16 - Experiment in Terror III


We will now install and run Norton VPN standalone 4.1.0.149, all general settings OFF, adblocker ON, forget split tunnel.


A. Auto connect to local region, ip confirm dns no leak, WITHOUT DISCONNECT select LOCAL region from list, BOOM goodnight Irene RASCLIENT shows SOE (sequence of events) with ERROR 31, close program. Check IP address, same VPN address? ip confirm dns no leak, still connected to VPN.


B. Open My Norton - it sees VPN address, attempt to connect 360 VPN, as expected cannot mix apples and oranges: US, auto connect, local region, all ERROR 31. Internet working however... stuck in standalone VPN connection, open program continues looping, says IP address unknown, attempting to connect spinning, close it, reopen, cannot kill process in services, will NOT use Task Manager. Disconnect internet.


C. Rewind loop, step 1-3 in Update 15. All normal, ip dns leaks. standalone VPN connect to US, confirm ip, dnsleak hung waiting for results. Disconnect. No VPN, ip confirm, dnsleak hung, clear dnsleak cookies, still hung. Autoselect region grabs local, ip confirm, dns no leak. DISCONNECT. Check ip, dns leak. Select local region connect, ip confirm, dns no leak. WITHOUT DISCONNECT attempt autoselect, grabbed SAME address, ip confirm, dns no leak. 


D. WITHOUT DISCONNECT attempt US, BOOM failure NORTON error ID 87; rasclient has NO ENTRIES for this SOE except a 631 which means user or program activated exit.


E. Local IP confirm, dns leaks. Autoconnect local, ip confirm, dns no leaks. WITHOUT DISCONNECT US region, BOOM error 87. RASCLIENT has all SOE entries with... drumroll please... SUCCESS and NO ERROR messages. NORTON VPN CONNECTION ERROR 87 still on screen, SAYS OFF, US IP CONFIRMED, NO LEAKS. Dismiss error, close program, reopen in OFF state, IP DOES NOT MATCH, shows LOCAL IP.  


F. Select US region, (in effect WITHOUT DISCONNECT) BOOM we are sucked back into the spinning mobius loop black hole with multiple RASCLIENT ERROR 31's.  Yet, we are connected on VPN with US IP.  This time we DISCONNECT, turn off WIFI, turn on airplane mode, turn off airplane mode, turn on WIFI.  Still on VPN US IP, open standalone VPN, spinning like a top, address unknown.


G. Rewind loop, step 1-3 local IP confirm, dns leaks. Autoconnect local, ip confirm, dns no leaks. DISCONNECT, US region, ip confirm, dns no leaks, DISCONNECT, local region, ip confirm, dns no leaks. Sensing a pattern here...


H. WITHOUT DISCONNECT US region, BOOM error 87, RASCLIENT has NO SOE entries except 631 program exit. A rinse and repeat of E and F above ensues - reproducible scenario. 


F. One change, instead of rewinding the loop, this time we terminate process with Task Manager. Ip stack still committed to US VPN address with no leaks. Open program, IP DOES NOT MATCH, shows local ip, but he's NOT spinning. This time we AUTOCONNECT to local region, ip confirm, dns no leaks as expected. In effect, the process termination created an orderly DISCONNECT or release.  


It appears that when attempting to move between regions, failure to disconnect will result in a failure to connect. The subroutines involved need a fine tooth comb scrubbin.  Much like VPN 360's call to update function, auto jumping regions without a clean disconnect precipitates the condition.


Again, somebodies WATCHDOG is ASLEEP on the job.  Mr. Clarkson and Norton are going to get one hell of a bill.
Update #15


As of 04/17/21 circa 16:00 PST... Experiment In Terror II.


1. Reinstall WAN miniport virtual adapters as detailed above

2. Run following batch file as administrator:

netsh winsock reset

netsh int ip reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

ipconfig /registerdns

3. and a restart


4. Holy Cow Batman!! Successful connection to VPN in: 

current country

auto select region (finds either current country or country of nearest upstream DNS server)

United States

Spain

Romania

UK, etc.


After each connect, turn off VPN, wait a few seconds, select new region. Verified with "what is my IP address" and DNSleak.com


Now let's break it, run Norton update from current country NO VPN or from any country with VPN.

5. sometimes current country and auto select connect

6. 809 error on all other country selections

7. circle back to current country and auto select, 809 errors.

8. No further connections can be obtained, end of rope, rewind loop...


Repeat steps 1-3.


#4 result holds UNTIL... we run Norton update, rinse and repeat as sporadic 809 trouble starts all over again.  This loop was repeated multiple times.


Fyi, flipping DNS to Primary CloudFlare 1.1.1.1 + Secondary Quad 9 9.9.9.9 only made the DNS faster, no impact on above results. 


Bare in mind, many are having the VPN connection error when attempting to connect within their current region (same country US to US).  Many are also having this error when attempting to connect to a region outside (EU-EU; foreign country to US and vice versa).


From 03/24 until 04/17, with constant error 31 we could not buy a VPN connection. Thus, either one or both of these was propagated in the last day: 1. program update. 2. server certificate update.


It appears that connection to Norton update servers precipitates the issue. That subroutine and whatever it crosses paths with need goin over with a fine tooth comb.


40 years of customer service in delivering IT based business solutions includes: at one point my boss would hand me the latest release and say, that's the latest now break it. Nothing was released into the production environment until I had my way with it. The programmers loved it, because it made them better. But they still called me a professional ball breaker.
Update #14

SA - thanks for the comment. Interestingly we are aware of that info, and we can find no CURRENT reference to an error 31 or 031 in RasClient Error Messages. However, further edification of what a RASCLIENT ERROR 31 implies...


The origins of the certificate check resolution...


ERROR 31 IN JAVA: VPN Client : The certificate associated with this Connection Entry no longer exists or failed to open. Please select another certificate. Cause: The certificate doesn't exist or failed to open. Possible resolution: If you have installed a new certificate and removed the old one, you need to enroll the new certificate.


Either delete the previous connection entry and create a new connection entry OR modify the certificate authentication entry for the existing connection entry.


Go to connection entries ->  Right click the respective connection entry -> Click Modify


Within certificate authentication section , select the new installed certificate.


https://www.buggybread.com/2013/03/error-31-certificate-associated-with.html



The origins of the reinstall WAN miniport virtual adapters pointing towards a corrupt RAS connection entry coupled to a bad device driver...


Event ID: 20227Source: RasClient CoID={522ABF49-21DA-484F-8545-A66EB61591F0}: The user **** dialed a connection named XXXXX which has failed. The error code returned on failure is 31. This happens after the connection is established and the "Verifying Username and Password" has been shown. 


CoId={5608FAF9-E5FA-48E5-B556-E726B0892484}: The user "USER" dialed a connection named Standard Modem over Bluetooth link (OTA) which has failed. The error code returned on failure is 31. Log Name: ApplicationSource: RasClientEvent ID: 20227 I found an app calles RArepair.exe, from another error , that seems to remove and add RAS again, and this worked for me!!! 


Code 31 This device is not working properly because Windows cannot load the drivers required for this device. (Code 31) Recommended resolution Update the driver.


http://networksteve.com/windows/topic.php/Dialup_Connections_Suddenly_Stopped_Working/?TopicId=27526&Posts=1



Finally, the registry fix you reference.  The origins of a problem starting with Windows 1903 build 18362.207 where the Remote Access Connection Manager (RASMAN) service may stop. This condition was due to when a VPN profile is configured as an Always On VPN (AOVPN) connection with or without device tunnel, and was caused by disabled Windows 10 telemetry.


At the bottom of this post: http://woshub.com/fix-vpn-not-working-windows-10/



The MS 1903 KB4505903 (OS Build 18362.267) build ISSUE notes June 27, 2019:


https://support.microsoft.com/en-us/topic/june-27-2019-kb4501375-os-build-18362-207-3258dfbe-4da5-02ac-b22f-7c109e2847bc


The MS FIX KB4501375 (OS Build 18362.207) notes July 26, 2019, do note the volume of permissions and VPN RAS related fixes....


https://support.microsoft.com/en-us/topic/july-26-2019-kb4505903-os-build-18362-267-d1a2bbc9-1a0e-1187-8713-102cc9be5c49



Again, NOTHING changed except a NORTON product update which HOSED the VPN. Hypothetical: The Norton work around in July 2019 and for those running 1903 has "artifacts" which are incompatible with the MS fix and various releases since. 

From past life experience (cleanup and turnaround), too many hacks poking into poorly documented spaghetti code called a product, creating (butterfly, domino, cascade effect) new undocumented features (bugs), and one arm knows not what the other does. Strict change mgmt, documentation and version control prevents these kind of push out problems. Just sayin.

When you posted the below text, I had earlier found something which MAY explain at least part of the issue as you wrote it: Intestingly, rasclient error 31 reported from support is perplexing in that, its concerning DIAL UP of all things. ERROR 31: The certificate associated with this Connection Entry no longer exists or failed to open. Please select another certificate. upon trying to connect through VPN. The certificate doesn't exist or failed to open.

Currently, on both PC's when attempting to utilize Norton VPN which employs MS RAS the following RASCLIENT errors are logged in the following order:
CoId={BEDB4F31-85CF-435E-A5B0-88D787C92F3C}: The user SYSTEM dialed a connection named NortonSecureVpn which has failed. The error code returned on failure is 31 which can refer to a problem after login credentials are xchanged, permissions or a bad cert involved. 
 

 

I have been finding a boat load of Norton Error reportings that have the exact same data as it was reported in Norton and found in the history, see below: The error "Cert Analysis" appears in every instance. IMA that these are NOT instances where I was using the VPN. 

norton error reporting cert analysis .pngGive this registry entry a look as well:

Edit the following registry value: SubKey: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection

 Setting: AllowTelemetry

Type: REG_DWORD

Value: 1, 2 or 3

Note: If the Remote Access Connection Manager Service is not running after setting the Group Policy or registry key, you need to manually start the service or restart the device.

SA

Update #13

SA - Thanks for the bump. In other news... through Chrome browser extensions - VPN Free - Betternet Unlimited VPN Proxy 7.0.10 and Hotspot Shield Free VPN Proxy - Unlimited VPN 5.0.4 - I can connect to their proxy VPN, and surf no problems. IP change verified through "what is my ip address" and a boat load of leakage traced at DNSleak.com. No RASCLIENT so, apples to oranges.


Currently, on both PC's when attempting to utilize Norton VPN which employs MS RAS the following RASCLIENT errors are logged in the following order:

CoId={BEDB4F31-85CF-435E-A5B0-88D787C92F3C}: The user SYSTEM dialed a connection named NortonSecureVpn which has failed. The error code returned on failure is 31 which can refer to a problem after login credentials are xchanged, permissions or a bad cert involved.

CoId={BEDB4F31-85CF-435E-A5B0-88D787C92F3C}: The user SYSTEM dialed a connection named NortonSecureVpn which has terminated. The reason code returned on termination is 828 (ERROR_IDLE_TIMEOUT), caused by the prior condition or error.


IMHO:  1. The fault condition is related to a RAS connection entry which keeps getting stepped on or corrupted. The RASCLIENT log shows hand-shaking was successful, it's whatever happens just after the userid/password is authenticated and control passes to the next step.


2. The RAS entry references a corrupt certificate which is not permitted.


So we decided to conduct a small "Experiment In Terror" (1962).
Using MMC certlm we checked the SURFEASY certs: personal was dated 04/09, whereas trusted and intermediate 02/23. So I deleted the older date certs, then copied and pasted the more recent dated cert from personal.


Tried VPN and AUTO SELECTED REGION, For the FIRST TIME I got a NORTON error popup for error 809 which indicates that UDP on ports 4500 and 500 are blocked by the firewall or local authorities. We know better and listen Silly Rabbit, that trick never works. But this gets even better...


Upon further review and as suspected the corresponding time stamped RASCLIENT log entry has NO entry for 809, so the mustard is off the hotdog. However, it DOES indicate a successful connection followed by a 13806 error...


"Contact your network security administrator about installing a valid certificate in the appropriate certificate store. Possible cause. This error typically occurs when no machine certificate or root machine certificate is present on the VPN server."

 

Considering we just touched the certs, that seems reasonable. Upon further review, the personal cert changed dates to 04/15, the other two are still dated 04/09. So personal got accessed, the other two not so much.


However, checking the Norton history logs, there are NO entries with corresponding TIME STAMPS for that SOE, only UDP firewall entries??


So once again, somebody's WATCHDOG is sleeping on the job.


We were able to recreate the SOE an hour later, however this time, no 809 pop up, but a RASCLIENT 809? Two separate program event writers swapped registers? Shared API memory space corruption? Checking the RASCLIENT logs, there are no other 809 errors going back for months. Further, subsequent attempts are back to the usual error 31 and have failed to recreate those SOE errors.

Issues:


1. The 809 error message popup

2. The RAS client connection entry reset

3. Certificate handling

4. The Norton process "watchdog" that monitors CHANGE OF STATE and its leashed log writer are asleep at the wheel. SOE cannot be ascertained because EVENTS are not being properly monitored and written to log.


If you can't monitor COS, you don't know what state your in (other than confusion), and how in the hell can you CONTROL ANYTHING? For example a real time virus.


40 years of customer service in delivering IT based business solutions includes: engineering of real time supervisory control and data acquisition systems and real time transaction processing.  We've put ms response times at arbitrager's fingertips, securely processed international bank customer xactions, and put numerous women and men into orbit, spacedock and return, safely. It's not rocket science, really.


A string of two word bits (LOL) follows: change control, software mgmt, quality control. 

@Sunil_GA Can you please pass this thread along to the engineering team? 

SA

Update #12


Received this 04/14/21 from Norton Escalation Team

Europe, Middle East, Africa and Latin America


"My apologies again for asking about your bank account information.


This was an error from my side.


Please provide your current phone number using the Voltage email. I would like to thank you for the explanation and confirming your part of troubleshooting. Logs had been collected and passed on to Engineering.


However, I would like to stress the current issue you are facing with your VPN is with Engineering.


We are working on a fix at the moment and would like to ask for your patient.


Once I have confirmation from engineering I will reach out to you as soon as I have this information.


I do not have a phone number you can call back as we are still under COVID 19 restrictions in XXXX and home office based." 


1. Alrighty then, asking for BANK DETAILS is an ERROR? If I was on billable services, Norton would have already collected my CC info which have NOTHING to do with BANK DETAILS.  To put this in perspective...


Would any customer ask Norton SUPPORT for a ham sandwich? No. Why? They don't sell sandwich's because sandwich's have nothing to do with delivery of SUPPORT services.


Shoe on other foot... would any SUPPORT org ask a client for their social security #, birth date and mother's maiden name? No. Why? Outside of BANKING, that sensitive information has NOTHING to do with delivery of customer support services. 


So WHY under ANY circumstance would Norton ask me for my BANK DETAILS? Just add this to an ever growing list of bizarre behavior.


2. "I would like to stress the current issue you are facing with your VPN is with Engineering. We are working on a fix at the moment and would like to ask for your patient."


Finally, someone who is direct and doesn't want to waste time on a KNOWN and PERSISTENT bug hunt for engineering which apparently are not fit for purpose.  How do we know this?


This problem has been well documented on many forum threads for quite some time (several years), during which Norton have to be kind: hung their user community out to dry on numerous occasion. Over multiple years and countless clients, Norton keep insisting on repeating the same mistakes, over and over, while expecting different results.  Again, the definition of insanity applies.


This is not a one off, coincidence, pattern or trend, it's habitual as in addictive neurosis. A cat attempting to cover up and bury its dukey on a marble floor comes to mind. Obfuscation and misdirection will not suffice and only begets wasted cycles, customer alienation and associated costs.


The resulting dysfunction has permeated their organization like a virus, which explains the bizarre behaviors and violation of the most basic tenants of CRM we are witnessing.


At the end of the day, Norton performed data collection of numerous client logs including mine, they have forensics, my contact info and they must have someone or a group who is capable of a problem resolution. You can't hide the problem, it's costing you money, so fix it for once and all.


Until our next installment of Norton Hears Ahhh... Few.
Update #11: We have received a lucid and detailed email from a gent at

Norton Escalation Team

Europe, Middle East, Africa and Latin America


Pertinent: "From what I can see in the Logs we have a RASClient error 31. For this error an engineering ticket was open and we are currently working on a fix.  This error however can be caused by many factors as it is a Windows error."


The 1st person to mention this, which can be gleaned from the MS Event Viewer application logs. Progress finally? Norton coders pushed out an undocumented feature - aka bug, half of which (DNS set adrift) has been resolved with the push out of 22.21.2.50.  Currently working on a fix sounds good. Many valid questions followed re: troubleshooting already performed and documented here on this forum, as well as the trouble ticket case number file. Hopefully? Somebody did not read this forum and/or the documentation in the CRM system is lacking. Par for the course, but it gets better...


"In order for us to call back, please reply to a separate email received by Voltage, confirming country + phone number. For this purpose, I will be sent you a separate encrypted email. Please check your inbox and or the E-Mail Spam Folder.

 
The E-Mail contains a hyperlink, such as message_zdm_html. When clicking on the attachment, you then will be prompted to create an account for Voltage secure mail. Once you have logged on, you then can see the email and when you respond with your bank details, the email sent is encrypted and therefore secure."


For a customer service CALL BACK, has anyone reading this ever been asked to sign up for encrypted email service and supply their BANK DETAILS?


My response was... "please do read the forum entries in their entirety for all the details. As for creating accounts for encrypted email and providing BANK DETAILS, that's not going to happen. If you want to provide your phone number and window of opportunity, I will be more than glad to call you in lovely XXXXXX, and we can proceed from there."


Enough is enough. Rather than resolve the issue by providing a solution, Norton have turned an opportunity to win business into something inconvenient, perplexing, frustrating and just plain ridiculous steaming in circles like an animal chasing its own tail.


We stand by our professional five point assessment provided above in update #7. Add a glaring hand off gap, and a lack of communication in Norton's CRM system or organization. All of this leads to a disconnect of continuity and unacceptable service levels, while putting an inability to communicate in the language we have all agreed to communicate in, and complete lack of common sense on display.


In our 40 years of customer service in providing business and IT solutions, we have experienced country club E-suite idiocy at its finest, and where the rubber meets the road technical incompetence at its worst.


However, we have never encountered anything remotely similar to this bizarre sequence of events. The postal service would be a step up. An organization who cannot get out of its own way should be avoided at all costs if possible.


Three words to the wise, and the latter two we rarely say but are fully warranted in this case: Norton, never again.
Update #10 - it just keeps getting better all the time. Below highlights from a series of emails which Robert Clarkson and customer service management should be even MORE interested in.


"My name is X and I am part of the NortonLifelock Global Escalations Team. I am writing to you as your case “666” has been escalated to my attention. We’re contacting you to schedule a call to help resolve the issue that you are having."

Norton Escalation Team 

North America, Asia Pacific & Japan

Norton stepped up, which seemed to be a turnaround.


"Due to recent events, we are not sure where you are currently located and did not want to cause any further issues by calling you immediately."


The Norton team were advised of my location and available time slot multiple times, all to no avail. 


"Please know that we have tried to call the number that you provided to our Norton Support, but we’re unable to reach you at the number."


Apparently backend escalation have attempted to call me with no success. The SOE (sequence of events) and Norton's ability to contact me was reiterated...


"your tech called me on Friday 04/09 at 8:30PM and previously robo dialed me three consecutive nights at 1AM" (over Easter weekend)."


Backend escalations inability to contact me was questioned...


"You were unable to reach me at the number you have. Yet, my phone did not ring, and there are no messages. What number are you calling?"


Rather than get to the point and answer the question, the response...


"We do have a phone number, however was not able to reach you on it. We just wanted to confirm that the number was correct."


WTF? If you want to know whether the number your dialing is correct, please let me know what number you are calling. If that number does not correspond, then I can give you a correct number to reach me at. Common sense much?


"Please know that our available time are as follows; between 12:00 PM to 6:00 PM Eastern Daylight Time."


Those hours Mon-Fri work fine for our purposes. After SEVEN EMAILS back and forth, TWO phone appointments gone astray and now this...


"Please know that while you are in the country of XXXXXX, you will be provided further assistance by another team who can contact you during those times."


Again, Norton have been informed as to my location and time zone numerous times, But, rather than step up Norton escalation are now tossing the client aside to another support group. More wasted time which cannot be recovered.


"Again, we’re sorry for the inconvenience and will be providing you with a 30 day extension as a gesture of goodwill. Our Team will contact you soon in regards to your issue."


However will the other team contact me if escalation could not? Will anything be different or change? No, and once again with Norton, the definition of insanity applies.


In summation, front line chat did their job, 1st level phone support lack of attention to detail terrorized the client,  the matter was escalated to back end who seemingly stepped up to take ownership.


We have workable hours and established email contact. However, the communication problem on Norton's end now has escalation making excuses to toss the customer like a hot potato to another group.


And if you think that's the end of the story, NO, it gets even better if you can imagine in Update #11. I kid you not.

Update #9 On 04/09 I called at 12:00 EST and the named escalation agent was unavailable. Received a return call from a 2nd level agent at 20:30 my time, an improvement on 01:00. The agent installed an update to version 22.21.2.50 and refreshed my licenses, which seems to have repaired the loss of DNS after attempting to connect to VPN. Unfortunately, the VPN connection failure persists. The agent collected data logs and said he would refer to escalation. Escalation emailed me an apology for the earlier unavailability and we will resume probably Monday.

SA - Thanks for the response and initiative. Initially PC1 would VPN connect while PC2 would not, however the logs indicated that PC2 thought it had connected. Both shared the no internet access or DNS blackout (DNS stepped on, could not find the gateway). Had both machines concomitantly exhibited identical symptoms, then the occurrence of an internal or upstream change could be suspect. Since nothing else inside the gateway or internal network changed AND after running the NORTON diagnostic tool on PC1, it assimilated the same symptoms as PC2 (see 2nd entry above for more details), the initial bifurcation exonerates the external ISP, and any software, settings or equipment involved. Currently hooking either machine up via ethernet to the ISP modem, yields the same results which excludes any internal origin. There can be only one… suspect that is: NORTON. Thanks for the offer, will defer at the moment to Norton Escalation, see update #8.

Update #8 I have updated both boxes to Windows 10 Home 1909 18363.1443 - no change. I have also received an email 04/08 from Norton Escalation. After three days Norton Support have reached out and acknowledge the previous phone disturbances on their part. “Due to recent events, we are not sure where you are currently located and did not want to cause any further issues by calling you immediately.” It appears they have changed the case number, a named individual has finally taken ownership and given a daily window of opportunity to call, which we shall pursue.

I'm looking in another direction with this yet again. WHO is your services provider, and what device(s) are present to bring those services into your home? IE: Provider modem/combo device. Personal router, etc.

SA

SA - Thank you for the response and suggestions. Inverted order 1. Staying on stable 1909: the issue did not start until circa March 23rd Norton product update. 2. Switched DNS to Primary Quad9 9.9.9.9 and Secondary CloudFlare 1.1.1.1 on both PC’s and Router. Norton support switched to Cloudflare and Google as you suggest, same result. 3. I uninstalled two ways: A. from Programs B. utilized the tool remove only, reboot, reinstall. Both Norton chat frontline and 2nd line data collection utilized the latter method. All to no avail.

peterweb - thanks for being a first responder and the suggestion. The very first thing I did was change DNS, did not help. Please refer to the original post for my DNS settings and other attempted remedies.