Category Archives: SonicWall

Configuring SonicWALL to work with Chromecast

9 Replies

In this write up I’m making the following assumptions:

  1. Your Client (Device trying to Connect to Chromecast) and your Chromecast are on SEPARATE zones. For example: Client is on the LAN and the Chromecast is on say, a wireless zone.
  2. The Wireless Access Point(s) that the Chromecast is connected to are already configured for Multicast (Ill have some other posts for how to configure those later. Update: Here and Here)

First off we need to enable multicast, and here is how we do that:

  1. Login to the SonicWALL and click Firewall Settings from the left hand pane
  2. The menu will expand, when it does click Multicast
  3. Check the box titled Enable Multicast
  4. UnCheck the box titled Require IGMP Membership reports for multicast data forwarding
  5. Select the radio button titled: Enable reception of all multicast addresses
  6. Click Accept at the top
  7. Now click Network from the left hand drop down, and when the menu expands click Zones
  8. For each Zone that will be participating with chromecast, click the configure icon, Check the box titled Allow Interface Trust if it’s not already selected. Click OK
  9. From the Network menu on the left click Interfaces. For each interface that’s part of any zone configured in step 8 perform the following: Click the configure icon for the interface, click the Advanced tab, check the box titled Enable Multicast Support. Click  OK.
  10. Now click Firewall from the left hand drop down, and when the menu expands click Access Rules
  11. Select the radio button titled Matrix at the top
  12. For each zone that was configured in step 8, select the rule from ZONE to MULTICAST
  13. Ensure that there is an ALLOW rule with ANY listed for Source, Destination, and Service. If there is not an ALLOW ANY ANY ANY rule, create on. Repeat for each Zone that was configured in step 8
  14. Update: as James points out below, you also need a traditional  bi-direction Allow rule between both zones.

Testing

  1. From your Client, open Chrome and download the extension “googlecast” if it’s not already installed.
  2. Verify that when you try to cast a tab, the Chromecast that’s located on the other interface/zone is listed.

Installing Certificate Services, and configuring LDAPS on a SonicWALL

Leave a reply

Assumptions: SonicOS 5.8+ and Windows Server 2008 R2 Enterprise running as a domain controller.

  1. On the Domain Controller: Open “Server Manager”, click “Roles”, click “Add Roles”.
  2. Click “Next >”, ensure there is a check mark next to “Active Directory Certificate Services”, click “Next >”, Click “Next >”, Ensure there is a check mark in the boxes “Certification Authority”, “Certification Authority Web Enrollment”, and “Online Responder” (Certification Authority Web Enrollment” and “Online Responder” are not technically needed, but are common parts of a CA infrastructure that should also be installed if you are installing a CA), Click “Next >”, Approve the installation of the IIS components that are required to run the Web Enrollment, Select the “Enterprise” radio button and click “Next >”, Select the “Root CA” radio button and then click “Next >”, Select the “Create a new private key” radio button and then click “Next >”, Select “RSA#Microsoft Software Key Storage Provider”, “4096”, and “SHA512” from the drop down boxes, click “Next >”, Edit the Common Name for the CA if desired, and then click “Next >”, Change the validity period if desired, and then click “Next >”, Click “Next >” to leave the database in its default location, click “Next >” to install IIS, Leave default IIS installation options checked, and click “Next >”, click “Install”, Click “Close”.
  3. From the Domain Controller, open Internet Explorer, and go to http://127.0.0.1/certsrv, when prompted login with the Domain Administrator account.
  4. Click the link “Download a CA Certificate, certificate chain, or CRL”
  5. Select the certificate with the common name from step 2, and then ensure the radio button “DER” is selected, click “Download CA Certificate”.
  6. Rename this certificate to match that of the common name and save it on the desktop.
  7. Login to the SonicWALL.
  8. Expand “System” from the left hand pane, and then click “Certificates”.
  9. Click “Import…” at the bottom.
  10. Select the radio button “Import a CA certificate from a PKCS#7 (.p7b), PEM (.pem), or DER (.der or .cer) encoded file.” Is selected, and then click “Browse…” Select the certificate with the common name that you set in step 2. Click “Open”, Click “Import”.
  11. Expand “Users” from the left hand pane of the SonicWALL, click “Settings”.
  12. Change the drop down box titled “Authentication method for login: “ to “LDAP + Local Users”.
  13. Ensure that the check box “Case-sensitive user names” is UnChecked.
  14. Click “Accept” at the top.
  15. Click the “Configure…” button next to the “Authentication method for login: “ drop down box.
  16. On the “Settings” tab enter the IP address of the Domain controller in the box titled “Name or IP Address:”, Change “Port Number:” to “636”, change the radio button selection to “Give login name/location in tree”, Enter a Active Directory user account( a service account with “Domain Guest” group membership will suffice) in the “Login user name:” field, enter the password for the account in the “Login password:” field, UnCheck “require valid certificate from server”.
  17. On the “Directory” tab enter the following: In the “Primary Domain:” field enter the DNS active Directory Domain Name, change the “User tree for login to server:” to the full path of where the service account (used on the Settings tab) is located in Active Directory (spaces are okay), click “Apply”.
  18. Click “Auto-Configure” to test populate the directories in AD which contain Users or Groups.

