SonicWall TSR to CSV

Published the first version of my SonicWall Technical Support Report (TSR) to CSV. Unless you are constantly looking at the SonicWall TSR you will not know where to look and you will be trying to search through looking for what you want. With this Python script, it will take the information and drop it into a CSV file for easier navigation and filtering base on columns.

Currently this supports the following sections:

  • System Info
  • Interfaces
  • Address Objects
  • Address Groups
  • Service Objects
  • Service Groups
  • Zones
  • Access Rules

Navigate on over to: to get the script and test it out.

Feel free to give any feedback on it and follow it as there will be updates including more sections soon.


Automating SonicWall NetExtender

Just published to my Github a Python script that automates logging into NetExtender with us of PyAutoGUI.

This script will take static variable inputs then try launching NetExtender and looking in with those preset login information that was provided in the script. The script will also error check making sure that the service and the application are started and if they are not it will go ahead and launch them.

Most of this is statically set like, Username, Password, Server IP, Domain, and the location of your NetExtender install.

The Github repo provides the needed images for the script to run, so make sure you download those as well. Images may need to be updated if you are using a different version than SonicWall NetExtender 8.6.263.

Here is the repo:


SonicWall Lab Automation – Entry 1

On this past Friday evening I wanted to set a goal for the weekend and what I came up with was a script/Module in Powershell to automate my SonicWall lab. The entire goal of developing this would be to save all that time waiting for firmware upgrades and factory reboots to take place. This would also go and do a basic configuration of the device.

Initial challenges were presented right away with the fact that registration of the SonicWall UTM appliance can only be done via the Web UI, current version of 6.5. This would mean digging into a common web test tool called Selenium, where luckily some have already written a few tools in Powershell to simplify things a little more.

Now the SonicWall UI is a set of iFrames which when using Selenium can cause some issues when looking for specific elements inside of said frames. This is made easier with the fact that you can actually, after authentication, directly navigate to some of the pages required. Example below:

This is the direct access to the registration page for the SonicWall UTM

Now with this discovery it was a bit simpler and easier now that there were far fewer elements and easier direct approach to fill in these forms. The registration portion is now complete, on to the next challenge “Handling Firmware Uploads and Factory Defaulting.”

There were a couple of challenges here but none with a solution.

  1. How to get the firmware uploaded into the SonicWall

I tried to do the way of using Selenium but unlike the Registration page, if you try to go to its directly hosted page you cannot interact with the page whatsoever. The only next solution was to use the CLI, and luckily SonicWall can have firmware uploaded via FTP and SCP. But, now where was I going to get this FTP server ? If I were programming in Python I could just program in a simple FTP server and host the file from there but I wanted to keep this purely in Powershell and I do not believe you can do such a thing. So, I looked towards an application solution and came up with installing Filezilla Server on the VM behind the X0 of the SonicWall.

Once the FTP server was up and running I used Posh-SSH , posted previously on, and wrote up a set of commands to get the job done. If you are familiar with SonicWalls you will know that when you boot to firmware that there is about a 600 second wait timer that runs while it handles writing the settings file to flash. Well this is where I ran into my first issue, where I had set the script to run too short and it killed the session too early thus corrupting the firmware image on the box causing it to boot into safe mode.

This is always why you test and test then test again in a lab environment when you have full access to the appliances for issues like these. Was not much of a matter, just manually re-uploaded and booted to the firmware to recover but definitely got me thinking to be sure of things when doing things in the future.

2. How to get back into the SonicWall after Factory Default

This is currently being handled via a manual process of executing another script from the Console side to go in and enabled SSH on the X0. In 6.5 firmware only the HTTPS management is enabled.

3. Configuring the SonicWall

This is handled via a single script that reads a text file full of CLI commands. It is a very basic approach but hopefully in the future I will be able to add more brains to this part of the process. This has now full reliance on the commands that you put into the text file and the order in which you put them in. If you know you cannot create an Address-Group that contains an Address-Object that has yet been created.

But by the end of the weekend, I am now successfully able to run a few Powershell scripts to Upload, Upgrade/Factory Default and/or Configure my SonicWall’s in my Lab. The time that will be saved will allow for more time in testing and enhancing this automated code base.

Once the code is more well built and sustainable for movement from machine to machine then it will be published to my Github and potentially Powershell community for all to use with simple commands of Execute-SnwlFacDef and Set-SnwlConfigFile and Execute-SnwlRebuild.


How to hide Virtual office Download Links in SonicWall

Some of the times the SonicWall Virtual Office page does not have the latest version or most stable version of NetExtender so sometimes you would like to hide it to prevent users from downloading it. Here is a simple Javascript way of doing so.

Default view

In the Sonicwall head on over to your Portal Settings page and then inside of the Home Page Message box put the following:

x = document.querySelector(“form”);
myDivs = x.querySelectorAll(“div”);
myDivs[1].style.display = “none”;
myDivs[2].style.display = “none”;

Now when you visit the page it will look something like this:

After applying the code

Locking Down SonicWall Management

This post is all based on 6.5+ SonicWall UTM firmware. Most of this does apply to the SonicWall in general but some features may be mentioned that are only available on 6.5+

