Uplevel’s Cloud-hosted VPNs

Uplevel Systems offers VPNs, like just about every other security services vendor out there. However, a substantial difference between our VPNs and traditional VPN services is that they are cloud-hosted. What does this mean to you, the MSP? We’re glad you asked!

How The ISP Can Give You A Bad-VPN Day

Traditional VPN services in the SMB world, whether site-to-site (S2S) connecting offices or remote access connecting remote workers to offices, entail establishing connections directly from the remote VPN client or terminator to the public IP of the main office. A typical S2S IPsec VPN, for example, would open a connection on port 500 (or 4500) to the main office public IP. To complete the connection, a ‘hole’ is punched in the main office firewall and traffic is forwarded to the VPN terminator on the LAN or inside the firewall. A few back-and-forth IKE exchanges, some inner tunnel setup, and bingo! the remote device is connected securely to the main office LAN.

This is all very nice in theory, but requires two essential things:

• Hole-punching: The remote device needs to get to the VPN terminator in the main office. For this to happen, ‘holes’ have to be punched in the firewall. If there are multiple firewalls in the path - say, your customer is a tenant of someone else - then ‘holes’ need to be punched all the firewalls in the path. But … what happens if you don’t own or control one or both of those firewalls? Well, then, you as the MSP get to negotiate with whoever controls those firewalls to request, very politely, that they punch said holes. And if you’re dealing with an ISP … enough said.
• Static IP: The remote device has to talk to the main office firewall directly. If the public IP of the main office changes - say, there’s been a power outage and the ISP handed it a new DHCP IP - the remote device needs to be reprogrammed with the new public IP. Until then the VPN is down and your customer is unhappy.

There’s a third factor in all of this - the Saturday night call from an irate customer complaining that he can’t connect to the office, and he really needs to get this important work done, and it is all your fault. Why? Possibly because the ISP chose that Saturday to push a firmware update to their modem, which not only took out the static IP, but also closed the IPsec port for added benefit? Now you’re on the phone with Tier 1 support at 8 PM explaining what an IPsec port is. Probably not your idea of a relaxing weekend. (And yes, this happens on a regular basis!)

The Uplevel Cloud-hosted VPN

Uplevel Systems has a somewhat different approach to this VPN conundrum that eliminates the static IP (or even a public IP) and all the hole-punching.

When we stand up a customer setup, we also assign a permanent, fixed public IP in our cloud, and hook it to a VPN hub. Uplevel gateways and remote access VPN clients all build SSL tunnels to this cloud-hosted public IP, not the public IP of the customer office. (The ISP can do many things, but they can’t mess with our public IPs.) The VPN hub then acts as a very fast router, switching traffic between the gateways as well as between the remote access clients and the gateways.

The benefits of doing it this way:

• The public IP never changes. The ISP can do what they want to the customer modem, and - you … don’t … care.
• No hole punching is required. Period. No conversations with Tier 1 support.
• The gateways build SSL tunnels (on port 443) out to our public IP, via the Internet. Nothing calls in. ISPs are known to block all manner of ports in the name of security, but an ISP that blocks port 443 will be immediately flooded with calls from the entire customer base complaining that the Internet doesn’t work! No chance of being blocked by an overzealous firewall in the modem.
• Adding more offices? Moving an office to a different state? No problem! Same public IP. You never have to get on the customer’s laptop and mess with the VPN profile.

No need to pay for a static IP. No need for port forwarding. We call this “ISP independence”. You call it “less headaches”. You’re welcome.

The (Small) Catch

What’s the catch, you ask? Well … the VPN connection becomes a 2-hop link. The first hop is to the VPN hub in our cloud. The second hop is to the gateway at the customer office. There’s an increase in latency.

For maybe 90% of our customers, the latency increase is not noticeable. We help things along by locating the data center closest to the customer zip code and firing up a dedicated VPN hub for each customer at that data center. In most cases the customer is accessing files or doing RDP sessions, and neither of these is affected by the extra hop. Nobody notices.

However, there are some applications that can’t tolerate the extra latency. For example, editing large files over the Internet can be slower with the extra hop. Databases are another case. (We strongly discourage directly accessing databases over the Internet, hops or no hops, because of the high risk of database corruption if a connection breaks. But there are customers that do it anyway.) Database transactions are highly impacted by latency.

Enter the Direct Remote Access VPN option.

Direct Remote Access Mode

To address those cases where we need VPN access but the extra latency can’t be tolerated, we introduced a special mode called “direct remote access”. It applies to both S2S and remote access VPNs.

For direct remote access to work, you need a public IP at all the applicable offices. (You still don’t need to pay for a static IP, but the ISP modem has to be put into bridge mode.) If all the offices have a public IP, you can enable direct remote access. The cloud then swings into action, determines all the public IPs, and auto-generates VPN configurations for each of the gateways. These are downloaded to the gateways, and a full mesh of site-to-site tunnels is brought up.

What if the ISP decides to change the public IP? The cloud constantly monitors this situation, and generates a new VPN configuration (for all the gateways) and updates the gateways, then instructs them to rebuild the tunnels. A short time later, the VPN is back to live action. No action required on your part!

This works for laptop VPN access, too. You designate a customer office as the “primary” to which customer laptops need to connect, and then the cloud creates a VPN terminator configuration for that location. Customer laptops then connect directly to the gateway at the primary office.  To defend against the ISP reassigning the public ip of the office, you have the option of assigning a DDNS name to that gateway - free from Uplevel - and then entering the DDNS name rather than the explicit IP into your VPN clients. Did we mention “ISP Independence”?

Wrap-up

All of our partners are interested in reducing headaches. (If you are not, let us know, we’ll plan on buying stock in aspirin vendors ..) Uplevel cloud hosted VPNs are one of the many headache-reducing features we offer. Call us if you want to know more!

Looking to protect your clients against potential threats? Look no further than Uplevel Systems! We offer all-encompassing IT Infrastructure solutions with a keen focus on security, performance, and scalability. As you venture into the world of cloud-based VPN, partner with Uplevel Systems to experience cutting-edge IT infrastructure.

About Uplevel Systems

Uplevel Systems is a small business IT infrastructure provider that sells exclusively through managed service providers. Uplevel’s subscription offering is the most popular with SMBs, but some prefer Uplevel’s new equipment purchase program and use a CapEx model.