Mikrotik sstp port error

Overview

Secure Socket Tunneling Protocol (SSTP) transports a PPP tunnel over a TLS channel. The use of TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

Introduction

Let`s take a look at the SSTP connection mechanism:

1. A TCP connection is established from client to server (by default on port 443);
2. SSL validates the server certificate. If a certificate is valid, a connection is established otherwise the connection is turned down. (But see note below);
3. The client sends SSTP control packets within the HTTPS session which establishes the SSTP state machine on both sides;
4. PPP negotiation over SSTP. The client authenticates to the server and binds IP addresses to the SSTP interface;

SSTP tunnel is now established and packet encapsulation can begin;

Certificates

To set up a secure SSTP tunnel, certificates are required. On the server, authentication is done only by username and password, but on the client — the server is authenticated using a server certificate. It is also used by the client to cryptographically bind SSL and PPP authentication, meaning — the clients send a special value over SSTP connection to the server, this value is derived from the key data that is generated during PPP authentication and server certificate, this allows the server to check if both channels are secure.

If SSTP clients are on Windows PCs then the only way to set up a secure SSTP tunnel when using a self-signed certificate is by importing the «server» certificate on the SSTP server and on the Windows PC adding a CA certificate in the trusted root.

A similar configuration on RouterOS client would be to import the CA certificate and enabling the verify-server-certificate option. In this scenario, Man-in-the-Middle attacks are not possible.

Between two Mikrotik routers, it is also possible to set up an insecure tunnel by not using certificates at all. In this case, data going through the SSTP tunnel is using anonymous DH and Man-in-the-Middle attacks are easily accomplished. This scenario is not compatible with Windows clients.

It is also possible to make a secure SSTP tunnel by adding additional authorization with a client certificate. Configuration requirements are:

• certificates on both server and client
• verification options enabled on server and client

This scenario is also not possible with Windows clients, because there is no way to set up a client certificate on Windows.

Certificate Error Messages

When SSL handshake fails, you will see one of the following certificate errors:

• certificate is not yet valid — notBefore certificate date is after the current time;
• certificate has expired — certificate expiry date is before the current time;
• cinvalid certificate purpose — the supplied certificate cannot be used for the specified purpose;
• cself signed certificate in a chain — the certificate chain could be built up using the untrusted certificates but the root could not be found locally;
• cunable to get issuer certificate locally — CA certificate is not imported locally;
• cserver’s IP address does not match certificate — server address verification is enabled, but the address provided in certificate does not match the server’s address;

Quick Example

SSTP Client

In the following configuration example, e will create a simple SSTP client without using a certificate:

[admin@MikroTik > interface sstp-client add connect-to=192.168.62.2 disabled=no name=sstp-out1 password=StrongPass profile=default-encryption user=MT-User
[admin@MikroTik > interface sstp-client print
Flags: X - disabled; R - running 
 0  R name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connect-to=192.168.62.2:443 
      http-proxy=0.0.0.0:443 certificate=none verify-server-certificate=no 
      verify-server-address-from-certificate=yes user="MT-User" password="StrongPass" 
      profile=default-encryption keepalive-timeout=60 add-default-route=no dial-on-demand=no 
      authentication=pap,chap,mschap1,mschap2 pfs=no tls-version=any

SSTP Server

We will configure PPP secret for a particular user, afterwards simply enable an SSTP server:

[admin@MikroTik] > ppp secret add local-address=10.0.0.1 name=MT-User password=StrongPass remote-address=10.0.0.5 service=sstp
[admin@MikroTik] > interface sstp-server server set default-profile=default-encryption enabled=yes
[admin@MikroTik] > interface sstp-server server print
                    enabled: yes
                       port: 443
                    max-mtu: 1500
                    max-mru: 1500
                       mrru: disabled
          keepalive-timeout: 60
            default-profile: default-encryption
             authentication: pap,chap,mschap1,mschap2
                certificate: none
  verify-client-certificate: no
                        pfs: no
                tls-version: any

Overview

Secure Socket Tunneling Protocol (SSTP) transports a PPP tunnel over a TLS channel. The use of TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

Introduction

Let`s take a look at the SSTP connection mechanism:

