This ADSL VPN primer explains what an Asymmetic Digital Subscriber Line (ADSL) IP VPN is and introduces IT professionals...
to ADSL VPN security concepts, services and backup.
Alternatives to MPLS IP VPNs
Every new service and technology has its lifecycle in the IT data and telecommunications market. MPLS networks have managed to gain a great share of the market, rapidly replacing the expensive leased lines and frame relay links between customer sites.
While the costs between MPLS and older WAN connectivity options are impressive, companies are still struggling to keep the costs down by migrating to MPLS and cutting down their link speeds to the bare minimum.
While MPLS has been enjoying its popularity and continuously increasing its share of the market, there has been a new player around that looks very promising and is here to upset the MPLS service providers for good. Let me introduce you to ADSL IP VPNs—referred to from this point as ADSL VPNs—in this ADSL VPN primer.
What are ADSL VPNs?
Today, every company has a dedicated ADSL Internet connection, providing Internet services to the internal network. ADSL has been around for more than a decade; however, it has been these past few years that its really taken off with the introduction of new ADSL technologies, such as like ADSL2 and HDSL, that allow super high download speeds of up to 24 Mbps and upload speeds exceeding 2 Mbps.
As ADSL speeds increased, the market looked at ADSL technologies in a different light. Many IT professionals began asking, if I can download and upload at such high speeds, why not create an encrypted tunnel between two endpoints and get rid of my MPLS WAN network? And this is how the success story of ADSL VPNs started. High-speed ADSL connections became a great alternative to existing MPLS networks.
Essentially, an ADSL VPN tunnel is an encrypted IPsec tunnel between two ADSL endpoints that are connected directly to the Internet. Network administrators and engineers who are desperately trying to find cheaper communications solutions have found solid ground and great acceptance in ADSL VPNs.
The great part about ADSL VPNs is that the ISP is almost never involved in the process of creating them, making them a fast and easy choice. With traditional WAN connectivity methods controlled by the service providers, engineers often end up being extremely frustrated during WAN network failures. This is because they can’t do anything about network failures since everything is controlled by the ISP and service providers have policies that prevent enterprises from accessing the provider’s end equipment located at the enterprise premises due to security and quality assurance purposes.
This "protective policy" of service providers has also contributed to the ground-gaining technology of ADSL VPNs. Engineers are able to configure their endpoint equipment in any way they like, create their encrypted tunnels and control them freely without any restrictions.
The diagram below is an illustration of a typical IPsec encrypted tunnel created between two endpoints that connect to the Internet via ADSL, our ADSL VPN:
Enlarge ADSL VPN diagram.
Each endpoint has a static IP address assigned by its Internet provider and a network engineer has configured both ends to form the IPsec VPN tunnel, connecting both sites together and allowing the secure exchange of data between them.
ADSL VPN security
We cannot argue about the importance of security and encryption when it comes to connections made over the Internet. Exposing the network to such a public threat is a big and very important matter. Taking the necessary precautions should be part of every engineer’s philosophy.
Research and tests by vendors such as Cisco Systems and other independent organizations have proven that when properly implemented, the level of security provided by an ADSL VPN is equally comparable to that of MPLS IP VPN encryption. This of course should not surprise any experienced network engineer or IT manager.
The fact is that both solutions, MPLS IP VPN and ADSL IP VPN, use the same protocols and implementation of IPsec in order to achieve the highly-encrypted VPN tunnel. With IPsec, all data is encrypted using Encapsulating Security Payload (ESP), providing confidentiality. Right after that, the ESP client—router or firewall—signs the newly-generated ESP header in order to prevent tampering by others.
This process is illustrated in the diagram below, courtesy of www.Firewall.cx. The numbers in the boxes represent the length in bits for each field analyzed:
Enlarge IPsec encryption process diagram.
More information on IPsec and its encryption process is available on http://www.firewall.cx/IPsec.php.
Perhaps the most important part during an ADSL VPN setup is the correct configuration of the VPN IPsec tunnels, which is usually implemented on a Cisco router or firewall.
Once the tunnel encryption is complete and the ADSL VPN tunnel is active, it’s a great idea to lock down the routers and firewalls. Any unauthorized person obtaining access to this equipment is a major threat not only to the devices alone, but also to the local and remote networks he or she connects to via VPN; all precautions must be taken into consideration.
ADSL VPN services
As stated at the beginning of this ADSL VPN primer, ADSL VPN services are based on normal ADSL Internet connections with the addition of an IPsec tunnel between two endpoints. The encryption used to safely connect the endpoints produces a small overhead that slightly and practically decreases the available data payload. The decrease in data payload rarely produces problems and allows us to transport pretty much any type of application across the VPN WAN network.
To provide a few examples of the ADSL services that companies around the globe are running over these low-cost VPN connections, check out this short list:
- Terminal Services: Remote teleworkers use terminal services to connect to a central server (terminal server) located at the headquarters. Taking advantage of the low-bandwidth requirements, Terminal Services and similar solutions (like Citrix Metaframe) offer an impressive alternative for centralized processing and control, no matter how far your teleworkers are.
- Voice over IP (VoIP): Providing voice connectivity between sites is extremely important. Running VoIP services is possible, even over ADSL links. Quality of Service (QoS) mechanisms take care of the pre-classification of packets before they enter the encrypted VPN tunnel, to ensure priority is given to the delay-sensitive VoIP packets. Connecting remote workers and sites from all over the world is no longer complicated and doesn’t necessarily need to involve the service provider. Using appropriate voice codecs such as G.729 allows the compression of voice streams from 85 Kbps to around 22 Kbps, saving valuable bandwidth. Combining VoIP codecs and QoS is ideal for ADSL VPN tunnels.
- Site-to-site backup: Many administrators utilize the ADSL VPN during non-working hours to run their daily backup, transferring their data from remote sites to the headquarters. Using specialized backup tools like Hewlett Packard’s Data Protector, they avoid copying full files and only copy the differences within them, making the whole backup service a much less bandwidth-consuming process.
- Email services: Users at remote sites are able to retrieve and send emails from the company’s central mail server located at the headquarters. Using carefully selected connectivity methods such as Webmail or IMAP, an end user’s email experience can be well-maintained without difficulty.
- Remote monitoring: Installing a few IP cameras or security systems over ADSL VPN connections gives companies a cheap and secure way to remotely monitor an office, shop or warehouse. ADSL VPNs can easily transmit this type of data.
It is evident that there is really no limit as to what you can do over an ADSL VPN tunnel. The key to getting everything to work correctly is to properly configure your endpoints.
ADSL VPN backup
So, you might ask yourself: What happens if my ADSL line fails and I lose VPN connectivity with my remote sites?
It’s actually quite a good question.
Since your ISP doesn’t provide any guarantee for your ADSL connection—don’t forget, it’s a normal Internet connection—you are left alone to figure it out. The great news here is that there are solutions. If your ADSL line is based on a PSTN (ANNEX A) type line, then things get pretty messy (upgrade it to an ISDN line!), but for ADSL lines based on ISDN (ANNEX B), you can use the ISDN line to perform an ISDN backup call to your ISP and establish up to a 128 Kbps link to your ISP. While 128 Kbps might not sound all that great, it is enough to serve at least three to four terminal users, basic email services and one G.729 voice channel—not bad for a backup solution.
Of course, we must keep in mind that backup links are not used to replace primary links, but to provide the bare minimum bandwidth to allow your remote sites to function. When backup links are initiated, most non-critical services are dropped and only core services are available. Again, this is purely a router/firewall configuration issue, so the responsibility falls back on the engineer once again.
As a rule of thumb, if you plan on using ADSL VPN, make sure it’s on an ISDN line so you can use the backup alternative during ADSL service failures. The best and simplest way to achieve WAN redundancy on Cisco devices is to use Reliable Static backup routes with IP SLA tracking. You can view a full example of IP SLA on Firewall.cx’s IP SLA page.
In short, IP SLAs allow the continuous monitoring of a host on the Internet. With IP SLA, you monitor an IP host (IP address) via a specific link (like the ADSL line). This IP address is constantly tracked by your router. If for some reason the router loses connectivity with the monitored IP address, it assumes the link (the ADSL line) via which it monitors the host, is down, and automatically initiates the ISDN backup.
During the ISDN backup period, the router will continue to monitor the IP host via the configured link, and once the remote host’s IP address starts to respond back to the router’s ICMP echo requests, the router will happily terminate the ISDN backup and reinstate the default route, which in our case is the ATM dialer interface.
In practice, ISDN backup does work—you just need to configure it properly. And again, it’s all up to the engineer to get it right.
In cases where there are multiple VPN links on one ADSL VPN, an ISDN backup interface might not be adequate. In such cases, you can examine the possibility of having another ADSL standby by a different provider, so you can use that to temporarily have your remote sites connect to it. This of course is a slightly more complicated scenario and requires experienced engineers.