Security

SonicWALL PRO-VX provides fast, simple firewall and VPN solution

In this case study, Robert McIntire shares how he helped a client with a complex networking problem using a simple solution: the SonicWALL PRO-VX firewall. Learn how they quickly set up the VPN and firewall with this flexible appliance.


A recent network project that I worked on combined several elements that made it worthy of documenting. The client already had in place a rather elegant VPN solution for LAN-to-LAN connectivity, which was designed by their ISP. But this was only a starting point. The next phase of the project was to implement a firewall/VPN solution for network security and remote user access. The device chosen by the client was the SonicWALL PRO-VX firewall VPN appliance. It provided for firewall protection and VPN connectivity, and among other things, had a certain level of ease in the management category through a Web-based configuration utility. The SonicWALL solution is ICSA-certified, meaning it would provide all the protection the company would need for its private network.

In this Daily Feature, I will tell you how we set up the VPN and firewall quickly and easily.

Firewall features
The designers of the SonicWALL PRO-VX provided for flexibility in configuration of the firewall and its connectivity options. With only three Ethernet interfaces—LAN, WAN, and DMZ—and a GUI interface for software configuration, setting up the SonicWALL PRO-VX is quite simple. The SonicWALL even includes default firewall rules that allow you to get started immediately.

SonicWALL has simplified the SonicWALL PRO-VX so that:
  • ·        All users on the internal LAN are allowed access to the external network via the WAN interface.
  • ·        All users have access to the DMZ.
  • ·        All users automatically have access to the VPN when their accounts are created.

The designers have gone out of their way to make installing and managing this box as simple as possible. It’s a good thing that ease of configuration doesn’t equate with ease of compromising. In fact, with the SonicWALL, ease of configuration is inversely related to its level of security.

The SonicWALL has several varied and sophisticated features to provide advanced protection for networks. By default, it blocks NetBIOS broadcasts, which is essential in a Windows-centric desktop world. Some of the other features provide for distributed denial of service (DDoS) protection, content filtering, antispoofing, and secure remote management. Most features can be easily configured through tabbed menus on the main configuration page.

Network design options
In most networks, it is simple to set up the SonicWALL. With Ethernet interfaces, you simply insert the firewall between your Internet router and internal switch, and change the default gateway at the workstations to point to the LAN interface of the firewall.

However, our design was a bit more complex because of the client’s existing VPN, which had been customized by the ISP. In this network, the data stream coming down the T1 to the central office router was twofold. The T1 serial interface was logically split at the Cisco router into two subinterfaces, with one interface carrying Internet traffic and the other interface carrying interoffice traffic from remote LANs.

Of course, you would normally expect any traffic entering the WAN interface of the firewall to be external, rather than a mix of external and private LAN traffic. It was our good fortune to work with a device that gave us the options necessary to successfully implement such a design. This was possible in part, because you can configure the SonicWALL to perform NAT or not to perform it. If you use NAT, the WAN interface of the SonicWALL is publicly addressed and can be hit directly from the Internet. If you don't use NAT, the WAN interface simply passes outbound traffic to the Internet router, which then handles NAT. Keep in mind that our network design is a little out of the ordinary, since we have private LANs on both sides of the firewall. Some of the steps we took aren’t usually recommended by SonicWALL or most network administrators, but it helps to know that they are available for use in demanding environments.

Router configured for NAT
In this design scenario, we left the Cisco router configured for NAT, as it had been previously. We physically connected the firewall in-line between the WAN and LAN with the WAN port connected to the routers' inside Ethernet port and the LAN port to the local switch. In this case, we assigned the 192.168.1.0 address from the LAN subnet to the SonicWALL LAN port and the router Ethernet port. However, this poses a problem, because the WAN port doesn’t get a public IP address unless you want the SonicWALL to handle the NAT function.

With no public address on the WAN interface, you might wonder how the VPN clients connect to the SonicWALL. To make this happen, we used a separate, private subnet address allocated by the ISP. This address was advertised on the Internet using a static NAT map statement on our Internet router, which mapped all IP traffic from this address to the LAN address of the firewall. For security purposes, we applied an inbound Access Control List (ACL) to the outside interface of the router to allow only IPSec tunnel traffic to this VPN-specific address. The NAT and ACL statements look like this.

VPN configuration on the firewall
The SonicWALL automatically inserted new access rules to allow IPSec traffic through. This was a nice touch that really simplified the configuration. Other static mappings were inserted at the router to map mail and Web traffic from the router’s T1 interface to the appropriate servers on the internal LAN. Once we had the ISP insert MX and WWW records for the domain, we were up and running. The VPN clients could then access the SonicWALL, because its address, 192.168.1.5, had been mapped to a legal IP (200.200.210.2) on the Cisco router. At this point, we had one public IP address assigned to the external router interface for connectivity to the Internet and another public IP address dedicated solely to remote VPN client access via redirection.

A fast, simple solution
Suffice it to say that this was the quick and easy way to get the client up and running, because it required the least amount of change to the existing network configuration. But sometimes, quick and easy solutions are a consultant’s best friend. I know that if I’m ever in need of another fast VPN fix, I’ll be heading right back to the SonicWALL.

More information on NAT and Cisco


 

Editor's Picks

Free Newsletters, In your Inbox