1. A TCP connection is established from client to server (by default on port 443);
2. SSL validates the server certificate. If a certificate is valid, a connection is established otherwise the connection is turned down. (But see note below);
3. The client sends SSTP control packets within the HTTPS session which establishes the SSTP state machine on both sides;
4. PPP negotiation over SSTP. The client authenticates to the server and binds IP addresses to the SSTP interface;

SSTP tunnel is now established and packet encapsulation can begin;

Starting from v5.0beta2 SSTP does not require certificates to operate and can use any available authentication type. This feature will work only between two MikroTik routers, as it is not in accordance with Microsoft standards. Otherwise to establish secure tunnels mschap authentication and client/server certificates from the same chain should be used.

Certificates

To set up a secure SSTP tunnel, certificates are required. On the server, authentication is done only by username and password, but on the client — the server is authenticated using a server certificate. It is also used by the client to cryptographically bind SSL and PPP authentication, meaning — the clients send a special value over SSTP connection to the server, this value is derived from the key data that is generated during PPP authentication and server certificate, this allows the server to check if both channels are secure.

If SSTP clients are on Windows PCs then the only way to set up a secure SSTP tunnel when using a self-signed certificate is by importing the «server» certificate on the SSTP server and on the Windows PC adding a CA certificate in the trusted root.

If your server certificate is issued by a CA which is already known by Windows, then the Windows client will work without any additional certificate imports to a trusted root.

RSA key length must be at least 472 bits if a certificate is used by SSTP. Shorter keys are considered as security threats.

A similar configuration on RouterOS client would be to import the CA certificate and enabling the verify-server-certificate option. In this scenario, Man-in-the-Middle attacks are not possible.

Between two Mikrotik routers, it is also possible to set up an insecure tunnel by not using certificates at all. In this case, data going through the SSTP tunnel is using anonymous DH and Man-in-the-Middle attacks are easily accomplished. This scenario is not compatible with Windows clients.

It is also possible to make a secure SSTP tunnel by adding additional authorization with a client certificate. Configuration requirements are:

• certificates on both server and client
• verification options enabled on server and client

This scenario is also not possible with Windows clients, because there is no way to set up a client certificate on Windows.

Certificate Error Messages

When SSL handshake fails, you will see one of the following certificate errors:

• certificate is not yet valid — notBefore certificate date is after the current time;
• certificate has expired — certificate expiry date is before the current time;
• cinvalid certificate purpose — the supplied certificate cannot be used for the specified purpose;
• cself signed certificate in a chain — the certificate chain could be built up using the untrusted certificates but the root could not be found locally;
• cunable to get issuer certificate locally — CA certificate is not imported locally;
• cserver’s IP address does not match certificate — server address verification is enabled, but the address provided in certificate does not match the server’s address;

Quick Example

SSTP Client

In the following configuration example, e will create a simple SSTP client without using a certificate:

SSTP Server

We will configure PPP secret for a particular user, afterwards simply enable an SSTP server:

Источник

Manual:Interface/SSTP

Applies to RouterOS: v5, v6+

Contents

Summary

Secure Socket Tunneling Protocol (SSTP) transports a PPP tunnel over a TLS channel. The use of TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

SSTP connection mechanism

• TCP connection is established from client to server (by default on port 443);
• SSL validates server certificate. If certificate is valid connection is established otherwise connection is torn down. (But see note below)
• The client sends SSTP control packets within the HTTPS session which establishes the SSTP state machine on both sides.
• PPP negotiation over SSTP. Client authenticates to the server and binds IP addresses to SSTP interface
• SSTP tunnel is now established and packet encapsulation can begin.

Note: Starting from v5.0beta2 SSTP does not require certificates to operate and can use any available authentication type. This feature will work only between two MikroTik routers, as it is not in accordance with Microsoft standard. Otherwise to establish secure tunnels mschap authentication and client/server certificates from the same chain should be used. Read more>>

Currently, SSTP clients exist in Windows Vista, Windows 7, Windows 8, Linux and RouterOS.

Note: While connecting to SSTP server, Windows does CRL (certificate revocation list) checking on server certificate which can introduce a significant delay to complete a connection or even prevent the user from accessing the SSTP server at all if Windows is unable to access CRL distribution point! Custom generated CA which does not include CRLs can be used to minimize connection delays and certificate costs (signed certificates with known CA usually are not for free), but this custom CA must be imported into each Windows client individually. It is possible to disable CRL check in Windows registry, but it is supported only by Windows Server 2008 and Windows 7 http://support.microsoft.com/kb/947054

