I love the SMA 1000 series.... but... lingering issues with Connect Tunnel Client
Doug_Daniel
Newbie ✭
I love the SMA 1000 series functionality but I have some lingering issues with the connect tunnel client (Connect Tunnel 12.4.2.664) and would really like to hear from the community about your experiences. I am using the connect tunnel client in a Device VPN / User VPN mode.
My biggest issue is that sometimes the Connect Tunnel client is not good at recovering or keeping a connection active. There are various cases where CT loses it connection (laptop sleep/resume, user moves and switches networks) and in many of these cases CT does not fully resume. Although the user is logged in CT is in Device VPN user and you must actively click "Connect" for the User VPN to connect.
Please don't tell me to contact support who wants logs and specific instances. I would like the client updated so that it keeps a heartbeat and if it sees Device VPN mode, it automatically attempts to reconnect the User VPN mode. It mostly does this but with even our small user base of about 150 users, we get near daily calls that just require the user to hit connect. We even created a little "Refresh VPN" utility, which kills the SNWLconnect process in the user context. This causes the process to get respawned by the Service and it automatically connects. I just want the CT client to attempt this reconnect automatically. Support has helped in many cases before, but I cannot get them to understand that I just want a more aggressive re-connect algorithm. They have actually made several client changes in response to some of our previous tickets, but have not been responsive to this.
Are our laptop users doing something unique or are others facing this?
I have even looked at using the Connect Tunnel (Named Pipes) API to monitor the status and force a reconnect if we see that it has fallen back to Device VPN mode. I am currently struggling with making the call and getting the status back. Let me know if anyone has had any luck with the connect tunnel API.
I may need to note that we use Device VPN mode for minimal access to domain controllers and other base services. We require the User to log in and establish the User VPN for access to other systems with specific security requirements.
It is getting to the point that we are looking at other options. Remote Access is a critical function. The SMA 1000 series is based on the Aventail technology and is far more powerful than the SMA 100 series which is what makes this frustrating.
Answers
First - Thank you to IAMBROKENMAN for his offer. However, I don't think I want to look at my policy/configuration yet.
So Question to the community: Do you have issues with Connect Tunnel not automatically resuming a full connection (user) after a network disruption or the machine recovering from sleep?
In our case we can find ourselves looking at a Connect Tunnel dialog showing Status: Device VPN and a working button saying "Connect" - if the user presses that button, the connection switches to a User VPN and connectivity is restored. But if they don't it can sit broken for hours. My REAL request is that Sonicwall add logic that if it sees the status change to Device VPN, it kicks in a process that at least ATTEMPTS to reconnect. It seems easy enough. Why does Sonicwall always want to look at my configuration?
I have already gotten two of my previous suggestions turned into product changes, and I know that development have worked on improving the features that resume a connection. My requests in the past have been reasonable - It is just REALLY hard to get something to development to look at. And the automatic resume features need work! This issue is not in my configuration. If the user can hit "connect", so can the client software.
here is where I had to point out that if a password was expring in 14 days that was no reason NOT to make the connection at all - they finally listened and modified the code - Bug / design change request - Modern Connect Tunnel Client and expiring password — SonicWall Community
and here is where I requested that an additional color be added to the client so you could tell the difference between a Device VPN connection and a User VPN connection, because if implemented properly they are VERY different - they finally listened and modified the code Feature Request(?) Connect Tunnel status colors — SonicWall Community
WHY IS IT SO HARD TO GET THE ATTENTION OF SOMEONE - the code that handles resuming of connections still needs work. This would help all SMA 1000 users.
I guess another question would be:
How many SMA 1000 series users are using the Device VPN / UserVPN model?
we use it for our "Always On" VPN
When the machine boots and gets network the Connect Tunnel client connects in Device VPN mode using the laptop's machine account credentials and establishes a "Device VPN" connection. Since we only have machine credentials, you get a very limited view of the network - critical domain services, DNS, machine management (patching, AV updates, etc)
Then you get to the login prompt with a basic network connection (device vpn mode). When you enter your user credentials, the Connect Tunnel client establishes the "User VPN", login scripts run, and the User has far more access than the Device did. The user can now access file shares, applications, services, etc that require user authentication.
You can watch the process in console and see the session go from [Laptop Name] to [User Name]
I noticed that in a recent client upgrade 12.4.2 there is now the option to use either our current "Device VPN" model or switch to the "Network Login" model. Should I be moving in this direction?
Thanks, @Doug_Daniel , for bringing up the issue. The original intent for not doing aggressive re-connect of User VPN is due to complexity and the side-affects. We allowed only Device VPN to continuously retry for reconnection since it's non-interactive and can reconnect automatically by creating a new session with Device Cert. User VPN will retry reconnect based on few conditions (like valid session id) and unlike Device VPN may require user credentials to establish a new session. So that's where it was designed so that user can initiate new User VPN by clicking connect button.
I understand that this behavior has not been ideal for your users. We can reevaluate and see if any improvements can be made here. But can you please confirm if the failure to reconnect User VPN is due to expired session ID? Or have you come across scenarios where client failed to reconnect even when user session ID is valid?
And since you were trying to have a utility to monitor the status and to force reconnect, I would say it can resolve your immediate need. Let us know if you had got access to the API guide and what didn't work so that we can help you in both regards.
Thank you for the reply!
re: can you please confirm if the failure to reconnect User VPN is due to expired session ID? Or have you come across scenarios where client failed to reconnect even when user session ID is valid?
I am struggling to understand the question. I don't believe that have never seen "a failure to reconnect the User VPN." In effectively all cases, if the user hit's the connect button it works. My silly app was because it was easier for some of them to find a "refresh vpn" icon in their utilities menu than to look at the system tray, bring up the CT dialog and hit connect. If the user knows how to verify their connect tunnel status, it always seems to work if they hit connect. they get in a disconnected state due to sleeping their laptops, and/or some combination of moving from one wifi network to another.
Your point about resuming the User VPN makes sense. Knowing that it was a design consideration rather than a software bug is extremely helpful. I would LOVE for you to reconsider and at least offer the option. We have over a 90% success rate with "Connect" resuming the connection. In a WFH environment someone might decide to move from a home office, to the patio. This is one frequent case where an auto-reconnect once they get their network connection would be great. Another is closing the laptop in the office, then driving home and opening it up after a "sleep" and on another network. I would love to discuss how this would be useful, and maybe it could be optional based on configuration. Maybe you could set some logic that triggers on the underlying network resuming, and then try x number of times with a x second delay betweens attempts, followed by failback to manual resume. the opportunity to talk about some of the things that would make the process better for users would be appreciated. Feel free to message me.
I have not succeeded in writing a utility using the connect tunnel API. This is a lack on my part. Named pipes should be one of the easiest APIs to use, but I am struggling on the callback. I have not spent much time on it. I would love to see a simple Powershell script showing how to call the "status" function and retrieve the results.
VKRTandra - I just saw your comment in the other thread with a sample PS script on the API. Thank you! i will play with this tomorrow.
This answer feels like I cannot really achieve an "Always On" VPN using the Connect Tunnel Device/User mode. Years back we used an SMA 100 series with NetExtender and had a great always on configuration (I think it was based on the old RAS APIs). The SMA 1000 series with Connect Tunnel is so much better in many ways, but we have suffered through many issues of the session dropping and not being agressive in reconnecting. Now I hear that this is by design. I would love to have a phone conversation or more responses. There are a number of minor ways that the connect tunnel client could be improved.
I got an inquiry today from our CIO as to whether we should send out a tip educating users with poor experience to use our "Refrresh VPN" utility. There is a quiet mandate to move away from this product. It has been 3 or 4 years now and stable connections without so much user interaction is one of the top issues. It is frustrating to learn that this is by design.
this (see image below) also happens which was why we originally created the "Refresh VPN" utility. Support just wants logs. I want a programmer to look at the dialog and fix the issue. If the connection type has fallen back to Device VPN, then the connect button should never be greyed out. The re-connect automation of the Device/User VPN modes needs attention. Add a monitor on the connection and if you see it drop to Device VPN make sure the Connect button is in the correct state.
Apologies if the frustration is coming through in my comments but your reply has been one of the best yet and if I can just get the points through this is all easily corrected. Please reach out and I can get you contact info. I would love to talk about how we use the product. Oh this dialog came through the help-desk this morning. I haven't seen one of these in a long time, but it may be because we gave the users a work around with our Refresh VPN utility. I have opened tickets on this before but have pretty much given up on support. They are doing their job, but want to study logs. There is no way this should be able to happen. It seems like 30 minutes with a whiteboard and this logic could be improved.
@Doug_Daniel , this definitely is a bug. If the button got disabled, then I would presume that AlwaysOn VPN checkbox is also enabled in the same user VPN community. Until 12.4.2, enabling AlwaysOn VPN checkbox in the user VPN community triggers a special mode that basically doesn't allow user to disconnect from user VPN (however they can connect if the VPN got dropped which isn't happening as per the screenshot).
Would it be feasible to capture debug client logs from as many use-cases/issues as possible to study and improve/fix these issues? The little flaws are sometimes hard to chase unless we can study the logs.
@vkrtandra
Yes - let me know the best way forward. What level of logs do I need? is debug, and then export logs from the connect tunnel dialog sufficient? It will be difficult as many of our users are used to just using our "refresh vpn" script when this sort of thing happens and I don't have an easy way to enable debug logging on all vpn users.. plus I worry about the performance impact.. Please feel free to message me directly for contact info.
Can anyone provide details on this 12.4.2 client update - it may be related to my users' issues.
FYI - for anyone who had this issue.. the 12.4.3.266 connect tunnel client seems to have much better auto-reconnect logic as stated in the release notes. It has done well in our testing and we will roll out to all end users this Saturday 4/20/24 and update with our experience. Here is the update mentioned in the release notes:
SMA1000-7134 Trigger User VPN to auto reconnect when it got disconnected other than user disconnect