I recently worked on a network project that combined several noteworthy elements. The client already had in place a rather elegant VPN solution, designed by their ISP, for LAN-to-LAN connectivity. But that 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 client chose the SonicWALL PRO-VX firewall VPN appliance for this purpose. It provides for firewall protection and VPN connectivity, and its Web-based configuration utility makes it easy to manage. The SonicWALL solution is ICSA-certified, meaning it would provide all the protection the company would need for its private network.
Here’s how we set up the VPN and firewall quickly and easily.
The designers of the SonicWALL PRO-VX provided for flexibility in configuring the firewall and its connectivity options. With only three Ethernet interfaces—LAN, WAN, and DMZ—and a GUI interface for software configuration, the SonicWALL PRO-VX is simple to set up. The PRO-VX even includes default firewall rules that allow you to get started immediately.
SonicWALL has simplified the 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. But its ease of configuration doesn’t make it easy to compromise. The PRO-VX employs several 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 configured easily through tabbed menus on the main configuration page.
Network design options
In most networks, setting up the PRO-VX is simple. With Ethernet interfaces, you simply insert the firewall between your Internet router and internal switch and then change the default gateway at the workstations to point to the firewall’s LAN interface.
However, our design was a bit more complex because of the client’s existing customized VPN. 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 carrying interoffice traffic from remote LANs.
Of course, you’d normally expect any traffic entering the firewall’s WAN interface to be external, rather than a mix of external and private LAN traffic. It was our good fortune that the PRO-VX gave us the options necessary to successfully implement such a design. This was possible in part because the PRO-VX gives you the option of performing—or not performing—network address translation (NAT). If you use NAT, the PRO-VX’s WAN interface 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. SonicWALL (and most network administrators) wouldn’t usually recommend some of the steps we took, but it helps to know these options 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 up to now. 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 PRO-VX LAN port and the router Ethernet port. But this approach poses a problem, because the WAN port doesn’t get a public IP address unless you want the PRO-VX to handle the NAT function.
With no public address on the WAN interface, you might wonder how the VPN clients connect to the PRO-VX. To make this happen, we used a separate, private subnet address allocated by the ISP. We advertised this address on the Internet using a static NAT map statement on our Internet router, which mapped all IP traffic from this address to the firewall’s LAN address. For security purposes, we applied an inbound Access Control List (ACL) to the router’s outside interface to allow only IPSec tunnel traffic to this VPN-specific address. The NAT and ACL statements are shown in Listing A.
VPN configuration on the firewall
The PRO-VX 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 PRO-VX because its address, 192.168.1.5, was mapped to a legal IP (22.214.171.124) 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. Sometimes, quick and easy solutions are a consultant’s best friend. If I’m ever in need of another fast VPN fix, I’ll be heading right back to the PRO-VX.