Certificates

Note: Starting from RouterOS v6rc10 SSTP respects CRL

To set up a secure SSTP tunnel, certificates are required. On the server, authentication is done only by username and password, but on the client — the server is authenticated using a server certificate. It is also used by the client to cryptographically bind SSL and PPP authentication, meaning — the clients sends a special value over SSTP connection to the server, this value is derived from the key data that is generated during PPP authentication and server certificate, this allows the server to check if both channels are secure.

If SSTP clients are Windows PCs then only way to set up a secure SSTP tunnel when using self-signed certificate is by importing the «server» certificate on SSTP server and on the Windows PC adding CA certificate in trusted root.

Note: If your server certificate is issued by a CA which is already known by Windows, then the Windows client will work without any additional certificates.

Warning: RSA Key length must be at least 472 bits if certificate is used by SSTP. Shorter keys are considered as security threats.

Similar configuration on RouterOS client would be to import the CA certificate and enabling verify-server-certificate option. In this scenario Man-in-the-Middle attacks are not possible.

Between two Mikrotik routers it is also possible to set up an insecure tunnel by not using certificates at all. In this case data going through SSTP tunnel is using anonymous DH and Man-in-the-Middle attacks are easily accomplished. This scenario is not compatible with Windows clients.

It is also possible to make a secure SSTP tunnel by adding additional authorization with a client certificate. Configuration requirements are:

• certificates on both server and client
• verification options enabled on server and client

This scenario is also not possible with Windows clients, because there is no way to set up client certificate on Windows.

Certificate error messages

When ssl handshake fails, you will see one of the following certificate errors:

• certificate is not yet valid — notBefore certificate date is after the current time.
• certificate has expired — notAfter certificate expiry date is before the current time.
• invalid certificate purpose — the supplied certificate cannot be used for the specified purpose.
• self signed certificate in chain — the certificate chain could be built up using the untrusted certificates but the root could not be found locally.
• unable to get issuer certificate locally — CA certificate is not imported locally.
• server’s IP address does not match certificate — server address verification is enabled, but address provided in certificate does not match server’s address.

Hostname verification

Server certificate verification is enabled on SSTP client, additionally if IP addresses or DNS name found in certificate’s subjectAltName or common-name then issuer CN will be compared to the real servers address. v5.7 adds new parameter verify-server-address-from-certificate to disable/enable hostname verification.

SSTP Client

Sub-menu: /interface sstp-client

Properties

Quick example

This example demonstrates how to set up SSTP client with username «sstp-test», password «123» and server 10.1.101.1

SSTP Server

Sub-menu: /interface sstp-server

This sub-menu shows interfaces for each connected SSTP client.

An interface is created for each tunnel established to the given server. There are two types of interfaces in SSTP server’s configuration

• Static interfaces are added administratively if there is a need to reference the particular interface name (in firewall rules or elsewhere) created for the particular user.
• Dynamic interfaces are added to this list automatically whenever a user is connected and its username does not match any existing static entry (or in case the entry is active already, as there can not be two separate tunnel interfaces referenced by the same name).

Dynamic interfaces appear when a user connects and disappear once the user disconnects, so it is impossible to reference the tunnel created for that use in router configuration (for example, in firewall), so if you need a persistent rules for that user, create a static entry for him/her. Otherwise it is safe to use dynamic configuration.

Note: in both cases PPP users must be configured properly — static entries do not replace PPP configuration.

Server configuration

Sub-menu: /interface sstp-server server

Warning: It is very important that the date on the router is within the range of the certificate’s date of expiration. To overcome any certificate verification problems, enable NTP date synchronization on both server and client.

Monitoring

Monitor command can be used to monitor status of the tunnel on both client and server.

Application Examples

Connecting Remote Client

The following example shows how to connect a computer to a remote office network over secure SSTP encrypted tunnel giving that computer an IP address from the same network as the remote office has (without the need for bridging over EoIP tunnels)

Consider following setup:

