How to overcome
The IoT Enterprise VPN Challenge
Today, IoT Communications Service Providers (IoT CSPs) are challenged to offer a secure and flexible way for enterprise customers to connect end-to-end from a device to their IoT back-end services.
Traditionally, IoT CSPs create a unique APN (Access Point Name) for each enterprise IoT customer on the mobile core and map it to a individual Enterprise Virtual Private Network (VPN). With this action, they have created a so-called Private APN for the customer.
The device itself does not need to have VPN support. The integrity of the mobile network and the Enterprise VPN’s IPSec tunnel between the mobile core and the enterprise protects the traffic.
Whether the IoT CSP is relying on its mobile network core or has outsourced the IoT core operations, the traditional APN method brings two main problems:
1. Cost, time, and scale
Deploying separate Private APNs for each customer has proven costly. It can take weeks for the IoT CSP engineer and the customer to set up the Enterprise VPN. As a result, IoT CSPs have limited this to an exclusive service for larger customers. Private APNs are also costly to maintain, both for the IoT CSP and its customers. When customers, for instance, want to move a range of devices to another APN, each device needs to be re-configured with the new APN.
With Enea IoT CCS‘s Multitenancy Private APN functionality, enterprises can set up their IoT Enterprise VPNs in minutes rather than weeks without interacting with the IoT CSP.
The IoT CSP extends a single APN to the IoT CCS in the cloud, which in turn separates the traffic to the correct Enterprise VPN.
Enterprise customers can create VPNs through the IoT CSP’s customer self-service portal. An API in IoT CCS enables this automation towards the next-generation firewall included in the IoT CCS service. The firewall has the dual function of terminating the VPN and protecting the traffic with unique settings for each customer.
As the APN name remains the same, the enterprise customer can move devices to another Enterprise VPN without reconfiguring them. It is just a matter of changing the routing in IoT CCS.
2. Lack of global IoT services
A truly global IoT service will require localization of eSIMs. Above all, in countries where permanent roaming is unavailable due to commercial or legal reasons. The traditional APN method on the home mobile core will not work in this scenario. The control will be lost to the local operator. As a result, the devices cannot keep IP addresses and security policies. Delivering a unified global connectivity service becomes mission impossible.
Using the same single APN name, IoT CSPs can elegantly solve this problem. They can take control of the traffic by asking their international mobile operator partners to route all traffic on that APN name to Enea IoT CCS. With IoT CCS, IoT CSPs can offer their customers a global, secure SD-WAN functionality rather than just a private APN. The IoT CSP will avoid violating local regulations regarding permanent roaming.
Philipp Rimli, Product Manager Swisscom.Delivering a private APN with an enterprise VPN is normally a tedious process for both the service provider and their enterprise customers, which can take weeks to complete.
With Enea IoT CCS, we can automate the delivery of VPNs for private APNs through a customer self-service portal.
IoT CCS Multitenancy Private APN
Automating setup up of Enterprise VPNs
We call this functionality of the Enea IoT Connectivity Control Service (IoT CCS) Multitenancy Private APN. Private, because we use one or more Enterprise VPNs between IoT CCS and the enterprise network. Multitenancy, because the IoT CSP only needs to extend one APN to IoT CCS to serve all customers. Furthermore, the IoT CSP’s IoT customers can also set up VPNs to send traffic to their partners. They get a secure SD-WAN rather than a private APN.
From the IoT CSP’s perspective, the process of setting up a ‘private APN’ is completely automated. The enterprise customers handle their own Enterprise VPN setup through a customer self-service enabled by the IoT CCS API.
The IoT CSP sends the IoT traffic to IoT CCS through a secure IPsec tunnel. The IoT CCS then routes the traffic to multiple customers through individual secure Enterprise VPNs. The IoT CCS policy-based IP assignment is one of the keys to this magic. Visit our IoT CCS overview page to learn more about this.
Since IoT CCS is aware of which IP addresses belong to which enterprise customers, we can send all their traffic to the stateful firewall included in the IoT CCS service. Here, they can set their own firewall and routing definitions. Enterprise customers can block traffic, send traffic to their Enterprise VPNs, or send traffic directly to the Internet. The firewall protects all traffic.
A standard Gi/SGi/N6 signaling interface enables IoT CCS to act as the “mobile core” for IoT.
You are welcome to contact us to discuss how Enea IoT CCS can help you.