So long as your list populated with OUs you should be good, this is everything you need to do in order to secure the connection between your SonicWALL and your domain controller.

Installing SonicWALL Analyzer

3 Replies

Here is a quick and dirty guide to getting SonicWALL’s Analyzer software installed, configured, and displaying information about your hardware device:

  1. Download the SonicWALL Analyzer software for windows from MySonicwall.com
  2. Install using default options, and when prompted make sure to select the proper IP on the workstation/server to use to receive communications from the SonicWALL hardware device.
  3. Open port UDP 514 and UDP 162 on the Workstation/Server’s Windows Firewall to allow for Syslog and SNMP traffic to be sent to the server from the SonicWALL hardware Device.
  4. After Installation, reboot the Workstation/Server.
  5. Launch the SonicWALL Universal Management application from the start menu/desktop.
  6. Login with the default username /password of: admin/password.
  7. Set a new password for the UMH aspect of the software.
  8. Register the software with mysonicwall.com using the link at the top of the application.
  9. During the registration process, enter “ANALYZER” in the serial number field. Add a Description of the PC. Click Submit.
  10. Under the “Roles” section in the left hand pane, enter a username, password for the database and password for the database administrator. Click Update. Make sure to create a user account that IS NOT “root”, you can use anything but “root” for the database User.
  11. Under “Settings” section in the left hand pane, enter the SMTP settings necessary to send emails.
  12. On the SonicWALL, expand “Log” on the left, and then click on “ViewPoint”. Click “Add” and then enter the IP address of the workstation/server running analyzer.
  13. Install Java and flash on the Analyzer workstation/server.
  14. Attempt to log into the analyzer software now (same link as the Universal Management tool) and then you will be prompted to change your password for the analyzer user.
  15. Once Logged in, click on the “Firewall” tab at the top, then click the small button on the left to add a Hardware Device to be monitored.

This will get you up and running any analyzing traffic in real time.

Installing SonicWALL Directory Connector ( SSO Component )

Leave a reply

This is a short and sweet mini-guide to setting up the SonicWALL Directory Connector. This should be everything that you need to get it up and running, from there you can setup the more advanced functionality, such as Terminal Services Integration on your own.

  1. Download and the SonicWALL Directory Connector for either 32 bit or 64 bit systems from mysonicwall.com
  2. Install the product with its defaults, when prompted for credentials enter a domain admin’s credentials.
  3. When Prompted to enter SonicWALL Device information enter the Internal IP of your SonicWALL, and create a shared key to be used by the SSO Component and your Device.
  4. Finish the Installer and then launch it.
  5. Now log into your SonicWALL Device and Expand “Users” in the left pane and then click on “Settings”.
  6. Under the section “Single-sign-on method:” change the drop down box to “SSO Agent” and click on the “Configure” button.
  7. On the “Settings” tab click the “Add…” button to add your agent, modify the IP, Port, and Shared Key to that of your server/workstation running the software. Click Apply. NOTE: If the status light does not turn green, you may need to add a firewall rule on the server/workstation to allow inbound connections on that port. I’ve also had to add both of these .exes to the list of excluded applications to get this software to work through the windows firewall: %ProgramFiles% (x86)\SonicWALL\DCON\CIAService.exe, %ProgramFiles% (x86)\SonicWALL\DCON\SoniCON.exe
  8. Under the “Users” tab make sure to add the Usernames of any Service accounts on the network that should be excluded from SSO reporting.
  9. Create a new Address Group on the sonicwall, and place into it all Devices that should be excluded from SSO Attempts, such as routers, switches, printers, wireless access points, basically anything that isn’t a windows PC. All of these devices will be governed by the “Default” Content Filtering Policy if CFS is in place.

