Feb 26, 2018
When a client sends an inquiry about broadband satellite services, BusinessCom representatives respond with a series of questions. Understanding what kind of company or organization the client is, the number of users, number of active VoIP lines, video requirements, and critical applications are essential to proposing the best solution for the client. One consideration on the list, is the question of whether the client is using a VPN or Virtual Private Network.
In the old days before the internet, companies used private circuits to connect their branch offices to the data center. Today, we have the internet, and enterprises use the internet to transport their traffic instead of leasing private circuits, which are more expensive. The internet, however is open and unsecured. A VPN allows an organization to encrypt and secure their inter-company communications as though they were on a private leased line, thus the “virtual” private network. However, for some VPNs, the latency or delay of traffic over satellite can create performance issues, so it’s important to understand whether there is VPN traffic early in the process, so the issues can be discussed.
The first thing to understand is the nature of the TCP transport protocol that is designed primarily to carry data in an error-free fashion. This protocol is used for web surfing, file transfers, email, or just about anything else that transports data, as opposed to voice or video which use a protocol called UDP. When a user sits at a workstation and sends or receives TCP (Transmission Control Protocol) traffic there is a background process going on between the workstation and the server where the content resides. Suppose a request has been made for a file on a server. The TCP protocol operating on the server sends a little data, then stops and waits for an “ACKnowledgment” from the remote receiver, confirming an error free transmission. Nothing is transmitted while it waits for this ACK. When it receives the ACK, it sends a larger chunk of data. With each successful ACKnowledgment that the data was received correctly the number of packets transmitted increases in an ongoing process as sender and receiver “learn” the characteristics of the link between them. This is why a user will sometimes see the transfer speed on a file transfer progress display steadily increase as a large file is received. This process is called TCP ‘slow-start’ and it provides a way for TCP to learn about the characteristics of the link it is traveling across.
In the current satellite environment based on GEO (Geosynchronous Earth Orbit) satellites, there is high latency that is not normally experienced on terrestrial circuits. Satellites are so far above the earth (over 22,000 miles) that it takes about 2/3 of a second for a satellite signal to make a round trip, compared with a handful of milliseconds over fiber to other locations on earth. TCP devices, such as PCs and servers, interpret this delay as congestion or a very slow circuit. It takes so long for the ACK response to come back, that the TCP sending device thinks the circuit is slow or congested and it will not transmit at the full capacity of the satellite link. Note that this limitation is on a ‘per session’ basis. Without tweaking TCP window sizes, most TCP traffic will max out at about 100 Kbps per session, regardless of the satellite link speed. A user could have a 4 Mbps circuit that was idle and the TCP download would max out around 100 Kbps, wasting the available bandwidth. Note that it is still possible to saturate a satellite link if there are many TCP sessions, but no individual session is able to take advantage of the link capacity regardless of whether bandwidth is available or not. In the old days of satellite communications, this meant very slow transmission speed. That has changed.
To address this issue, vendors provide TCP Acceleration, Spoofing or PEP (Performance Enhancing Proxy) software that intercepts the TCP control headers before they get transmitted over the satellite link, and responds to them locally. There are different degrees of sophistication for these services, but in general they allow the TCP session to take advantage of the full satellite link capacity. Now if the 4Mbps link is idle, a TCP download can use it all. Most shared broadband satellite solutions such as those provided by iDirect, have some sort of TCP Acceleration, Spoofing or PEP built into them. SCPC circuits that carry a lot of TCP traffic may use external accelerators, such as those provided by XipLink, though vendors have integrated TCP Acceleration into SCPC modems as well.
Note that UDP (User Datagram Protocol), the protocol used to transmit voice, video and other real-time traffic is not a guaranteed delivery protocol. It is a “spray and pray” protocol, sending data and not providing any acknowledgments or retransmissions if packets are lost or corrupted. Once a voice packet is lost or corrupted, it makes no sense to resend it; there may be some static or noise but the conversation continues without stopping to retransmit packets. Thus the UDP protocol will use the entire link capacity as available on a per-session basis.
The industry solved the problem of using TCP as a transport over satellite, so what is the issue with a VPN?
The VPN “problem” arises when PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), IPSec (IP Security) and similar VPN technologies are deployed, because these methods encapsulate the original TCP packet in a new packet that is UDP-like. IPSec, one of the most popular VPNs, encrypts the original packet. The problem here is that the TCP Acceleration, Spoofing or PEP process is unable to “see” the original TCP headers so as to respond to them locally, as it normally would. The satellite modem/router sees the UDP headers for the VPN packet but considers the contents of that packet to be data and it doesn’t look into the packet for the TCP control headers associated with the original packets. Thus the entire packet must be transported across the satellite link, get unwrapped, decrypted and then ACKnowledged by the receiver, with the ACK itself being encapsulated. The ACK is then sent back across the satellite link before any more traffic can be transmitted, and all the benefits of the acceleration/spoofing/PEP are disabled. Thus the VPN traffic is again limited to about 100 Kbps per session.
There are some workarounds to this issue, if indeed it is seen as a problem. Some network operators consider this “problem” to be a crude form of bandwidth management since it limits each customer’s TCP sessions. However IP traffic is generally intermittent and bursty, and if satellite link capacity is available, in most cases, it makes sense to use it, rather than waste it. In the real world, this problem is most associated with IPSec VPNS. Here are some suggestions and potential workarounds:
1. Place the IPSec VPN appliance at the teleport, rather than at the remote site. Most satellite links are inherently secure – at least as secure as Frame Relay, private leased line or MPLS circuits. Unless it is a government, military, or financial application that requires end-to-end encryption for enhanced security, there is very little chance that the customer’s data will be intercepted or interfered with as it travels across the satellite part of the link. This level of security will not be acceptable for all applications, however.
If the IT department agrees that the remote site traffic is reasonably secure over the satellite link, then the VPN appliance may be hosted at the teleport for a small fee, protecting the final leg of the trip across the Internet, back to the customer’s IT headquarters location. The Internet, after all is where the real security problems occur – so traffic is protected across the unsecured internet part of the virtual circuit. Placing VPN appliances in the teleport has the added advantage of simplifying and reducing VPN management tasks. Usually companies that have small VPN appliances at all their remote sites, require a great deal of operational support, or they do a poor job of keeping security policies updated on all the little VPN appliances. A single, more robust VPN appliance at the teleport can efficiently transport traffic from multiple remote terminals on the shared satellite service, back to the IT headquarters over a secure virtual circuit across the Internet. The IT techs may be more likely to keep the security policies updated and monitored on this device, rather than 50 small devices at remote sites.
2. Pre-accelerate the TCP traffic. There are devices such as those mentioned above from XipLink that sit between the LAN and the VPN appliance and provide TCP Acceleration before the TCP data is encapsulated and encrypted by the VPN appliance. This works very well for LAN based traffic at remote sites. These devices can also provide QoS (quality of service) prioritization, prior to the data being encrypted and/or encapsulated. Otherwise there is no way to prioritize specific traffic within a VPN tunnel. One can only prioritize the entire tunnel.
This option is attractive because it provides full end-to-end encryption from the site to the data center. Note that this option does not work in all cases. There is a problem when the PC has client IPSec VPN software such as Cisco VPN Client loaded on it. When the data leaves the PC it has already been encapsulated and/or encrypted and cannot be accelerated by an external appliance. This is often a problem for people who work at home, or on the road, using client based IPSec VPN software on their laptops. It works fine over cable or DSL, but over satellite services – even enterprise class services such as those offered by BusinessCom Networks, there is currently no way to pre-accelerate the traffic that comes from a workstation running IPSec client software.
3. Use SSL-VPNs.This newer and more flexible VPN technology encrypts the data, but leaves the TCP headers untouched so the acceleration technology continues to work properly. The session setup times may be slightly longer as SSL tends to be a “chatty” protocol, but once it is setup, the connection is able to use all the link capacity. BusinessCom’s Sentinel provides a low-cost platform for SSL-VPNs along with numerous other functions.
SSL-VPNs have additional advantages. In some cases, a full site is connected to the data center using an SSL-VPN tunnel, however this is not always necessary. SSL-VPN supports an appliance that sits at the IT headquarters, but with no client software or external VPN appliance required at the remote site. The solution uses the encryption that is already built into common PC browsers. Further, they limit access to specific applications on specific servers. A PPTP, L2TP or IPSec VPN gives a user access to the remote data center LAN, and from there they can go anywhere. An SSL-VPN may limit access to specific applications on specific servers, so security is more controlled. SSL-VPNs are also great for extranets, or business partners for whom the organization wants to provide limited access to specific resources. PC sharing applications such as PCAnywhere and most other Remote Access products use SSL for transport. SSL-VPNs will provide much better support for telecommuters who have broadband satellite access than IPSec.
4. Built-in encryption – Some solutions like iDirect offer 3DES and/or AES encryption across the satellite link. The additional delay due to encryption overhead is negligible. This encryption is only over the satellite link, however, and a VPN appliance must be placed in the teleport (see #1 above) for the final leg of the trip, or the customer must put a leased line or MPLS circuit from their data center to the teleport. Note that this does not provide complete end-to-end encryption, since the data is encrypted over the satellite link, but decrypted when it comes out of the hub, travels over a short piece of Ethernet cable ‘in the clear’ and then gets encrypted again for the final leg of the journey over the internet. For this application one must have a “secure” teleport. It does not provide full end-to-end encryption. If, however, the client has their own hub in their own data center; essentially their own small teleport, then this is a good solution to protect data end-to-end.
5. Other vendor solutions: Companies such as Xiplink and UDcast/OneAccess have combination VPN/pre-Acceleration and QoS solutions in one package. They accelerate TCP in both directions, while providing end-to-end IPSec encryption.
6. Live with it. 100 Kbps isn’t that bad, and although the sessions will be sluggish and have a slower ramp-up speed, it may be perfectly acceptable for some users if it’s only used for occasional access to headquarters to retrieve and send emails or grab product/pricing information off the company intranet. The other Internet traffic will operate at full speed, since it won’t be in a VPN.
If a BusinessCom satellite sales rep asks whether you use a VPN, it’s because they want to make sure to set the correct expectations with regard to performance, and to discuss the available work-around options to provide maximum throughput and performance. It’s quite disconcerting to purchase a large data circuit and then discover that your data is stuck in the slow lane. BusinessCom Networks will help ensure that doesn’t happen.
