![]()
Section 1
|
|
"Virtual Private Network" You may
also find VPN referenced in some European telco offerings to sell/lease
private frame relay clouds to connect remote operations.
As opposed to non dial-up VPN's that are formed using firewall to firewall
tunneling, a VPDN is usually created by tunneling software that
bypasses firewalls to allow remote clients onto the corporate LAN.
In other words, the entire geographically dispersed network appears as a
single firewall protected network, while it actually encompasses encrypted
links over untrusted networks. A VNP uses firewalls, encryption, and
standard administration, control, and security policies to allow a dispersed
organization to extend its network to multiple locations over
an untrusted network, such as the Internet. In a VNP, all network
services may be allowed between the trusted networks. By virtue of the
protection provided by the Virtual Network Perimeter even
"insecure" network services are not vulnerable while on the Internet. A VNP
may contain a Virtual Private Network.
![]()
Using a product like InJoy on an OS/2 workstation allows for the setup of a highly automated networked client. While this is a powerful configuration, it is not the functional equivalent to a full time network. Dial-on-demand PPP has two functional shortcomings when compared with a permanent connection. First, demand at the PPP workstation will cause a connection, but demand from a remote workstation trying to connect to the PPP workstation will not cause a connection. This really amounts to one way Dial-On-Demand. The reality of this situation is that the PPP workstation will only properly function as a client of remote systems and will not be useful as a server. The second and more important limitation is the dynamic nature of IP addresses in most PPP implementations. Dynamic address assignment is one of the most powerful features of the PPP protocol, allowing a small pool of precious IP addresses to be shared by a large number of clients. Since IP addresses are part of TCP socket definitions, sockets do not persist through an IP address change. This means that any TCP socket, which is bound to the PPP interface and open when a PPP connection times out, will not survive a reconnection. This can be demonstrated by opening a telnet connection and then dropping and reconnecting a PPP session. The telnet session will not survive. This problem has the greatest impact on applications such as database replication which would not experience an IP address change in normal operation. To make matters worse, there is no mechanism which will allow an application to know that the remote system has 'idled down' its connection. When a server has an open socket to a remote system which has disconnected, the server will continue to send information to the remote address in the form of TCP keep-alive packets or application data. The best case in this situation would be if no system existed at this address. Often, another system does exist at this address. Another user connected to the same PPP connection pool could be served the address which was formerly owned by someone connected to your server. This server is now trying to send data to an address which it thinks is still one of its clients. The result is that the server is unknowingly flooding an unknown users PPP connection with what could be valuable served information. This is a security concern for the server involved and an annoyance to the unknown client involved.
![]()
While it might initially seem complex, it is not particularly complex to pick up a packet at one point and drop it off at another point. An IP through IP tunnel could do this using a simple TCP socket which would carry packets as payload in other packets. The concept of tunneling allows us to use an entire network as a connection. This provides equivalent connectivity to both local and remote workstations, but it does not provide equivalent security. All of the remote workstation's traffic travels through what is most likely a public space. Since all traffic is transported through one pipe, most tunnel implementations take advantage of this architecture by securing the pipe. That is, packets are encrypted for transport through the pipe. This provides a secure connection to a remote system, even when using an insecure network such as the Internet as a connection mechanism. A node on a VPN can and should have an address which is not part of the connecting network's address space. This is possible because packets from a VPN node are merely data when traveling through the tunnel network. It would be wise to provide a VPN node with a static IP address, or at least a DHCP address which would be static during the life of the current boot. A smart tunnel can survive the address changes of a typical PPP service. A secure tunnel can provide a secure connection to a remote workstation, even when the connection is tunneled through the Internet. By taking advantage of the static nature of VPN addresses, a tunnel system can provide full two way Dial-On-Demand. The F/X Tunnel has all of these features, providing LAN levels of connectivity to remote systems. In other words, A VPN allows a private network to span between the home gateway and the remote client, no matter where the remote resource dials into the Net. Imagine a large organization with remotely located offices or a mobile sales force. Those resources need to connect to the home LAN for a wide variety of reasons. Normally that is done with leased lines for remote office LANs and via direct, long distance dialing for mobile personnel. The Internet offers the possibility to connect all the nodes together, with neither leased lines nor direct calls. However, the Internet does present a few obstacles. If the organization simply provides off-site personnel a local dial-up Internet account, the ISP's dynamic IP addressing sends corporate information security right down the drain if it allows access to the back-end applications. Additionally, ever changing IP addresses makes it literally impossible for the home office to initiate a connection with remote sites. And finally, most of the data passed back and forth is freely available for intercept and exploitation by competitors.
Tunnel/2 solves all those problems with one Tunnel Master at the corporate LAN, one Tunnel Slave at the remote office LAN and another with each mobile PC. In practice, Tunnel Slaves connect to Tunnel Master on demand and traffic destined for the Master LAN is:
The Tunnel Master will get a response back from the corporate LAN and it is:
The great thing about this Tunnel Setup, is that the TCP/IP traffic is actually moved to another computer, and doing so, makes the remote seem on-site. This integration makes it such much easier to administrate the WAN in any regard.
To apply Tunnel/2 in our example scenario (figure1), here is what needs to be done:
The VPN can be viewed as a virtual segment. It will need an address pool. These addresses do not have to be real Internet addresses. Unassigned address space such as 10.0.0.0 can be used in this case. Notice how all workstations now have static IP addresses. The RED ones are imaginary ones used at the corporate LAN, the BLUE ones are the static interfaces defined for the Tunnel Network. The GREEN addresses are the dynamically assigned IP addresses from the ISP. The GREEN addresses will change at each connect of the Internet dialer, but so can any address in between the Slave and Master (without hurting the concept).
Static IP Numbers - Really?
Packets are then sent on a normal socket connection to the Tunnel Master (still with the 10.2.2.200 as the source IP address). On the network of the Tunnel Master the packet is forwarded to the destination IP address in question (found in the IP packet itself). Prior to sending out the packet on the Master LAN, the Master will add a PROXY ARP entry in the TCP/IP stack. A PROXY ARP entry is a way of telling that the IP address of the remote Slave is accessible via the Master computer. This will automatically update the company lan/router with the information it needs to route packets to and from the tunnel net. This could be accomplished with with static routing as well. Lets take a closer look at the TCP/IP stack of the Tunnel Master and The Tunnel Slave to see how this is accomplished:
The IP numbers need to be static for several reasons, but the main reason is that you can keep your applications open across Internet dial-up connections. Applications won't even know what happened and with Dial-On-Demand, the network is all transparent to the user, just the way it should be!! The routing may seem scary at first, but as all great inventions, it is in fact very simple. If you need the Tunnel and feel overpowered by the configuration then JUST ASK F/X. |