How to get to IPVPN Beeline via IPSec. Part 1
To begin with, we, as a telecom operator, have our own huge MPLS network, which is divided into two main segments for fixed-line customers – 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 for our corporate clients goes.
Typically, the client connects 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 registered via the transport network to the corresponding PE-MPLS router, on which we bring it to a specially created for a VRF client, taking into account the traffic profile that the client needs (profile labels are selected for each access port based on ip precedence values 0,1,3,5).
If for some reason we cannot fully organize the last mile with the client, for example, the client’s office is located in a business center, where another provider is a priority, or there is simply no point of presence nearby, then earlier clients had to create several IPVPN networks for 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 an edge router (hardware or some Linux-based solution), connected an IPVPN channel to it with one port, and an Internet channel with the other, launched their own VPN server on it, and connected users through their own VPN gateway. Naturally, such a scheme also generates encumbrances: such an infrastructure needs to 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 connections 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 to its VRF.
Who will benefit from
- Those who already have a large IPVPN network and need new connections on a tight schedule.
- Anyone who, for some reason, wants to move part of the traffic from the public Internet to IPVPN, but previously faced technical restrictions associated with several service providers.
- For those who now have several scattered 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 only stay on our single VPN, switch all other channels of other operators to the Internet, and then connect to Beeline IPVPN via IPSec and the Internet from these operators.
- For those who already have an IPVPN network overlaid on the Internet.
If you deploy everything with us, then clients receive a full-fledged VPN support, and serious infrastructure redundancy, and standard settings that will work on any router they are used to (be it Cisco or 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 of both OpenVPN and Wireguard, so that clients can not depend on the protocol and it is even easier to take and transfer everything to us, and we also want to start connecting clients from computers and mobile devices (embedded in OS solutions, Cisco AnyConnect and strongSwan and the like). With this approach, de facto, the construction of the infrastructure can be safely given to the operator, leaving only the CPE or host configuration.
How the connection process for IPSec mode works:
- 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, a subnet with a mask / 30) and the type of routing (static or BGP). To transfer routes to the client’s local networks in the connected office, the IKEv2 mechanisms of the IPSec protocol phase are used with the appropriate settings on the client router, or they are announced via BGP in MPLS from the private BGP AS specified in the client’s application. Thus, the information about the routes of client networks is completely controlled by the client through the settings of the client router.
- In response from his manager, the client receives account data to be included in his VRF of the form:
- VPN-HUB IP Address
- Login
- Authentication password
- Configures CPE, below, for example, two basic configuration options:
Option for Cisco:crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 –VPN hub Beelinepre-shared-key
!
For the option with static routing, routes to networks accessible through Vpn-hub can be specified 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 a CE router is a mandatory configuration for static routing between CE and PE. The transfer of these routes to PE is performed automatically when the tunnel is raised through IKEv2 interaction.
route set remote ipv4 10.1.1.0 255.255.255.0 –Local office network
!
crypto ikev2 profile BeelineIPSec_profile
identity local < логин >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
mode tunnel
!
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 addresstunnel 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 < логин >#
acl name ipsec 3999
rule 1 permit ip source 10.1.1.0 0.0.0.255 –Local office network#
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 simplelocal-id-type fqdn
remote-id-type ip
remote-address 62.141.99.183 –VPN hub Beelineservice-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 addresstunnel-protocol ipsec
source GigabitEthernet0 / 0/1 – Internet access interfaceipsec profile ipsecprof
#
Routes to the client’s private networks, accessible through 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/0The resulting communication scheme 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.
All that remains is to connect the CPE to the Internet, ping to the response part of the VPN tunnel and any host inside the VPN, and that’s it, we can assume that the connection has been made.
In the next article, we will tell you how we combined this scheme with IPSec and MultiSIM Redundancy using Huawei CPE: we put our Huawei CPE to customers, in which not only a wired Internet channel can be used, but also 2 different SIM cards, and the CPE automatically rebuilds IPSec- tunnel either via wired WAN or radio (LTE # 1 / LTE # 2), realizing high resiliency of the final service.
Special thanks to colleagues from our RnD for preparing this article (and, in fact, to the authors of these technical solutions)!
Similar Posts
