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.
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:
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.
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.
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 18.104.22.168 firmware on it and you are upgrading to 22.214.171.124 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, 126.96.36.199 or 188.8.131.52 or 184.108.40.206, 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.
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.
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 220.127.116.11 firmware this little trick will work.
This is for those situations where you are trying to find a bunch of lines matching against some Regex and you not only want to remove that match but the line as well.
The regex command being used is: ^.*_.*\R
Breakdown of the command: ^ match start of line .* match any character as many times until it sees an Underscore ( _ ) .* then again match any character as many times needed until it sees a Line Feed \R
Here you can see the Find box where I have hit count and there is 629 matches and there are 3801 lines in this document
Switched over to the Replace tab and hit Replace All and it got all 629 occurrences found.
Now as you can see there are only 3172 lines in this document meaning that those 629 lines were successfully removed from the document.
Pre-req: If you have never installed any modules from PS Gallery you can run the below command so that you do not get the Untrusted Error.
Step 1: Need to change the Execution Policy or you will throw an Error
Step 2: Need to go ahead and install the Posh-SSH module
We are adding on the -RequiredVersion switch as that is the stable version. There is a 2.1 version, but suggested version and this guide uses the 2.0.2 version.
Step 3: Import the module of Posh-SSH to make the commandlets available for use.
Now you can verify this by running a Get-InstalledModule command and should output the Posh-SSH Module
Just for to see what we can do: Let us now go ahead and run the Get-Command and see what Commandlets and functions are available within the Posh-SSH module
Step 4: Initiate an SSH Session with the following command
Even though the switch says ComputerName you can go ahead and put an Ip Address there. We are also going ahead and added the -AcceptKey to accept the RSA key of that SSH session. A Credentials popup window will come up to fill in the login creds, and this can be automated. For now we will just manually fill in the credentials.
Now you have established a session with your remote SSH enabled device. Be on the look out for another post on how to use Posh-SSH with a SonicWall UTM appliance.