Office router is connected to internet through ether1. Workstations are connected to ether2. Laptop is connected to the internet and can reach Office router’s public IP (in our example it is 192.168.80.1).

Before you begin to configure SSTP you need to create a server certificate and import it into the router (instructions here).

Now it is time to create a user:

Notice that SSTP local address is the same as the router’s address on the local interface and the remote address is from the same range as the local network (10.1.101.0/24).

Next step is to enable SSTP server and SSTP client on the laptop:

Notice that authentication is set to mschap. These are the only authentication options that are valid to establish a secure tunnel.

SSTP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.

Please, consult the respective manual on how to set up a SSTP client with the software you are using. If you set up SSTP client on Windows and self-signed certificates are used, then CA certificate should be added to trusted root.

Note: Currently, SSTP is only fully supported on recent Windows OS releases such as Vista SP1, Windows 7, Windows 8, Windows 2008 etc. With other OS’s such as Linux, results cannot be guaranteed.

To verify if SSTP client is connected

At this point (when SSTP client is successfully connected) if you try to ping any workstation from the laptop, ping will time out, because Laptop is unable to get ARPs from workstations. Solution is to set up proxy-arp on local interface

After proxy-arp is enabled client can successfully reach all workstations in the local network behind the router.

Site-to-Site SSTP

The following is an example of connecting two Intranets using SSTP tunnel over the Internet.

Consider following setup:

Office and Home routers are connected to internet through ether1, workstations and laptops are connected to ether2. In this example both local networks are routed through SSTP client, thus they are not in the same broadcast domain. To overcome this problem as with any other ppp tunnel, SSTP also supports BCP which allows it to bridge SSTP tunnel with a local interface.

First step is to create a user:

Notice that we set up SSTP to add a route whenever the client connects. If this option is not set, then you will need a static routing configuration on the server to route traffic between sites through the SSTP tunnel.

Now we need to upload and import CA and server/client certificates. Assuming that the files are already uploaded use following commands:

Edit names to something more meaningful:

Do the same on client side, but instead of server’s certificate import client’s certificate.

Next step is to enable SSTP server on the office router:

Now configure SSTP client on the Home router:

Now we need to add static route on Home router to reach local network behind Office router:

After tunnel is established you should be able to ping remote network.

Источник

Продолжая тему VPN для удаленного доступа, сегодня мы хотим рассмотреть настройку SSTP-сервера на базе оборудования Mikrotik. Это не самый распространенный и популярный протокол, но имеющий ряд особенностей и преимуществ, главное из которых — использование стандартного протокола HTTPS для установления соединения, что делает SSTP-трафик неотличимым от обычного и дает возможность работать из любой точки, где есть интернет, проходя через NAT, брандмауэры и даже прокси-сервера. При этом его достаточно просто настроить и использовать, о чем мы расскажем в данной статье.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Практически все из рассмотренных нами ранее протоколов VPN имеют те или иные ограничения, которые могут помешать установить соединение в условиях ограниченного доступа к сети интернет. Особенно это актуально для публичных и гостиничных сетей, где может быть заблокировано практически все, кроме обычного HTTP/HTTPS. Именно в таких сценариях раскрываются сильные стороны протокола SSTP и отходят на второй план слабые. Как мы уже говорили раньше — нет универсального VPN-решения, каждое из них имеет свои особенности и недостатки, поэтому для каждой задачи надо выбирать именно то, что поможет решить ее наилучшим образом.

SSTP, как технологию удаленного доступа следует рассматривать в первую очередь для тех клиентов, которые могут работать из самых различных мест и должны всегда иметь возможность быстро подключиться к корпоративной сети соблюдая высокие требования безопасности. К недостаткам следует отнести повышенные накладные расходы и связанную с этим невысокую производительность, но это общий недостаток всех VPN-протоколов поверх TCP.

В случае использования оборудования Mikrotik встает вопрос высокой нагрузки на процессор для моделей без аппаратной поддержки AES. При этом вне зависимости от аппаратной поддержки шифрования скорость канала для недорогих моделей вряд-ли превысит 20-25 МБит/с , вне зависимости от доступной ширины канала. Более подробно об этом можете прочитать в нашей статье Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование. Поэтому мы не советуем использовать SSTP для каналов, предполагающих высокую загрузку, но можем рекомендовать как надежное и безопасное средство удаленного доступа для сотрудников, часто работающих вне стационарных рабочих мест.

