We're using RV340W routers with a Telework VPN connection going back to the main campus, for use with some remote teleworkers. They use the same Client-to-Site profile that's defined on the main office router, and for the user auth, each one authenticates against a "user" setup in Windows active directory for that specific router. (Makes it easy to disable a specific router's VPN should that be needed, by disabling the router's user account.)
In our environment, the RADIUS server (a Windows Network Policy Server) is joined to a different domain than the router's user is in. So, we have to use "domain\username" when setting up the Telework VPN. The interface doesn't seem to like special characters and won't allow the backslash. Prior to firmware 1.0.03.22, I was able to work around that limitation by exporting the config, manually adding the backslash and re-importing the config. However, as of 1.0.03.22, it seems to enforce its averseness to these characters at run-time. I confirmed that by checking the NPS server logs and see that the auth failure is being logged as an attempt at "DomainUsername" instead of "Domain\Username".
For some environments that use Active Directory authentication, they may need to give a domain and username in the username field, so the backslash is a must for those environments. I also found that for passwords and preshared key fields, there seem to be symbol characters it likes and some it doesn't like. Not only is it frustrating to set a random-generated password only to have to redo it a few more times because there was a character the router setup didn't like, but nowadays secure passwords are expected to pretty much be able to use any character on the keyboard. It shouldn't be considered taboo to use symbol characters in password fields.
I wanted to give this feedback so that perhaps in a future update these routers can be more accepting of symbol characters in usernames and password fields.