Hopefully you found this helpful and it saved you some time.

Force All Traffic over a NetExtender SSL VPN Connection, but allow users to continue to access the Internet.

Leave a reply

I have a client that is using a medical application whose access to the cloud based storage is locked down by Public IP address. This restricts access to the application to only folks who are in the office, Users who work from home, or take their laptop home with them on the weekend are unable to work from home. To solve this problem I’ve setup netextender and forced it to tunnel all traffic back into the main site, but users were then unable to connect to any resources on the internet.

Here is how to resolve this issue. First let’s configure the SSL VPN:

  1. Log into your Sonicwall, and expand “Network”
  2. Click on “Interfaces” and then click on the Configure link for your WAN connection.
  3. Make sure the box that says “User Login: Https” has a check mark, and then click “OK”
  4. Expand “SSL VPN” on the left, and then click “Server Settings”
  5. Click the red dot next to “WAN” and wait for it to turn green.
  6. Click “Client Settings” on the left, and then configure an IP address range for your SSL VPN Guests, also configure the User Domain, and DNS servers.
  7. Click “Client Routes” on the left pane, Enable “Tunnel All Mode”, this is done to ensure all traffic sent by the client appears to originates from the main office, and not the client’s home router.

Now let’s create a user and grant them access to the appropriate networks during an VPN connection.

  1. Expand “Users” on the left, and then click on “Local Users”.
  2. click “Add User…”
  3. On the “Settings” tab, give the user a username and password.
  4. On the “Groups” tab, Add the user to “Trusted Users”, “Everyone”, and “SSLVPN Services”. Click OK.
  5. Click “Local Groups” on the left.
  6. Click on the “Configure” button for the group “Trusted Users”
  7. Click on the “VPN Access” tab, add “LAN Subnets” and “WAN RemoteAccess Networks” to the list. Click OK.

Now have the user connect to the SSL VPN, open a command prompt and ping anything, the first hop should be the main office’s WAN connection’s Default gateway, this shows that you’re tunneling all traffic over the SSL VPN and still able to get online.

Applying a NAT policy to a Sonicwall VPN Tunnel

15 Replies

I recently had an opportunity to setup something that I’ve never configured before. I had to build a site to site VPN with a vendor into a network that used the same IP scheme as one of the vendor’s subnets. Normally the IPs on either side of the tunnel are different, in this case the vendor already had a subnet in their network with the same IP address range as our internal subnet, so this wouldn’t allow us to build a tunnel between the two sides wouldn’t route the traffic to the other, both would think the traffic is local.

We decided that we would mask my client’s internal subnet to some other range so that the internal subnet wouldn’t interfere with the subnet that the vendor had internally.

Let me break this down into numbers that make some sense:

  • Our local subnet was 192.168.1.0/24
  • The Vendor’s subnet was 10.0.0.0/24 (but they also had a subnet in their network for 192.168.1.0/24, which is why this would not work, our traffic would  get to them, but wouldn’t make it back out over the VPN on the way back)
  • We decided that we would mask our 192.168.1.0/24 subnet as 192.168.254.0/24

Here is how the router was Setup:

First we needed to make some Address Objects in the Sonicwall

1)      Expand “Network” in the Sonicwall’s left hand pane

2)      Click on “Address Objects”, and Create the following Address Objects:

  • Name: Vendor Network,  Zone: VPN, Network: 10.0.0.0, Netmask: 255.255.255.0
  • Name: Local Network, Zone: LAN, Network: 192.168.1.0, Netmask: 255.255.255.0
  • Name: Masked Local Network, Zone: VPN, Network: 192.168.254.0, Netmask: 255.255.255.0

