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?