8.5.2 build 5739 lost VPN settings after unrelated edit

I’ve been running 8.5.2 beta builds w/o problem.

Just today I was doing two things:

  1. turned on Advanced / UDP relay, added a relay, then turned it off and disabled it.
  2. disabled a firewall rule to test, then re-enabled it

Shortly after, a user said their VPN connection was failing. I went to look, and in fact the VPN was disabled:

IMG_2201

And when I re-enabled the checkbox, all of the settings (Preshaed Key, Listen ON, User Accounts) were gone as well.

Fortunately I have backups of this info, but I’ve never seen a bug like this before.

Hardware: Balance One

Thinking back over what I did, I think I may have done this:

  • Make some edit changes, clicked the Apply Changes button.
  • It seemed to be taking a long time (10+ seconds), so rather than waiting for confirmation, I clicked to another UI section
  • made some other settings changes.
  • I wanted to click the Apply Changes button but it was dimmed out
  • in a few seconds, the “changes made” confirmation showed up, and Apply Changes re-enabled, and I clicked it.

I wonder if there’s a race condition here, such that if you make further settings changes, while a pending “apply changes” is being processed, you can end up losing some other (unrelated) changes?

Not a great bug, if true?

We are unable to reproduce the issue in our lab. Would you mind open up a ticket here and let us investigate this further?

1 Like

@Oh_Yaw_Theng if you enable remote access , add user accounts, save and apply, then disable remote access , save and apply, then re enable remote access I believe it wipes all user accounts.
This has been this way for some time, are you telling me this should be the case?

3 Likes

This seems like perhaps 2 bugs?

  1. @Jonathan_Pitts : disabling remote access, then re-enabling, deletes all user accounts.
  2. @soylentgreen : some combination of updating settings (not related to Remote Access) disabled Remote Access, leading to bug 1
2 Likes

sounds like it’s two ways to trigger the same bug?

1 Like

@soylentgreen is bug #2 repeatable?
@ChristopherSpitler , While #1 to me seems like it’s a bug , I’d like someone from peplink @sitloongs , @Giedrius to comment if clearing the remote users when disabling the remote access is by design?

1 Like

@Jonathan_Pitts @soylentgreen ,

Based on the description given, don’t think this is related to 8.5.2 issue.

It’s seem that a combination features enabling and disabling “clicking” may triggered the issue.

  1. @Jonathan_Pitts : disabling remote access, then re-enabling, deletes all user accounts.

Quick test result:
After untick RUA (Save) before you apply the changes, do a page refresh, the will cleared the user account info.

I will discuss with the teams and update again.

  1. @soylentgreen : some combination of updating settings (not related to Remote Access) disabled Remote Access, leading to bug 1

Still looking at the possible step to reproduce this, @soylentgreen , if you able to reproduce the issue, please share the steps and I will check on it.

Thank you

1 Like

Update :

  • Discussed with the teams. It’s expected the user account info will be cleared after disabled the RUA.
  • The Browser will able to cache the info but if you refresh the page, the info will be cleared after disabled the RUA feature.

CSV format is supported in case you need to add back the user info :

1 Like

That’s somewhat inconsistent UX - for many other areas of the Peplink UI, Disabling a feature does not clear the feature’s settings.

It would be nice if there was a general rule Disabling a feature does not alter any other settings

Please consider this a feature request, thanks!

3 Likes

@sitloongs I agree if it clears the values, then an alert should state as such.

3 Likes