Next we need to build the VPN Tunnel

1)      Next Expand “VPN” in the Sonicwall’s left hand pane

2)      Click on “Add..” to create a new VPN

3)      Fill in a Name,  IPSec Primary Gateway, Shared Secret and then click the “Network” tab

4)      Under the Section “Local Networks” select “Local Network” from the drop down list

5)      Under the Section “Remote Networks” select “Vendor Network” from the drop down list, and then click on the “Advanced” tab

6)      Select the box for “Keep Alive” and the box for “Apply NAT Policies”

7)      Change “Translated Local Network:” to “Masked Local Network” using the drop down selection box

8)      Change “Translated Remote Network:” to “Original” using the drop down Selection box and press OK (note: we did not go over the proposals tab because it’s not relevant to this configuration)

Finally we’ll need to setup some one-to-one NAT rules to allow traffic from our Vendor to our desired Server(s). Note: This section may not be needed, when I configured this we were actually bringing 3 different subnets into the tunnel using just a single masked subnet, so I ended up needing to do this, but it’s possible that you won’t need to do this if you’re only using a single subnet on each side, so check to make sure the tunnel is routing traffic properly before moving forward with these steps.

1)      Expand “Network” in the Sonicwall’s left hand pane

2)      Click on “NAT Policies” in the Sonicwall’s left hand pane

3)      Here is where things can get a little tricky, basically we need to make a rule for each object that needs to be accesses by the vendor’s subnet. Let’s assume it’s only our one server, which happens to be 192.168.1.10. If you’ve got more than one server, you can create multiple rules

4)      Click “Add…” to start a new NAT rule and enter the following:

  • Original Source: Vendor Network
  • Translated Source: Original
  • Original Destination: 192.168.254.10 (remember this is coming FROM the vendor to the Masked Address)
  • Translated destination: 192.168.1.10
  • Original Service: Any
  • Translated Service: Original

Once this rule is created your vendor should be able to access you server at IP address 192.168.1.10 by using the IP address of 192.168.254.10.

This is a confusing configuration, so email me if you have any questions, and good luck.

Configuring IPSecuritas for Use with a SonicWall TZ190 Enhanced, Part 2 Configuring the Client Computer

2 Replies

This is part two of Configuring IPSecuritas with a Sonicwall TZ190 Enhanced. If you missed the first part you can go back and check it out here.

Find the information you recorded in Part 1, we’ll need it below.

  1. Download and Install IPSecuritas. Refer to installation manual if needed.
  2. Launch IPSecuritas and then launch the Connection window by clicking the Connections menu and then selecting Edit Connections….
  3. Click the Plus Sign ( + ) at the bottom left to create a new connection. (shown as “TEST CLIENT”) Enter the WAN IP Address of the sonicwall in the Remote IPSec Device field. Select Host in the Endpoint Mode (Local). Select Network in the Endpoint Mode (Remote). Enter your network Address. See Figure 1.
  4. Click the Phase 1 Tab. Enter the information from Part 1 Step Four: 28800, DH2, 3DES, SHA-1. Exchange Mode: Aggressive. Proposal Check: Obey. Nonce Size: 16. See Figure 2.
  5. Click the Phase 2 Tab. Enter the information from Step Four: 28800, 3DES, SHA-1. PFS Group: None. See Figure 3.
  6. Click the ID Tab. Local Identifier: Address. Remote Identifier: Set this to FQDN, Use the Firewall Identifier from Step Seven. Authentication Method: Preshared Key. Use Preshared Secret from Part 1 Step Three. NOTE: If you are using XAUTH change Authentication Method to XAUTH PSK, enter User and Password  from Part 1 Step Ten and Preshared Secret from Part 1 Step Three. See Figure 4.
  7. Skip the DNS tab, Click the Options Tab. Make sure your Settings appear the same as the picture. See Figure 5.
  8. Click START from the IPSecuritas Program or Widget.

Again, these instructions have only been tested with a Sonicwall TZ190 Enhanced, These instructions may need to be alerted to work with other SonicWall Models. Please let me know if you’ve been able to get these instructions (or slightly modified instructions) to work on any other SonicWall routers.

