There are a number of ways to categorize VPNs, but the three main design varieties are network-to-network, host-to-network, and host-to- host.

Network-to-Network

Also referred to as site-to-site, this term is often used to describe a VPN tunnel between two geographically separate private networks. This type of VPN is commonly used when the LANs have to be connected across a public network so that users on both networks can access resources located on the other LAN, as if they were located inside their home network. A major advantage is that in this configuration both networks are adjacent and the background operation of VPN gateways is transparent to the end users. In such a scenario, tunneling is also important, as private networks commonly use RFC 1918, reserved range addressing that is not "routable" through the Internet. Such traffic has to be encapsulated into a tunnel for successful interconnectivity. A common example of such a design application can be the connection of two offices of the same organization over a point-to-point wireless link. Even though the traffic in transit does not leave the internal infrastructure of an organization, the wireless part of the journey has to be treated with the utmost care, as if the traffic was routed through the public network. You have seen how easy it can be to bypass WEP, and even TKIP can be vulnerable, so we strongly encourage you to use additional layers of encryption wherever possible when using 802.11 nets.

Host-to-Network

The host-to-network scenario occurs when remote users connect to the corporate network over the Internet. The mobile client first establishes Internet connectivity and then initiates a request for an encrypted tunnel establishment with the corporate VPN gateway. Once the authentication is done, the tunnel is established over a public network and the client becomes just another machine on the internal network. The growing practice of employees working from home is stimulating an increase in this type of VPN connectivity. As opposed to the network-to-network situation, where the number of VPN participants is limited and is more or less predictable, a host-to-network VPN can easily grow beyond the controllable boundaries. Therefore, system administrators must prepare a scalable mechanism for client authentication and a key management system.

With respect to wireless point-to-multipoint links, second layer security might be insufficient to protect such networks or it might encounter serious compatibility and interoperability problems when running public hot spots or using legacy hardware. You should use scalable strong encryption, authentication, and user accounting for any organization that runs a wireless network in the office for its employees' laptops and other wireless devices. This might involve setting a central VPN concentrator with access control and accounting capability over the VPN tunnels ending in it. This could be a viable alternative to deploying a RADIUS server, user database, and 802.1x infrastructure. The host-to-network VPN topology assumes that wireless hosts connected via the VPN can access different networks, such as the Internet, through the VPN concentrator, but cannot communicate with other wireless hosts on the same WLAN.

Host-to-Host

Host-to-host is probably the least common scenario out of the three. It involves only two hosts participating in both encrypted and unencrypted communication. In such a configuration the tunnel is established between the two hosts and all the communications between them are encapsulated inside the VPN. The application of such networks is not common, but a suitable example might be a remote backup storage server located in a geographically distant location. Both hosts are connected to the Internet and the data from the central server is mirrored at the backup slave. In a wireless world, simple host-to-host VPNs can be employed to protect ad hoc WLANs.

Star

The networking world does limit the number of participants in the VPN, so having discussed the simple host and network topologies, let's examine more complex cases. Note that the variety of VPN topology designs closely mirrors the physical design of nonvirtual networks.

Star is the most common of all VPN topologies. You have a VPN concentrator that has an established tunnel to the remote client. For one of the hosts to communicate with the other host, the data must pass from remote host A to the VPN concentrator and then from the VPN concentrator to remote host B. Bear in mind that the scalability of such a network is generally limited by the throughput of the VPN concentrator. The concentrator has to be able to support a sufficient number of simultaneous connections. Also, the overall performance of such a network would be limited by the processing power of the concentrator, which is halved for each connection between two hosts, as the data will have to be decrypted on receipt and then encrypted again prior to transmission. The ease of centralized configuration, maintenance, access control, and accounting in this scenario is complicated by the presence of a single point of failure. Thus, if the VPN concentrator is down, no more communication between the nodes is possible. The star topology is applicable for point-to-multipoint wireless links, but it is less secure than the host-to-network topology because wireless hosts can communicate with each other (via the concentrator).

Mesh

In the mesh topology, each node is directly connected by a tunnel to another node on the network, thus creating a "wireframe" of interconnections. Such a topology eliminates the drawbacks of the star topology, but it has a great disadvantage in the huge increase in maintenance time and difficulties in adding new nodes to the network. Note that the end clients now need to be more powerful machines as the number of simultaneous tunnels each node needs to handle will be greater than one. Imagine that you have to deploy a secure wireless ad hoc network, maybe as part of a massive wireless distribution system (WDS) project. The mesh topology VPN is, perhaps, the solution you are looking for: You cannot implement an efficient 802.1x-based security solution on such a network lacking the Authenticator device (access point). Thus, both user authentication and key rotation, as defined by the 802.11i standard, may not work properly.