{"id":89276,"date":"2020-07-21T13:42:28","date_gmt":"2020-07-21T11:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-popast-v-ipvpn-bilajn-cherez-ipsec-chast-1"},"modified":"2026-07-05T10:59:44","modified_gmt":"2026-07-05T08:59:44","slug":"kak-popast-v-ipvpn-bilajn-cherez-ipsec-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-popast-v-ipvpn-bilajn-cherez-ipsec-chast-1","title":{"rendered":"How to access Beeline IPVPN through IPSec. Part 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello! In the previous post<\/a> I described the operation of our MultiSIM service regarding reservation<\/a> and balancing<\/a> channels. As mentioned, we connect clients to the network via VPN, and today I'll share a bit more about VPN and our capabilities in this area.<\/p>\n

To begin with, as a telecommunications operator, we have our own extensive MPLS network, which is divided into two main segments for fixed-line clients \u2014 one used directly for Internet access, and the other used for creating isolated networks \u2014 with IPVPN (L3 OSI) and VPLAN (L2 OSI) traffic flowing through this MPLS segment for our corporate clients.<\/p>\n

\"How<\/a><\/a>
\nTypically, client connections occur as follows.<\/p>\n

An access line is laid to the client's office from the nearest Point of Presence (POP) of the network (MEN node, P2P link, BSSS, FTTB, etc.), and then, the channel is routed through the transport network to the corresponding PE-MPLS router, where it's assigned to a specifically created VRF for the client, taking into account their required traffic profile (profile tags are selected for each access port based on the values of IP precedence 0, 1, 3, 5).<\/p>\n

If, for any reason, we cannot fully organize the last mile for the client, for example, if the client's office is in a business center where another provider is prioritized, or if there is simply no point of presence near them, clients previously had to create multiple IPVPN networks with different providers (not the most cost-effective architecture) or solve access issues to their VRF over the Internet.<\/p>\n

Many did this by setting up an IPVPN Internet gateway \u2014 they installed a border router (hardware or some solution based on Linux), connected an IPVPN channel to one port and an Internet channel to another, launching their own VPN server<\/a> and connecting users through their own VPN gateway. Naturally, such a scheme brings its own challenges: this infrastructure needs to be built correctly and, what's most inconvenient \u2014 maintained and developed.<\/p>\n

To simplify life for our clients, we established a centralized VPN hub and organized support for connections over the internet using IPSec. Now, clients only need to configure their routers to work with our VPN hub via an IPSec tunnel through any public internet, and we will route that client's traffic into their VRF.<\/p>\n

Who will benefit<\/h2>\n

 <\/p>\n