Attached Files:

Configuring IPSecuritas for Use with a SonicWall TZ190 Enhanced

Leave a reply

Okay here’s another guide that probably should have been put online sooner, but hey better late than never right? I’m sure there are probably a ton of TZ 1×0’s kicking around and if you’ve got a MAC and want to VPN in, but don’t have the SSL vpn software then you’ll need this guide. I’ve not tested this with anything other than a TZ190 Enhanced, but I’m pretty confident that it would work with at least any Enhanced OS in that same generation of SonicWalls, and maybe even outside of that generation as well.

This is the equivalent Global VPN Client for Mac.

Here is Part 1 – Router Side Configuration:

  • Note: Identify whether or not the SonicWall will hand out DHCP addresses. Make note of this as we’ll need it later in the configuration.
  1. Start by clicking the VPN tab and then select Settings. See Figure 1.
  2. Click on the WAN GroupVPN Configure button. See Figure 2.
  3. Set your Authentication Method to IKE using Preshared Secret and Record your Shared Secret. See Figure 3.
  4. Click the Proposals Tab. Record your settings. In this case we are using DH 2, 3DES, SHA1, and 28800 for Phase 1 & 3DES, SHA1, and 28800 for Phase 2. See Figure 4.
  5. Click the Advanced Tab. Without XAUTH (As Shown See Figure 5.): Set Allow Unauthenticated VPN Client Access to Firewalled Subnets. Or With XAUTH (not shown): Check Require Authentication of VPN Client via XAUTH. Change User Group for XAUTH users to Trusted Users.
  6. Click the Client Tab. Change the Cache XAUTH User Name and Password on Client to Never. Change the Virtual Adapter settings: to DHCP Lease or Manual Configuration. Check the Use Default Key for Simple Client provisioning. Uncheck all other options. See Figure 6.
  7. Click Ok. Return to the VPN Settings page. Record your Sonicwall’s Unique ID. See Figure 7.
  8. Click DHCP Over VPN. Click the Configure button. See Figure 8.
  9. If the SonicWall is acting as the DHCP server (as shown, See Figure 9.) then Check Use Internal DHCP Server. Check For Global VPN Client. Or If the SonicWall is NOT acting as the DHCP server (not shown) then Check Send DHCP requests to the server addresses listed below. Click Add… and Add your DHCP’s Server’s IP address.
  10. (OPTIONAL) If you configured Trusted Users as the XAUTH group in Step Five continue with the steps below, Otherwise Skip to configuring the Client.

  • Click the Users Tab, Select Local Users, Click Add User…
  • Add a new user for each remote user and record the passwords.
  • Change to the Groups tab for each user and add that user to the Trusted Users group.
  • Click OK to Exit the New User… Window and then click the Users tab, select Local Groups, and then click the configure button for Trusted Users
  • Click the VPN Access tab, add Firewalled Subnets into the Access List: section. Click Ok

Once You’ve completed these steps and Recorded all of the necessary information that you were asked to record, download and install IPSecuritas from the link HERE, and then Hop over to Part 2 – Configuring the IPSecuritas Client on a Mac, Here.

Attached Files:

OSX 10.6.7 Update Breaks Sonicwall Net Extender (Again)

5 Replies

More Sonicwall NetExtender fun. This time it’s 10.6.7 changing permissions on the /usr/sbin/pppd folder.

I had users over the weekend update Mac OS X 10.6 to version 10.6.7, after the update they were unable to connect to thier Net Extender . When they tried to connect, it failed and then displayed the connetion log. The log contained the following entries:

[general warn 28598] NetExtender 881 closed unexpectedly; attempting to cleanup pppd 28566
[dns info 28608] Restarting mDNSResponder

I’ve only tested this fix for Net Extender version 5.0.680, but I’ve confirmed that it’s working with that version. We’ll need to adjust the permissions on the folder /usr/sbin/pppd:

Open terminal, and enter the following command:

sudo chmod u+s /usr/sbin/pppd

Enter your password at the prompt, allow the command to complete. Once that’s been entered, close and reopen the Net Extender, and then you should be able to connect.

Allow Access to a Dell Remote Access Controller (DRAC or iDRAC) through a firewall

