free vpn usa

Wednesday, 14 March 2012

Interoperability and Mixed versus Homogenous Device Deployments

Although IPSec is a documented standard, the Request for Comments (RFCs) that document it has left room for

interpretation. In addition, Internet drafts such as IKE mode-conﬁguration and vendor-proprietary features increase the

likelihood of interoperability challenges. For instance, there is no standard mechanism for IPSec to determine tunnel up/down

state and remote peer reachability. For these reasons, you should check with vendors of both products for interoperability

information and their participation in interoperability bake-offs. Typically a few minor changes to conﬁgurations-and

sometimes-code-are necessary to facilitate interoperability in a reliable fashion. Realize, though, that these changes may

affect the security stance of the device, so be aware of the implications of these changes. Also, in order to ensure

interoperability between products from a single vendor, it is a best practice to use the same code base across all platforms.

This scenario will decrease the likelihood of any interoperability issues with products made by the same vendor as changes

are made over time to adhere to the standards and increase interoperability with other vendors.

Issues in addition to interoperability arise in environments where different device types are deployed to build a VPN. These

issues usually arise because of interaction between the VPN and other features that complement its operation. For instance,

consider the authentication, authorization, and accounting (AAA) protocol used to manage remote users and administrators.

The granularity of support for this protocol, say Terminal Access Controller Access Control System Plus (TACACS+) or

Remote Access Dial-In User Service (RADIUS), may differ among the device types. This difference can complicate matters if

your user database does not support one of these mechanisms across all the device types deployed. The mechanisms used for

IPSec high-availability and CA support differs for some routers, ﬁrewalls, concentrators, and remote-access clients. Finally,

consider the additional resources required to train administrators on how to conﬁgure, manage, monitor, and troubleshoot

multiple device types.

Monday, 12 March 2012

used toillustrate an adaptive VPN

Source NAT. So far, in the cases we have used toillustrate an adaptive VPN, the selection of an appropriate tunnel has been based only on subnet policyrules, as it commonly is. However, an applicationbased adaptive VPN (as illustrated in Figure 6) alsoallows tunnel selection to be based on the destinationTCP port number. Unfortunately, routing tables specify routes by means of destination IP addresses and donot provide the ﬂexibility to specify them by means ofa combination of destination IP addresses and TCP portnumbers. Let us consider again the conﬁguration inFigure 10 and assume that now it is required thatpackets destined to the subnet 192.168.5.0/24 be sentthrough the enterprise tunnel if the destination TCPport number is 25 (i.e., e-mail) and through thenetwork tunnel if the destination TCP port number is80 (i.e., the Web). This means that the list of hostsbehind both the enterprise and network tunnelsshown in Figure 10 must be modiﬁed to include the subnet 192.168.5.0/24. The local presence IP addressesfor these two tunnels are 192.168.5.10 and192.168.1.10, respectively. But if a packet is to be sentto a speciﬁc IP address in the 192.168.5.0/24 subnet,there is no way to specify in the routing table that thegateway should be at IP address 192.168.5.10 if thepacket is to be sent to destination port 25 and at IPaddress 192.168.1.10 if the packet is to be sent toport 80.