VPN for mobile devices at the network level
There is still surprisingly little material in Runet about such an old and simple, but convenient, safe and especially relevant in connection with the development of the Internet of things technologies, such as mobile VPN (virtual private network). In this article I will describe how and why you can configure access to your private network to any device with a SIM card without the need to configure specialized software on it.
To begin with, I will answer the question “why?”. VPN as a technology is used to solve a variety of network problems, united by a common feature - the isolated transfer of data between two devices through a large number of intermediate nodes. Based on this, more complex solutions are already being built and the very different tasks are being solved. In the usual case, which is usual for everyone, a fixed-line operator network is used to build a VPN (there is great material for those who wish ) or many different network protocols (GRE, IPSec, L2TP and others - the same author about it) and the software products that work with them (Cisco AnyConnect, OpenVPN, TOR - you yourself know), but their use on a specific terminal device immediately puts forward a number of requirements for it, the failure of which leads to certain restrictions.
The first serious limitation is that the device must be able to work with at least one of these protocols at the hardware and software levels. This is most often determined by software that is easy to find for a laptop or smartphone, but there are cases when the task is faced with a device that is too simple from a hardware point of view, or its software has limitations: the water meter wants to use a VPN to transmit its unfortunate byte of readings once a month no less than you want to use a VPN to edit your LinkedIn profile.
Another important limitation is the need for customization. It works both for “stupid” devices from the first paragraph, and for classic smartphones and computers for which the previous restriction is unknown. And if with the former everything is relatively simple and depends on the amount of time spent on the setup, then with the latter there are options. Often, organizations use VPNs for security purposes to protect the service terminal device from accessing the public network without proper corporate protection or from transferring service data through public channels. End users, however, may for some reason disconnect or forget to enable VPN, as a result of which many of the company's security systems may be left behind.
Both of these restrictions can be easily removed if access to the VPN is provided at the network level. In the case of mobile communications, this can be implemented using the "mobile VPN". A device of any complexity capable of transmitting data will transmit it to the correct network. It doesn’t matter what settings are made on the device, if the network is properly configured, it will in any case transfer them to where you want, and nowhere else.
And as a nice bonus, the device will receive an address from the internal network, configured remotely, and access to it will be possible to get only from within this network (or physically). For a certain class of devices, this is very important.
It would seem that VPN is a classic service of all telecom operators for the B2B segment, and why, then, focus on this? The thing is how the data network is arranged for devices connected via GPRS, HSPA, LTE or other mobile communication technology. There are no vlan familiar to all network administrators, there are no switches, there are not even routers in their usual meaning. But there is a radio access network (RAN) and a packet core (PS Core).
A simplified diagram of a packet network of a mobile operator. It is slightly different for LTE, but the general meaning remains the same.
In the general case, each device with a SIM card registered in the packet network (having passed the GPRS attach procedure or the like), before starting to transfer data somewhere, should initiate the creation of a data transfer session (PDP context) on the packet network core router, GGSN . The details and purpose of these processes are very well described here in this article.. What is important for us: when initiating a session, the request to GGSN, among others, includes parameters that many saw on their phones or even dealt with them when setting up, for example, usb modems. These are three fields: APN, login and password. APN (access point) is a very important entity in the logic of the GGSN: depending on which APN the session is initiated with, the GGSN acts in different ways. As a result of successful processing of a user request, the GGSN must activate a data transfer session and inform the device of its parameters, in particular, the IP address and DNS addresses given to the device. There are a number of important very important features:
On the first three points, the question immediately arises: what kind of IP address is issued to the subscriber?
This is determined by the settings of the APN with which the request to activate the session came. About 99% of mobile data users use regular Internet access. These are internet.mts.ru, internet.beeline.ru, and so on, well-known access points. In the case of Internet access, GGSN issues addresses according to the classical DHCP principle from the gray subnets specified in the settings. When accessing the public network, they are closed by the classic NAT (or rather, by its version, which is PAT).
But GGSN is capable of more. To select an IP address, he can make an AAA request to the authorization server (Radius, for example). This logic is configured for individual APNs depending on their purpose. The simplest case is the service of providing a permanent public IP address. Such addresses, as a rule, are assigned to subscribers in the operator’s billing (BSS), and depending on the IT architecture, they end up in a particular database, which is accessed by the GGSN request. Due to the fact that he knows the MSISDN (phone number) of the subscriber, which will be contained in the request, such a database will be quite simple and may contain only a bunch of numbers and addresses. Additionally, in case the client plans to use one SIM card to connect several devices (if the SIM card is located in a WiFi router of a remote office, for example),
In addition to issuing addresses, it is also necessary to deliver subscriber traffic to client networks, each to its own. Here everything works much more traditionally. On GGSN, traffic specialized for working with VPN APN is routed to a separate router of the operator’s network (it can be called differently, sometimes it is a VPN router), which in turn performs the function of a classical PE in the L3VPN scheme. It adds the necessary labels, headers, and that’s all and sends all this traffic stream through the routers of the transport network to the pre-configured joints or tunnels to the client network. This part is already much more traditional and many times described elsewhere, so I will not focus on it in this material.
Given all these details, there can be several ways to organize a mobile VPN, and they will differ from each other by a combination of the following features:
There are several dozen such combinations with different types of tunneling, balancing traffic between access channels to the “main” VPN client and the principle of issuing addresses. For most cases, the general scheme is as follows:
As a result, after a fairly quick process of registering on the network and obtaining an IP address, the device gets access to the client’s network, and the client’s network gets access to the device. At the same time, the subscriber is isolated from all other subscribers of the operator that are not related to a particular client, he does not need any additional settings, and all traffic is sent to the client’s network without any alternative, where it is processed in accordance with the client’s internal policies.
Tasks and limitations
To begin with, I will answer the question “why?”. VPN as a technology is used to solve a variety of network problems, united by a common feature - the isolated transfer of data between two devices through a large number of intermediate nodes. Based on this, more complex solutions are already being built and the very different tasks are being solved. In the usual case, which is usual for everyone, a fixed-line operator network is used to build a VPN (there is great material for those who wish ) or many different network protocols (GRE, IPSec, L2TP and others - the same author about it) and the software products that work with them (Cisco AnyConnect, OpenVPN, TOR - you yourself know), but their use on a specific terminal device immediately puts forward a number of requirements for it, the failure of which leads to certain restrictions.
The first serious limitation is that the device must be able to work with at least one of these protocols at the hardware and software levels. This is most often determined by software that is easy to find for a laptop or smartphone, but there are cases when the task is faced with a device that is too simple from a hardware point of view, or its software has limitations: the water meter wants to use a VPN to transmit its unfortunate byte of readings once a month no less than you want to use a VPN to edit your LinkedIn profile.
Another important limitation is the need for customization. It works both for “stupid” devices from the first paragraph, and for classic smartphones and computers for which the previous restriction is unknown. And if with the former everything is relatively simple and depends on the amount of time spent on the setup, then with the latter there are options. Often, organizations use VPNs for security purposes to protect the service terminal device from accessing the public network without proper corporate protection or from transferring service data through public channels. End users, however, may for some reason disconnect or forget to enable VPN, as a result of which many of the company's security systems may be left behind.
Both of these restrictions can be easily removed if access to the VPN is provided at the network level. In the case of mobile communications, this can be implemented using the "mobile VPN". A device of any complexity capable of transmitting data will transmit it to the correct network. It doesn’t matter what settings are made on the device, if the network is properly configured, it will in any case transfer them to where you want, and nowhere else.
And as a nice bonus, the device will receive an address from the internal network, configured remotely, and access to it will be possible to get only from within this network (or physically). For a certain class of devices, this is very important.
How it works
PS Core
It would seem that VPN is a classic service of all telecom operators for the B2B segment, and why, then, focus on this? The thing is how the data network is arranged for devices connected via GPRS, HSPA, LTE or other mobile communication technology. There are no vlan familiar to all network administrators, there are no switches, there are not even routers in their usual meaning. But there is a radio access network (RAN) and a packet core (PS Core).
A simplified diagram of a packet network of a mobile operator. It is slightly different for LTE, but the general meaning remains the same.
In the general case, each device with a SIM card registered in the packet network (having passed the GPRS attach procedure or the like), before starting to transfer data somewhere, should initiate the creation of a data transfer session (PDP context) on the packet network core router, GGSN . The details and purpose of these processes are very well described here in this article.. What is important for us: when initiating a session, the request to GGSN, among others, includes parameters that many saw on their phones or even dealt with them when setting up, for example, usb modems. These are three fields: APN, login and password. APN (access point) is a very important entity in the logic of the GGSN: depending on which APN the session is initiated with, the GGSN acts in different ways. As a result of successful processing of a user request, the GGSN must activate a data transfer session and inform the device of its parameters, in particular, the IP address and DNS addresses given to the device. There are a number of important very important features:
- In a request to initiate a session, the device never asks what IP address it would like to receive;
- In addition to the “APN”, “login” and “password” fields set in the device’s settings, the request to GGSN also transfers the telephone number (MSISDN) of the subscriber (hereinafter “subscriber” is the end user, one device with a SIM card, and “Client” - the organization-customer of the service, which includes subscribers);
- When a session is activated, GGSN creates a record of the new IP address in its routing table. All subscribers on the GGSN are indicated by entries in the routing table with the prefix / 32, i.e. 1 subscriber - 1 entry in the table. GGSN is a very productive router;
- An operator’s network can at different stages (both on SGSN and GGSN) for various reasons change the APN field in a request to initiate a session. This allows in some cases to reduce, and in some cases to completely exclude the network settings on devices with a SIM card.
On the first three points, the question immediately arises: what kind of IP address is issued to the subscriber?
This is determined by the settings of the APN with which the request to activate the session came. About 99% of mobile data users use regular Internet access. These are internet.mts.ru, internet.beeline.ru, and so on, well-known access points. In the case of Internet access, GGSN issues addresses according to the classical DHCP principle from the gray subnets specified in the settings. When accessing the public network, they are closed by the classic NAT (or rather, by its version, which is PAT).
But GGSN is capable of more. To select an IP address, he can make an AAA request to the authorization server (Radius, for example). This logic is configured for individual APNs depending on their purpose. The simplest case is the service of providing a permanent public IP address. Such addresses, as a rule, are assigned to subscribers in the operator’s billing (BSS), and depending on the IT architecture, they end up in a particular database, which is accessed by the GGSN request. Due to the fact that he knows the MSISDN (phone number) of the subscriber, which will be contained in the request, such a database will be quite simple and may contain only a bunch of numbers and addresses. Additionally, in case the client plans to use one SIM card to connect several devices (if the SIM card is located in a WiFi router of a remote office, for example),
Not a single GGSN
In addition to issuing addresses, it is also necessary to deliver subscriber traffic to client networks, each to its own. Here everything works much more traditionally. On GGSN, traffic specialized for working with VPN APN is routed to a separate router of the operator’s network (it can be called differently, sometimes it is a VPN router), which in turn performs the function of a classical PE in the L3VPN scheme. It adds the necessary labels, headers, and that’s all and sends all this traffic stream through the routers of the transport network to the pre-configured joints or tunnels to the client network. This part is already much more traditional and many times described elsewhere, so I will not focus on it in this material.
Given all these details, there can be several ways to organize a mobile VPN, and they will differ from each other by a combination of the following features:
- IP addresses, as already described, can be issued dynamically (each time a different address from a given subnet) and statically (each time the same address for a particular subscriber), which is determined by / or the APN settings and / or the settings of the Radius server ;
- IP addresses can be issued by a Radius server under operator control or under client control;
- Devices connected to a mobile VPN can either interact only with each other, or have access to a regular L3VPN client network through a direct interface (VPN port) with an operator or through tunneling over the Internet;
- In some cases, using a username and password to successfully activate a session may be necessary, and sometimes it is not even necessary to fill in the “APN” field.
There are several dozen such combinations with different types of tunneling, balancing traffic between access channels to the “main” VPN client and the principle of issuing addresses. For most cases, the general scheme is as follows:
As a result, after a fairly quick process of registering on the network and obtaining an IP address, the device gets access to the client’s network, and the client’s network gets access to the device. At the same time, the subscriber is isolated from all other subscribers of the operator that are not related to a particular client, he does not need any additional settings, and all traffic is sent to the client’s network without any alternative, where it is processed in accordance with the client’s internal policies.