Создание центра сертификации и выпуск сертификатов

Так как SSTP использует HTTPS для установления защищенного соединения нам понадобится сертификат сервера, поэтому создадим собственный центр сертификации (CA) и выпустим необходимый сертификат. Если в вашей сети уже имеется развернутая инфраструктура PKI, то можете выпустить сертификат с ее помощью, мы же рассмотрим использование для этих целей собственных возможностей RouterOS.

Перед тем, как приступить к созданию центра сертификации убедитесь, что на роутере правильно настроено текущее время и часовой пояс, а также включена синхронизация времени через NTP.

Сначала выпустим корневой сертификат, для этого перейдем в System — Certificate и создадим новый сертификат заполнив поля как указано на рисунке, красным обозначены обязательные к заполнению.

Name — видимое имя сертификата, Common Name — имя субъекта, которому выдан сертификат, в каждом из них указываем CA (т.е. Certification authority). Вообще там можно написать все что угодно, но правила хорошего тона требуют давать сертификатам понятные имена. Key Size — размер ключа, оставляем по умолчанию 2048, Days Valid — срок действия сертификата в днях, имеет смысл указать достаточно продолжительный срок, в нашем случае 10 лет.

Перейдем на вкладку Key Usage и оставим только crl sign и key cert. sign, затем сохраним сертификат нажав Apply, и подпишем его кнопкой Sign, в открывшемся окне следует указать CA CRL Host, для которого можно использовать один из IP-адресов роутера, в нашем случае это localhost. Если же при помощи данного CA вы собираетесь выпускать сертификаты для других серверов, то следует указать доступный для них адрес, внутренний или внешний.

В терминале все это можно быстро сделать командами:

/certificate 
add name=CA country="RU" state="31" locality="BEL" organization="Interface LLC" common-name="CA" key-size=2048 days-valid=3650 key-usage=crl-sign,key-cert-sign 
sign CA ca-crl-host=127.0.0.1

Затем выпустим сертификат сервера. При этом надо определиться каким образом вы будете подключаться к серверу по IP-адресу или FQDN (доменному имени), второй вариант более предпочтителен, так как при смене адреса вам придется перевыпустить сертификат сервера и изменить настройки всех клиентских подключений.

Заполнение полей практически ничем не отличается от предыдущего сертификата, за исключением Common Name и Subject Alt. Name, в них указываем FQDN или IP-адрес сервера, для поля Subject Alt. Name также указываем тип: DNS — для доменного имени или IP для адреса. Срок действия сертификата также имеет смысл сделать достаточно большим, в нашем случае 10 лет.

На закладке Key Usage устанавливаем digital-signature, key-encipherment и tls-server и подписываем сертификат сервера, для этого в поле CA выберите ранее выпущенный корневой сертификат.

В терминале:

/certificate 
add name=sstp.interface31.lab country="RU" state="31" locality="BEL" organization="Interface LLC" common-name="sstp.interface31.lab" subject-alt-name=DNS:"sstp.interface31.lab" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,tls-server
sign sstp.interface31.lab ca="CA"

При подключении через SSTP клиент прежде всего устанавливает с сервером защищенное соединения, а для этого ему нужно проверить сертификат и убедиться в его подлинности, в противном случае продолжение соединения будет невозможным. Чтобы клиентские системы доверяли нашим сертификатам нам нужно будет установить на них корневой сертификат нашего CA.

Для этого выберем корневой сертификат в System — Certificate, щелкнем на нем правой кнопкой мыши и нажмем Export, в поле Type ставим PEM, пароль не указываем, так как нам нужен только сертификат, без закрытого ключа. Закрытый ключ центра сертификации является секретным и никогда не должен покидать пределы роутера.

В терминале сертификат можно экспортировать командой:

/certificate
export-certificate CA

Найти и скачать выгруженный сертификат можно в разделе Files.

Настройка SSTP VPN-сервера

Перед тем как браться за настройку сервера следует определиться со схемой доступа к сети, существуют два основных варианта: Proxy ARP, когда адреса удаленным клиентам выдаются из диапазона основной сети и они получают доступ без дополнительных настроек, и маршрутизация, когда диапазон адресов для VPN-клиентов не пересекается с основной сетью, а для доступа в нее будет необходимо указать маршруты, этот процесс можно автоматизировать с помощью PowerShell.

После этого перейдем в IP — Pool и создадим новый пул адресов для выдачи VPN-сервером, количество адресов в пуле не должно быть меньше предполагаемого количества клиентов.

В терминале:

/ip pool
add name=sstp_pool ranges=10.20.0.100-10.20.0.199

Затем перейдем в PPP — Profiles и создадим новый профиль, в поле Local Address введем локальный адрес VPN-сервера, он должен относиться к тому же диапазону что и выделенный выше пул адресов, который следует указать в поле Remote Address, остальные настройки оставляем по умолчанию.

Или выполним команду:

/ppp profile
add local-address=10.20.0.1 name=SSTP-profile remote-address=sstp-pool

Затем переместимся в PPP — Secrets и создадим учетные записи пользователей, указываем имя пользователя, пароль, в поле Service выбираем sstp, что ограничит действие учетной записи только SSTP-сервером, если оставить any, то учетка сможет подключаться к любому сервису. В поле Profile указываем созданный нами профиль.

Эти же действия в командной строке:

/ppp secret
add name=Ivanov password=Pa$$word profile=SSTP-profile service=sstp

Теперь, когда все готово, настроим сам сервер. Для этого перейдем в PPP — Interface и нажмем кнопку SSTP Server. Включим его, установив флаг Enabled, в поле Default Profile выберем созданный нами профиль, в разделе Authentication оставим только mschap2, в поле Certificate указываем сертификат сервера. Дальнейшие настройки отвечают за повышение уровня безопасности: TLS Version — only-1.2 не разрешает использование устаревших версий TLS, Force AES — заставляет принудительно использовать алгоритм шифрования AES256, PFS включает совершенную прямую секретность (Perfect forward secrecy), которая формирует уникальный сессионный ключ для каждого подключения, что делает невозможным расшифровку сессии даже при наличии закрытого ключа.

В терминале для включения и настройки сервера выполните:

/interface sstp-server server
set authentication=mschap2 certificate=sstp.interface31.lab default-profile=SSTP-profile enabled=yes force-aes=yes pfs=yes tls-version=only-1.2

На этом настройка закончена, сервер готов принимать подключения.

Настройка подключения клиента в Windows

Как мы уже говорили, для того чтобы клиент мог проверить подлинность сервера нам необходимо импортировать корневой сертификат, переместим его на клиента и установим в Расположение хранилища — Локальный компьютер:

Хранилище сертификатов — Доверенные корневые центры сертификации:

Затем создаем подключение, в котором указываем Тип VPN — Протокол SSTP и Тип данных для входа — Имя пользователя и пароль, здесь же вводим адрес сервера и учетные данные.

После чего в свойствах подключения на закладке Безопасность убедимся, что в разделе Проверка подлинности указан только протокол MS-CHAP v2.

Настройка клиента закончена, можно подключаться.

Настройка подключения клиента в Linux

В используемых нами дистрибутивах Linux нет штатного SSTP-клиента, однако есть сторонняя разработка, которой мы и воспользуемся. Все нижесказанное будет справедливо для дистрибутивов основанных на Debian и Ubuntu, если у вас иная система обратитесь на страницу проекта.

Проще всего владельцам Ubuntu, им достаточно просто подключить PPA, ниже приведен пример для Ubuntu 18.04, для других систем просто измените кодовое название дистрибутива:

deb http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu bionic main 
deb-src http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu bionic main

В Debian процесс немного более сложный, сначала получим и установим ключ репозитория проекта:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 61FF9694161CE595

Затем создадим файл с указанием источников пакетов:

touch /etc/apt/sources.list.d/sstp-client.list

И внесем в него следующие строки:

deb http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu eoan main 
 deb-src http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu eoan main

Обновим список пакетов и установим клиент:

apt update
apt install network-manager-sstp

После чего появится возможность создать SSTP-соединение штатными средствами Network Manager. Настройки несложные: указываем адрес сервера, учетные данные и сертификат CA, у которого предварительно следует изменить расширение на PEM.

Если вы все сделали правильно, то соединение будет установлено.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.