Hello! IN I described the work of our MultiSIM service in part и channels. As mentioned, we connect clients to the network via VPN, and today I will tell you a little more about VPN and our capabilities in this part.
It’s worth starting with the fact that we, as a telecom operator, have our own huge MPLS network, which for fixed-line customers is divided into two main segments - the one that is used directly for accessing the Internet, and the one that is used to create isolated networks - and it is through this MPLS segment that IPVPN (L3 OSI) and VPLAN (L2 OSI) traffic goes for our corporate clients.
Typically, a client connection occurs as follows.
An access line is laid to the client's office from the nearest Point of Presence of the network (MEN node, RRL, BSSS, FTTB, etc.) and further, the channel is prescribed over the transport network to the corresponding PE-MPLS router, on which we output it to a specially created for the VRF client based on the traffic profile that the client needs (profile labels are selected for each access port based on ip precedence values of 0,1,3,5).
If for some reason we cannot fully organize the last mile for the client, for example, the client’s office is located in a business center where another provider is a priority, or our point of presence simply is not nearby, then before clients had to create several IPVPN networks at different providers (not the most cost-effective architecture) or independently resolve issues with organizing access to your VRF over the Internet.
Many did this by installing an IPVPN Internet gateway - they installed a border router (hardware or some kind of Linux-based solution), connected an IPVPN channel to it with one port, and an Internet channel with another, launched their own VPN server on it, and connected users through their own VPN gateway. Naturally, such a scheme also creates encumbrances: such an infrastructure must be able to build and, what is most inconvenient, to operate and develop.
To make life easier for our customers, we installed a centralized VPN hub and organized support for enabling over the Internet using IPSec, that is, now customers only need to configure their router to work with our VPN hub via an IPSec tunnel through any public Internet, and we let's release this client's traffic into its VRF.
Who will need
- Those who already have a large IPVPN network and need new connections in a short time.
- Anyone who, for some reason, wants to move part of the traffic from the public Internet to IPVPN, but has previously encountered technical limitations associated with several service providers.
- Those who now have several disparate VPN networks from different telecom operators. There are clients who have successfully organized IPVPN from Beeline, Megafon, Rostelecom, etc. To make it easier, you can stay only on our single VPN, switch all other channels of other operators to the Internet, and then connect to IPVPN Beeline via IPSec and the Internet from these operators.
- Those who already have an IPVPN network overlaid on the Internet.
If you deploy everything with us, then clients receive both full-fledged support for VPN, and serious infrastructure redundancy, and typical settings that will work on any router familiar to it (be it at least Cisco, at least Mikrotik, the main thing is to be able to properly support IPSec / IKEv2 with standardized authentication methods). By the way, about IPSec - right now we only support it, but we plan to launch full-fledged work with both OpenVPN and Wireguard so that clients can not depend on the protocol and it’s even easier to take and transfer everything to us, and we also want to start connecting clients from computers and mobile devices (OS-embedded solutions, Cisco AnyConnect and strongSwan and the like). With this approach, de facto infrastructure construction can be safely given to the operator, leaving only the CPE or host settings.
How the connection process works for IPSec mode:
- The client leaves a request to his manager in which he indicates the required connection speed, traffic profile and IP addressing parameters for the tunnel (by default, the subnet with a /30 mask) and the type of routing (static or BGP). To transfer routes to the client's local networks in the connecting office, the IKEv2 mechanisms of the IPSec protocol phase are used using the appropriate settings on the client router, or they are announced via BGP in MPLS from the private BGP AS specified in the application by the client. Thus, information about the routes of client networks is completely controlled by the client through the settings of the client router.
- In response, the client receives accounting data from his manager to be included in his VRF of the form:
- VPN Hub IP Address
- Login
- Authentication password
- Configures the CPE, below, for example, two options for the basic configuration:
Option for Cisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 – Beeline VPN concentrator
pre-shared-key <Authentication Password>
!
For the static routing option, routes to networks accessible via the Vpn-hub can be set in the IKEv2 configuration and they will automatically appear as static routes in the CE routing table. These settings can also be made in the standard way of setting static routes (see below).crypto ikev2 authorization policy FlexClient-author
Route to networks behind the CE router - a mandatory setting for static routing between CE and PE. The transmission of route data to the PE is performed automatically when the tunnel is raised through the IKEv2 interaction.
route set remote ipv4 10.1.1.0 255.255.255.0 – Office LAN
!
crypto ikev2 profile BeelineIPSec_profile
identity local <login>
authentication local pre-share
authentication remote pre-share
keyring local BeelineIPsec_keyring
aaa authorization group psk list group-author-list FlexClient-author
!
crypto ikev2 client flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
client connect Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
tunnel mode
!
crypto ipsec profile default
set transform-set TRANSFORM1
set ikev2-profile BeelineIPSec_profile
!
interface tunnel1
ip address 10.20.1.2 255.255.255.252 –Tunnel address
tunnel source GigabitEthernet0/2 –Internet access interface
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Routes to the client's private networks accessible through the Beeline VPN concentrator can be set statically.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Option for Huawei (ar160/120) :
ike local-name <login>
#
acl name ipsec 3999
rule 1 permit ip source 10.1.1.0 0.0.0.255 – Office LAN
#
aaa
service-scheme IPSEC
route set acl 3999
#
ipsec proposal ipsec
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
ike proposal default
encryption-algorithm aes-256
dh group2
authentication-algorithm sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key simple <Authentication password>
local-id-type fqdn
remote-id-type ip
remote address 62.141.99.183 – Beeline VPN concentrator
service-scheme IPSEC
config-exchange request
config-exchange set accept
config-exchange set send
#
ipsec profile ipsecprof
ike peer ipsec
proposal ipsec
#
interface tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 –Tunnel address
tunnel-protocol ipsec
source GigabitEthernet0/0/1 –Internet access interface
ipsec profile ipsecprof
#
Routes to private client networks accessible via the Beeline VPN concentrator can be set staticallyip route-static 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip route-static 172.16.0.0 255.255.0.0 Tunnel0/0/0
The resulting connection diagram looks something like this:
If the client does not have some examples of the basic configuration, then we usually help with their formation and make them available to everyone else.
It remains to connect the CPE to the Internet, ping to the counterpart of the VPN tunnel and any host inside the VPN, and that's it, we can assume that the connection has taken place.
In the next article, we will describe how we combined this scheme with IPSec and MultiSIM Redundancy using Huawei CPE: we install our Huawei CPE for clients, which can use not only a wired Internet channel, but also 2 different SIM cards, and CPE automatically rebuilds IPSec- tunnel either over a wired WAN or over a radio (LTE#1/LTE#2), realizing the high resiliency of the resulting service.
Special thanks for preparing this article (and, in fact, to the authors of these technical solutions) to colleagues from our RnD!
Source: habr.com