9 Replies

It’s Friday, 4:59pm and you’re itching to get home, that’s when you get a call saying that the server in the remote office is locked up. All the employees of the branch office have left for the day and shutdown all of their PCs. There’s no way to get into that local network and remote control the server or reboot it without fighting through rush hour traffic, trying to remember the security code to the front door, and then playing the ‘see which key fits game’ on 3 sets of locked doors. This could be avoided if you had just opened access to your DRAC to your IP ranges at your main office. Here’s how:

First Identify what ports your version of the Dell Remote Access Controller uses, here’s a short list:

DRAC 4
5900TCP
3668TCP
2068TCP
8192TCP
443TCP (I recommend changing this from within the DRAC’s UI)

DRAC 5
3668TCP
3669TCP
5900TCP
5901TCP
443TCP (I recommend changing this from within the DRAC’s UI)

iDRAC 6 & iDRAC 7
443TCP (I recommend changing this from within the DRAC’s UI)
5900TCP
623TCP

For this example I’m going to be using a SonicWall TZ 210 Router, and we’re going to be Setting up access to a iDRAC 6 that’s IP address is 192.168.1.12.

I’m also going to be adding all of these services into a Service Group, that way I only have to make 1 set of firewall and NAT rules instead of 3. If your firewall does not support this, just make 3(or 5) individual rules, one for each service.

The first thing I’m going to do is change the DRAC’s internal web server to use port 4433 instead of port 443, because I’m already running services over port 443 for something else, and more than likely you are too.

You change this by logging into the DRAC, under the Network/Security section there will be tab for Services Change the HTTPS port number to 4433.

Next let’s create the services, On the Sonicwall. Log into the Sonicwall and on left hand

Figure 1.

pane, expand Firewall, and click Services. Click Add… to Create a new service, enter a name, I typically use DRAC Service 1 or something similar. Change the Protocol to TCP, and Enter your Port range, for the first service we’d enter 623 and 623 again in the second box See Figure 1.

Figure 2.

Once you’ve created all 3 Services you can create a new Service Group, I called mine DRAC Services, and I add all 3of the services that we just created to this group. See Figure 2.

Next we’ve got to create some address objects. Expand the Network on the Sonicwall’s left hand pane and click Address Objects. Click Add… to create a new Address Object. We’re going to need to create two address objects. One for the DRAC which will be 192.168.1.12 and located on the LAN, and the other will be for Our (Your) main office’s public IP(s) and will be located on the WAN. You’re Address Object for the DRAC should look like figure 3.

Figure 3.

Next we’ll create our Firewall rule, expand Firewall on the Sonicwall’s left hand pane

Figure 4.

and click on Access Rules. We’re going to be creating a new rule from the WAN to the LAN. When you create the rule it should look like Figure 4, only with slight changes to the names of the Address Objects you created.

Action: Allow
From Zone: WAN
To Zone: LAN
Service: DRAC Services( or whatever you named your service group)
Source: This will be whatever you named your Main Office’s Public IP address Address Object
Destination: WAN Primary IP (this is because you’ll be accessing the DRAC from the Public IP of the remote office and not from it’s Internal IP address)

We’re almost done now, we just need to create our NAT rule, and then we’ll be ready to test.

Expand Network on the Sonicwall’s left hand pane, and click on NAT Policies. Click

Figure 5.

Add… to create a new NAT rule. You’re NAT rule should look similar to Figure 5.

Original Source: This will be whatever you named your Main Office’s Public IP address Address Object
Translated Source: Original
Original Destination: WAN Primary IP (this is because you’ll be accessing the DRAC from the Public IP of the remote office and not from it’s Internal IP address)
Translated Destination: This will be whatever you named your DRAC’s Address Object.
Original Service: DRAC Services( or whatever you named your service group)
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

That’s it! You should now be able to go to https://YourBranchoOffice’sPublicIP:4433 and log into your DRAC. Note: I’ve had some issues with the iDRAC6 Active X control not working remotely, change it over to Java and it works fine. I’m not sure if this is an issue with just my PC or with something within the Active X control. Let me know if the Active X control works for you after you’ve followed these instructions.

Attached Files: