New SonicWall NetExtender 10.3.0 changed .exe (addon broken)

Hello,

Thank you for your feedback.

Have you tried updating the Path properties of the SonicWall NetExtender in File - Settings - Application - Paths?


Best regards,

Hi,

please note that I specified that the exe file name is changed, not the folder path...

Hello,

Thank you for your feedback.

Have you tried renaming the .exe file to see if that helps?

Best regards,

Hi Nicola,

We will add support for this new executable name. As a workaround in the meantime you can make a copy of nxcli.exe named necli.exe, I just tested it it works with the current version of RDM.

Ok, thanks.

My main attempt was to notify to you the new version change.

Cheers.

WARNING: certificate acceptance message is changed as well, so I think a code change in RDM is needed.

I can confirm that copying the file works - though in our case we also had to update the name of the name of the network adapter is looks for an IP on (previously it was "SonicWall NetExtender" and it's now "SonicWall_NetExtender_SSL":

I can confirm that copying the file works - though in our case we also had to update the name of the name of the network adapter is looks for an IP on (previously it was "SonicWall NetExtender" and it's now "SonicWall_NetExtender_SSL":

I confirm the same too.

Thank you for reporting it, we added the information to our ticket to handle those changes correctly.

Hello,

We've fixed the executable issue as well as the confirmation for the certificate.

For the certificate confirmation fix to work (sending "T" instead of "Y"), make sure that the executable is named "nxcli.exe" if you've renamed it to "necli.exe" as a temporary fix. We use the executable name to ensure that the correct confirmation is sent to the correct version of SonicWall.

You can expect these fixes to be in the upcoming 2024.3 version.

Regards,

Thanks!

RDM 2024.3.22 is now available with the support for the new version of NetExtender.

Hi there,

back on topics. I'm using NetExtender 10.3.4 and there is something wrong. I have "Automatically accept the certificate" option enabled and sometimes I see:


Other times, if I wait, a "T" char is outputted:


Also, "Automatically delete profile on close" doesn't work, it remains saved within the client.

Any help?

Thanks

Sometimes "Connection already existed"...

I see exactly the same issue as Nicola. @Jafran Majeau / @Sebastien Duquette perhaps something changed in their command line parameters?

It's unusable for me at the moment. I don't see any follow-up, so I'm trying to open a specific new thread.

Hello,

Thank you for your feedback.

We are sorry that the SonicWall entry no longer works on your end. We will investigate this internally and get back to you.

Thank you for being so patient.

Best regards,

Erica,

I suppose you need to investigate the new CLI commands and test his responsiveness. It seems quite different from the old one and not manageable from RDM at the moment.

Moreover, having NetExtender not deleting/saving the connection it's a mess (and security concern).

Thanks,

Hello,

You’re absolutely right in your observations here. Based on what you’ve described, it does look like something has changed again in the NetExtender CLI behavior.

I’ve checked internally, and our development team has opened a new case specifically to investigate this exact issue (including the inconsistent certificate acceptance behavior and profile handling).

We’ll keep you updated as soon as we have more information or a fix.

Thanks again for the detailed feedback it really helps us track these changes.

Best regards,

Using 2026.1.15.0 64-bit (PreJIT), I now get slightly improved behavior; it now pauses to ask me to key a password into the popup terminal box.
Keying this in allows it to continue, but also kind of defeats the point.

Let me know if there's anything else I can try in the setup for the VPN?

Cheers,
Geoff

2026.1.18.0 seems fixed the connection/disconnection behavior.

WARNING: profile is not deleted on connection close though and, moreover, password remain saved within the NetExtender!

Having RDM creating a connection profile named as the selected entry, it's a mess. Even if I prefer to delete it, may I suggest adding a field to adjust this value when saving profile is needed? Could be useful to better identify the active connection also.

About password saving, I suppose that there's something broken within the NetExtender itself because I always had "Not allow password saving" in the firewall/VPN server policy and this is clearly not applied. The password is saved only if inserted by RDM though.

Hello,

We'll investigate this issue and come back to you as soon as we can.

Regards,

Hello,

We haven't been able to replicate the issue you're experiencing. The profile is correctly deleted for us (by extension, no password is saved as well).
If we proceed with the assumption that your SonicWall is fully up to date, we might need more information as to your paritcular setup. It's possible that some other setting is conflicting with the recent changes SonicWall introduced and its preventing your profile from clearing properly when closing.

Any additional information you can provide would be useful. Without mentioning Hosts, usernames or any such information, any setting or additonal command set in the entry would be useful in attempting to replicate your problem.

Regards,

Hi Jafran,

I tested it again now, and I think the "issue" is that NetExtender GUI clears itself on application restart. I'll test it a bit more now (I moved to manually profile creation before for the original issue).

Furthermore, I want to add another point of attention. I think that there's something broken with the "Always accept certificate" in conjunction of SonicWall OTP option:


I managed it by manually accepting the certificate at the first request and clearing the "Automatically accept certificate" flag, but it's not ideal. Can be possible that RDM is not considering the SonicWall OTP feature?

Let me know and thanks,

Well,

another situation that I want to alert all (I'm quite sure that is not a Devolution issue in this case).

1. Connecting to the VPN by RDM > OK
2. The "temporary" NetExtender profile is added with the RDM entry name > OK (as my previous post, it's not ideal for me using the entry name with no customized property)
3. NETWORK DROP > VPN DOWN (so, no closing command issued by RDM)
4. The "temporary" NetExtender profile remains saved with password also! (this is a violation of the SonicWall UTM/Appliance policy)

Hope to be helpful.

Same issue if the OTP input is wrong: the profile remains saved (as I suppose RDM not issues the deletion command).

Hello,

We will look into the OTP issue. I agree that this looks like something that RDM is sending incorrectly. I will provide you an update when I can.

Regards,

Anyway, I suggest testing the profile deletion because it seems inconsistent (sometime RDM doesn't launch the command > in fact, I don't see it in the terminal prompt or, maybe, for less than a second I see a command before prompt is closed).

Can be something related to a "wait" needed between commands?

I don't see any update about this topic.

In the while, I wanna warn that profiles are saved within the NetExtender and, when RDM try to establish a new VPN connection again, it requires the password input (even if saved inside RDM).
If I manually delete the saved profile within NetExtender, RDM successfully launch the connection again.

Hello,

The investigation is still ongoing here, I've increased it's priority. Hopefully we should be able to provide you with an update shortly.

Regards,

Hi,

I've just seen the new release note with "various SonicWall Netextender fix". Any further details? I think that can be useful adding them to this post.

Thanks,

Hello,

Thank you for your feedback.

The following fixes have been released in RDM 2026.2.19.0

• Password prompt shouldn’t be an issue anymore
• For automatic OTP input, the user needs to link the same credentials in the OTP section of the session and ensure the usage field is set to Specific to session.

Let us know if that helps.

Best regards,

Hi,

it seems that we have now a better experience but take care that:

• delete connection on exit option DOESN'T WORK;
• credentials are SAVED within NetExtender in any case (!!!!).

This behaviour is a great security flaw! (I suppose that there's something broken from NetExtender side, as I always set the SonicWall firewall VPN policy to do not let save them within the client).

Another idea
Can be possible to have an option to avoid the "1" input in case of OTP request? I don't the point to spend time on digit an obvious "1" (NetExtender weird behaviour):


Thanks,

Hello,

The investigation is still ongoing, but we haven't been able to replicate your first 2 issues (connection not deleting and credentials saving), which makes me think that either we have a version difference, or we're misunderstanding each other.

When you're saying "delete connection on exit option doesn't work", what form exactly does that take? On my side I can see that the connection has disappeared from the "quick selection" in NetExtender (and since it's gone, obviously so are any credentials).

Regards,

Exactly: on my side, with the NetExtender the profiles are completly saved once disconnected from RDM.

(this time, dunno why, password was not saved at least)

In addition: I don't see any prompt window with deletion command (as I remember from the past).

Hi Nicola,

Thank you for the additional details.

I have not yet been able to consistently reproduce either the profile-deletion issue or the OTP behavior in every setup. However, I was able to reproduce a specific profile-deletion scenario:

• A VPN is configured on a session entry.
• The VPN is started using the Open VPN Dashboard action.
• The VPN is then stopped using the separate Close VPN Dashboard action.

In this workflow, the NetExtender profile was not deleted. In my tests, opening the session normally and then closing the session worked correctly. We identified why the separate Dashboard VPN-action workflow can lose the generated NetExtender profile name that is required for deletion, and we are working on a correction.

Could you please confirm whether this matches your workflow? In particular, are you using the Dashboard Open VPN action followed by the Dashboard Close VPN action, rather than opening and closing the session itself?


It is also expected that you no longer see the NetExtender terminal window when RDM deletes a profile. The deletion now runs in the background; RDM displays a small loading indicator with “Deleting connection” instead.

Regarding OTP, I have not been able to reproduce the automatic OTP issue in my environment so far, so I would like to better understand your configuration. For NetExtender, automatic OTP injection requires the OTP credential to be configured for the session with its Usage set to Specific to session.

Could you please share how the OTP credential is configured and linked to the affected session?


Best regards,


Léon Le Brun

Hi Leon,

it's correct. I've the VPN set up whitin the client (folder) and inherited within every entry. I always use the dashboard/entry toolbar to open and close.

The OTP is requested by our SonicWall SSL accounts and we don't store/generate them within RDM, we simply need to digit when asked: for some reason, the NetExtender CLI ask "1" to let you digit the OTP and it's tedious as "obvious" (why I should cancel with "2"?). Maybe, there's a misundersting about which OTP I'm talking about (you can simply reproduce it enabling TOTP option within your SonicWall SSL VPN server/Firewall).