Using a Trihomed ISA/VPN Server to Secure Wireless Networks

Using a Trihomed ISA/VPN Server to Secure Wireless Networks

Part 1 – DMZ, VPN, WLAN and Access Control Design Principles

By Thomas W. Shinder, M.D.

Wireless networking is becoming increasingly popular in both small office, medium sized, and enterprise networks. Wireless networking allows wireless clients to roam throughout an office, building or even entire campus and maintain a consistent and reliable link the internal network or the Internet. Wireless network adoption continues to grow at an accelerating pace and if you don’t have a WLAN in place yet, you will in the near future.

The problem is that wireless networks suffer from profound security weaknesses that are directly related to the things that make them so attractive. Wireless networks provide an ideal example of the only inexorable law of security: security and convenience are always inverse related.

For example, the convenience of being able to “pick up” a WLAN connection from a Wireless Access Point (WAP) that broadcasts its SSID is inversely related to the fact that the blue-haired kid in the parking lot is also about to connect to that same WAP while carrying out his evil plot to compromise your network or steal your Internet bandwidth.

This isn’t to say that WLANs are hopelessly unsecure. There are things you can do to make a wireless network almost as secure as a wired network. Some standard security focused actions you can take include:

You can prevent casual users from finding your WLAN by disabling broadcasting of the SSID. This requires that you inform your wireless clients of what the SSID is so that they can manually configure it on their wireless network connections. This incurs more administrative overhead than broadcasting the SSIDs, because you have to find some way to communicate the SSID to known and sometimes unknown users.

MAC address filtering allows you to take advantage of the convenience of broadcasting your SSID and still limit the wireless clients that connect to the WLAN. MAC address filtering is a simple form of network access control where you create a list of MAC addresses allowed to connect to the WAP. If the wireless client’s MAC address isn’t in the list, the client is not allowed access WAP and WLAN. The problem is that it’s relatively easy to spoof a MAC address. Of course, the network criminal would need to know what address to spoof.

One way bad guys can find out what MAC addresses are permitted is to sniff the wireless traffic as it moves “over the wire” (the air in the case of a WLAN). You can slow these criminal “sniffers” down by using a network data encryption protocol. The Wireless Equivalent Privacy Protocol (WEP) can be used protect data as it moves from wireless client to WAP. However, methods are available that allows the intruder to listen on the and to crack your WEP key. Several gigabytes of data need to be collected, but the unemployed criminal hacker sitting in the parking lot in front of your office won’t have a problem sitting there for hours if he needs to do so to collect the required data.

Another security option you can add to your wireless security bag of tricks is 802.1x authentication. 801.1x requires that the wireless client use a certificate to authenticate to the network before the wireless NIC is given access. If the NIC can’t authenticate, then the client is not allowed on the WLAN. In fact, you can use the same mechanism to authenticate Ethernet connections too. However, while 802.1x is very cool and powerful, your WAPs must support it and you still have to deploy a PKI. Who want to spend a mint on a Cisco WAP and who want to incur the administrative overhead of PKI if you don’t have to?

Is there a secure method you can use that provides a combination of security and convenience? What about a method that includes the following:

How do we do all this? The answer is a trihomed ISA Server. The trihomed ISA Server allows you to put all of your wireless clients on a LAT-based DMZ segment. The LAT-based DMZ segment is considered trusted by the ISA Server, but is safety partitioned away from the internal network. Because the LAT-based DMZ hosts are exposed to firewall policy, you can use access control based on IP address (client address set). You configure any wireless clients that need access to resources on the internal network with VPN connections that connect to the ISA Server firewall/VPN Server. The basic setup looks like what we have below.

The WAP is connected to a switch or hub and the wireless clients connect to the WAP automatically because the SSID is broadcast and no WEP keys are required. You could even locate some server based resources on the WLAN LAT-based DMZ segment that wireless clients could access while still preventing them from accessing the internal network or the Internet. Its all done with ISA Server firewall policy and VPN.

The figure below shows what happens when you set the DMZ wireless clients up as VPN clients. The wireless VPN clients connect to the ISA/VPN Server in the same way that external network VPN clients connect to the server. Once the wireless VPN clients establish the VPN link, these clients have access not only to resources on the internal network, but also to resources on the Internet.

You typically want to give anonymous wireless client’s access to the Internet and not the internal network. You can accomplish this by using IPSec policies and/or RRAS packet filters. The goal of both RRAS packet filters and IPSec policies is to prevent communication between the WLAN network ID and the internal network ID(s).

The LAT-based DMZ allows WEP clients access to the Internet. The LAT-based DMZ doess not allow the wireless clients access to the internal network since the entire LAT-based DMZ concept depends on the fact that DMZ addresses cannot communicate with hosts on the internal network ID(s).

If you want to allow the LAT-based DMZ hosts access to the internal network and the Internet, there are two requirements:

I highly recommend you disallow split tunneling. Your anonymous WLAN segment has enough security issues without introducing them into your private, internal network by allowing split tunneling by your VPN clients.

In order to make this work, you need to do the following:

Actually, you don’t have to do it this way. For example, you can use Windows 2000 and four or five network interfaces if you like. I prefer to use Windows Server 2003 because it seems more stable and it’s definitely more secure. I’ve had zero problems running an ISA Server firewall on a Windows Server 2003 box, so I’ll continue to recommend it until I see something strong enough to drive me away from this recommendation.

Use the methods I describe over at http://www.isaserver.org/tutorials/installon2003.html to install the ISA Server firewall on the Windows Server 2003 machine. Make sure you install all the NICs on the server before you install ISA Server. While you can install additional NICs after the ISA Server is installed, you may run into problems depending on the roles the servers plays. If you install the ISA Server firewall as a firewall, and not a general purpose application, mail or Web server, you won’t have any problems addition NICs after installing the ISA Server.

The ISA Server firewall comes with a very nice VPN client connection Wizard that configures RRAS to allow incoming VPN connections. The Wizard does almost all the work for you, but you might need to tweak it a bit to support an addressing scheme that works for you. Check out my VPN server related articles over at www.isaserver.org/shinder for tips and tricks on how to configure the VPN server after the VPN Wizard is done. You’ll also benefit from going over to www.microsoft.com/vpn and checking out the White Papers on Windows Server 2003 VPN server and VPN gateway configurations.

The heart of the LAT-based DMZ concept is RRAS packet filtering and IPSec policies. ISA Server doesn’t manage connections or apply firewall policy to communications between LAT hosts. Since the WLAN DMZ segment is part of the LAT, the ISA Server firewall will not apply firewall policy. You will use RRAS packet filter and optionally, IPSec policies to control what traffic can move between the LAT segments. In this example we want to allow only VPN clients to connect to the Internal network, so the RRAS packet filters and IPSec policies will prevent all communications between the LAT-based DMZ and the internal network.

The final piece of the puzzle is configuring the VPN client connectoids on the Windows 2000 and Windows XP machines. You then configure these machines to be Web Proxy and Firewall clients after the connectoids are completed. This allows you to apply firewall policy to these VPN clients. Again, its important to force firewall policy on these VPN clients because the VPN client act like any other client on your internal network.

In this article we went over the basic VPN, DMZ, WLAN and access control design principles we’ll use to create our secure WLAN LAT-based DMZ segment. In the second and third parts of this article we’ll go over the step-by-step details of the configuration so that you can test the concept out in your own lab before rolling it out on your production network. See you next week with the details!