Category Archives: VPN

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

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

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

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 Four28800, 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 Four28800, 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 ThreeNOTE: 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.

Configuring IPSecuritas for Use with a SonicWall TZ190 Enhanced

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 belowClick 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.

OSX 10.6.7 Update Breaks Sonicwall Net Extender (Again)

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.

SonicWall LDAP bind Error – Remote Authentication – Bind to LDAP server failed

We’ve setup one of our client’s Sonicwall TZ series routers to allow LDAP authentication for VPN connections. Occasionally we were getting alerts from the SonicWall with the following content:

Subject: *** Alert from SonicWALL *** [SONICWALL NAME]

12/14/2010 17:05:22.544 - Error - Remote Authentication - Bind to LDAP server failed - - Credentials not valid at LDAP server - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 775, v1772

This email was generated by: SonicOS Enhanced 5.6.0.3-40o (MAC-ADDRESS-NUMBER)

Of course we’d log in and check it out, we’d hop over to the LDAP section, check to make sure that the user account, password, search context and such were proper, and they were. We’d then run a test bind, and of course it would work fine. It stumped us for a few days but we were eventually able to figure out that the account that the SonicWall was using to bind to the LDAP server was getting locked out due to some other non SonicWall related event, and of course when the account was locked out the SonicWall could not perform an LDAP query, and the users could not VPN in. Once the lockout period expired the SonicWall was again able to perform queries, which explained why when we logged in to test, it was working properly.

The moral of the story? Make sure that the account you are using for LDAP on the SonicWall isn’t used for anything else, so that the chance of someone locking out the service account is low, or you could also remove it’s lockout policy and apply a very strong password.

Mac OS 10.6 Clients unable to resolve DNS on Net Extender SSL VPN

Over the last few days I’ve been running into a problem with Mac OS 10.6 clients and the SonicWall SSL VPN client, NetExtender. The client computers were able to resolve DNS properly prior to installation. The problem didn’t appear until after the software was connected to a endpoint, and then disconnected. Once the connection was ended, boom, no DNS resolution.

I had already updated the endpoint device, a SRA 1200, and the NetExtender was whatever version came with SRA 1200 firmware SonicOS SSL-VPN 4.0.0.3-20sv, which was the most recent firmware available at the time of writing.

I started with a review of the release notes of the SonicWall firmware, which mention a problem with Mac OS prior to version 10.6.5 and NetExtender. I updated one of the client Macs to 10.6.5, but still no luck.

A call to SonicWall ended up with them giving me a new version of the NetExtender software for the Mac, version 5.0.680. I updated the first client and Success! I was able to connect, disconnect, and then continue to resolve DNS.

I thought my problems were over until I re-connected to test that the VPN was still working. Now on version 5.0.680 I was unable to resolve DNS on the other end of the VPN tunnel when connected. I could resolve DNS on my local subnet, and on the internet, but I was unable to resolve anything on the internal DNS servers at the main office that I was connecting to. I verified that I could telnet to port 53 across the tunnel, a NSlookup test proved that I the records I was looking for did exist.

I flushed the dns cache, I verified the /etc/resolv.conf file had the two DNS servers that the NetExtender had placed in there when I connected, and I verified with telnet that a firewall was not blocking DNS to the DNS servers.

I called SonicWall back and after much discussion they recommended that we roll back to version 5.0.679. I downloaded the file, removed the current NetExtender and then attempted to re-install the version 5.0.679. It would not allow me to re-install, stating that a more current version was already installed.

I was able to bypass this error by performing the following:

Drop to Command line and enter the following commands:

sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.bom
sudo rm /private/var/db/receipts/com.sonicwall.NetExtender.plist
sudo rm /etc/ppp/sslvpn.*

I then rebooted the Mac and was able to install NetExtender version 5.0.679. Once installed I tested again. I was able to connect and resolve DNS, good. I was able to disconnect and continue to resolve DNS, even better. And Finally I was able to connect again and continue to resolve DNS still.  Version 5.0.679 on Mac OS 10.6.5 was what ended up working for me.

I’ve attached version 5.0.679 for download if you’re experiencing the same problem. NetExtender.MacOSX.5.0.679

Update 1: Upon further review, it appears that NetExtender version 5.0.679 breaks the bonjour protocol on the Macs that it is installed on. To circumvent this problem we actually went back to version 5.0.680, and statically configured a hosts file for all of the major resources on the other end of the VPN tunnel. Click Here to see how to manually edit a hosts file on a Mac. You can download version 5.0.680 here: NetExtender.MacOSX.5.0.680

Update 2: Thomas (see below) pointed out that it doesn’t matter what’s in the resolv.conf file as Mac OS 10.6 and higher no longer uses this file to determine DNS servers. My writing about about double checking this file will have no impact on this particular problem. The rest of the article will still help you work around the problem though, so good luck!