To start this of, we will first need to talk about a unique feature of the SonicWall. An that is the Service objects that it uses to identify the management features of the SonicWall to separate them from any other port/service used in the rule sets. There will be a service object for each of the management type; HTTP, HTTPS, SSH, Ping and SNMP.

These objects will change when you modify them in any of the appliance configurations. The only ones you cannot change are SNMP and Ping because they follow the industry standard for them.

When creating access rules these Service Objects would need to be used or else these access rules will not affect the Management of the SonicWall.

Access Rule Lockdown

This is a simply method, but also can be confusing for times if you do not understand flow of traffic and how it works within the SonicWall.

First one we will look at is the WAN lockdown rule.

Head on over to Access Rules and select WAN to WAN as the rule set that you are looking out. You should be seeing the rules for the management settings that you have enabled already. They should look like this:

If you do not see these rules, then you do not have these management options enabled on your WAN interface(s)

All you need to do is change the Source object and assign whatever IP address that you would like to allow management to the WAN side.


It would be suggested that you use at least 1 DNS object in here if you are mainly remotely managing your SonicWalls. This will allow for a simple DNS change to regain access to the SonicWall if ever for some reason you lose access from that Static Address.

This method can be applied to any of the Access Rules that you would like to lockdown and ensure systems do not have access to your SonicWall that should not. Like internally on your LAN, if your IT machines are assigned static IP address you create the rule on LAN to LAN to lock it down to ensure that not some random user to pull up the admin login page on the SonicWall.

Port Changing

Changing the ports, goes along with the old school rule in security of “Security by obscurity” which really does not stand true anymore today with all the scanning and fingerprinting tools out there, you cannot truly hide openly like this. With that said, it is still generally best practice to change these ports, especially if you are allowing WAN management so the standard bots out on the Internet are not finding your edge device.

Having this enabled is not always the best, as this just allows another port to be able to be found to bring someone directly to the admin login page.

Changing the Management ports on the SonicWall, when you first start configuring, is also a best practice as using 80, 443, and 22 could interfere with any future NAT policies that you may implement if using the IP address on that WAN interface.

Certificate Authorization

This would be something to implement if you would like to really restrict your management and if you have something like a CAC system implemented. (Will go more in detail on this feature in a future post)

One Time Password

Setting up and actually using the TOTP feature would be something that would be highly effective on locking your system down, if you are unable to IP lockdown your access. Adding on a 2FA (2 Factor Authentication) will add that additional layer security to whatever options you may choice to implement.


Getting Started with SonicWall UTM

Now in general with any networking appliance many thing you just plug it in and start configuring it for the needs of your network. But, there are always something here that in best practices terms should be completed before doing so to ensure optimum use of the appliance or even sometimes any future issues down the road.

With a SonicWall appliance, I have always had the best practice of factory defaulting the device before starting anything else. This even goes before uploading any newer firmware. This is to ensure that if there was anything imported into the device or something in QA done to it that there is nothing left over.

After factory defaulting that device, I will then grab the firmware that I would like to put on it, upload it into the device then “Boot to Factory Default” for that firmware. Yes yes, I know you say “Why would you do this again, when you just did it?” That is because you want a fresh clean slate, and having a firmware upgrade path is not a fresh clean slate. Say if the device you got has firmware on it and you are upgrading to firmware, who knows what even in the default settings file may have issues with that change of firmware. The second number in the SonicWall firmware versioning, is a feature implementation so there could be a new feature in there that didn’t play well with converting some settings over and then 3 years down the line you call into SonicWall support and find out oh yeah there was this issue that started when you first installed this box and now you have to Wipe and Type because of corrupted settings.

Now after Factory Defaulting, then uploading the firmware you would like and booting to Factory Default on that firmware you are going to want to configure your WAN interface and that is all. I suggest to use the commonly used public DNS servers, or or, so that when we go to register the device you will not run into any issues.

I will now go ahead and register and license this box before ANY configuration more than that of the WAN interface. I do not change the LAN IP or anything else, just configure your WAN interface and register and license it. Make sure you check over all the licensing to make sure it is accurate then go through the settings and make sure all of the security services enable and update their databases.

After all of this is completed, you are now ready to start configuring your device as needed and you will have a little less worry about anything else happening as you now have a rock solid foundation to move forward on.


How to download a SonicWall TSR and Export Settings in 1-Click

Normally you have to do both of these things in 2 steps that can use up some time, depending on model and the latency between you and the device.

I have discovered that, when authenticated to the SonicWall, you can do a simple URI change to download either the Tech Support Report or the Settings file export. Then a college pointed out that you can use booklets and Javascript to do this. + “/sonicwall.exp”), + “/techsupport.wri”)

This is just a little snippet of Javascript that you can throw in the URL portion of a bookmark and then click this bookmark when you want to download the TSR and Export settings in 1-click

When you click this, it opens 2 tabs and 1 will run then the other will sit and wait. This is because the SonicWall only allows 1 web socket to be active at a time per IP address. So, yes this means until the files finish downloading you will not be able to do anything on the device but that really should not take too long.

It was also found that you only need the word ‘sonicwall’ and ‘.exp’ for the settings download and it will still name it with that default convention and ‘techsupport’ and ‘.wri’ for the TSR and once again it will keep the normal default naming.

This was tested on the most current SonicWall UTM firmware and even as far back as firmware this little trick will work.