Custom VPN (Powershell) - entry does not show it's connected

Backlog

Custom VPN (Powershell) - entry does not show it's connected

avatar

In RDM 2025.1.37.0, we created a custom VPN in powershell script which connects to a Sonicwall netextender VPN. This works fine, but after the powershell script is run, the VPN Entry does not change to indicate it is connected. Is there something we need to set in the script to get this to display. We had to do this route because the build-in NetExtender VPN was creating entries in NetExtender called "SonicWallTemp_xxxxxx" that never got deleted when disconnected and eventually caused netextender to throw connection limit errors. (If there is a way around this, would go back to the build-in one).

The script:

# Define the connection parameters
$VPNName="VPN"
$VPNServer = "$VPN_HOST$"
$Username = "$VPN_USERNAME$"
$Password = "$VPN_PASSWORD$"
$Domain = "$VPN_DOMAIN$"

# Path to the NECLI executable
$EXE = "C:\Program Files\SonicWall\SSL-VPN\NetExtender\NECLI.exe"

# Connect to the VPN using NECLI
Start-Process -FilePath $EXE -ArgumentList "connection add $VPNName -s $VPNServer -u $Username -p $Password -d $Domain -v auto" -Wait

# Connect to the VPN using NECLI
Start-Process -FilePath $EXE -ArgumentList "connect $VPNName" -Wait

All Comments (6)

avatar

Hello,

Would it be possible for you to update to the latest version, 2025.2.30.0, and see if this issue still occurs with the NetExtender entry?
We fixed an issue similar to this in the 2025.2 version and we would like to confirm if this indeed solves your issue.

Regards,

Hubert Mireault

avatar

The update to 2025.2 fixed the built-in sonicwall netextender VPN connector. It no longer leaves temp configurations. It did not fix the issue that I posted using my custom powershell script and the green connected indicator showing up after a connection was completed.

For now, we'll use the built-in one, but would be nice to know what we are doing wrong with our script for future reference.

avatar

I'm glad to hear the NetExtender entry now works as expected for you.

For the Powershell, RDM considers the entry running only as long as the Powershell process it started is still found. At the moment there's no way to script the verification to see if the entry should still be considered opened. So, I don't think you're doing anything wrong with your script, it's just how RDM works at the moment. We would need to add a new feature for this if we wanted to change that behavior.

Regards,

Hubert Mireault

avatar

After some more testing there is one issue with the built-in NetExtender VPN. If you do NOT check off "Automatically Delete profile on close", the next time you open the VPN, you will be prompted for the password (IE: First time creates the profile and works fine, the 2nd does not). The password is not stored on the created profile in the NetExtender app (I ran into this when writing our own powershell script). The profile does have the security setting to allow passwords in variables set as well.

avatar

As far as I'm aware this is a limitation by the integration. As you mention, it acts the same when you do it through your scripting. Unless you have a solution we're not aware of that we could implement, this is the best we can do at the moment and we need to clear the profile to be able to send the password properly.

Regards,

Hubert Mireault

avatar

Pretty much, same problem. I was playing around with passing the password if prompted, but no luck so far.