How to get to IPVPN Beeline via IPSec. Part 1

Hello! In the previous post, I described the operation of our MultiSIM service in part reservations and balancing 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.

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:

  1. 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.
  2. 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

  3. 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 Beeline

    pre-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 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 Tunnel1

    Option 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 simple

    local-id-type fqdn
    remote-id-type ip
    remote-address 62.141.99.183 –VPN hub Beeline

    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 the client’s private networks, accessible through the Beeline VPN concentrator, can be set statically

    ip 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 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

Leave a Reply Cancel reply