Strongswan gui client linux

Strongswan gui client linux

strongSwan — Download

strongSwan 5.x — Monolithic IKEv1/v2 Daemon

Current Release: 5.9.3

Developers Release: 5.9.4dr3

Developers Release: 6.0.dr10

strongSwan 2.x, 4.x and 5.x Security Patches

NetworkManager Applet

This applet is also available as package in several distributions. For an introduction and HOWTO see our wiki.

Current Release: 1.5.2

NetworkManager Applet 1.5.2 This version requires strongSwan 5.8.3 or newer, it’s not compatible with older releases. NetworkManager Applet 1.4.5 This version works with all strongSwan releases, but doesn’t support the new features introduced with 5.8.3.

Installation / Binary packages

Most distributions provide packages for strongSwan:

Download Mirrors

• download.strongswan.org Hochschule für Technik Rapperswil (100 Mbps)
• download2.strongswan.org strongSec GmbH (5 Mbps)

License statement

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Источник

strongSwan

Documentation¶

Resources¶

NetworkManager¶

NetworkManager allows configuration and control of VPN daemons through a plugin interface. We provide such a plugin for NetworkManager to configure road warrior clients for the most common setups. The plugin supports connections using the IKEv2 protocol only.

NetworkManager uses D-Bus to communicate with a special build of the charon IKE daemon (charon-nm), which runs independent of the regular daemon (e.g. charon-systemd) to avoid conflicts.

The plugin uses a certificate for server authentication and supports EAP and public key authentication for client authentication (since 5.8.3 / NetworkManager-strongswan 1.5.0 also EAP-TLS). PSK authentication is supported starting with version 1.3.1 of the plugin, but strong secrets (min. of 20 characters) are enforced.

You can use any password based EAP method supported by strongSwan (MD5/GTC/MSCHAPv2) or public key authentication. Private keys are either stored in a file or accessed through your ready-to-use ssh-agent. You’ll need a certificate matching that key. Starting with strongSwan 4.5.0 / NetworkManager-strongswan 1.2.0, private keys and certificates on a smart card can be used (see below for details).

If you configure the server certificate directly on the clients, there are no requirements to the certificate. If you deploy CA certificates (supported since 4.3.1), the server certificate will need a subjectAltName including the host name of the server (the same you enter in the client’s configuration). Since 5.8.3 / NetworkManager-strongswan 1.5.0 it’s possible to configure the server identity explicitly. Starting with 4.3.5, you can also use preinstalled root CA certificates of your distribution, using the —with-nm-ca-dir configure option. Since 5.5.1 this can also be modified with the charon-nm.ca_dir setting. Just don’t specify any server/CA certificate in the GUI to use preinstalled root certificates. CA certificates on a smart card are automatically used.

Screenshots¶

Dependencies¶

The original strongSwan NM plugin and the NetworkManager VPN module were based on the NetworkManager 0.9 interface. Version 1.4.0 of the plugin updated parts of it to the NetworkManager 1.2 interface (mostly related to the GUI, the plugin in charon-nm is largely unchanged). It should work out-of-the-box with the latest packages of your favorite Linux distribution.

Installation¶

Your distribution may provide a package (e.g. network-manager-strongswan on Debian/Ubuntu).

Otherwise, you have to build strongSwan from source.

Building from source¶

To build from source you additionally need the NetworkManager headers for the strongSwan NM backend:

NM integration works only for IKEv2. Since on a desktop we have OpenSSL installed anyway, we are going to use libcrypto for all cryptographic operations. —enable-agent builds the ssh-agent private key plugin, EAP plugins are enabled using —enable-eap-gtc —enable-eap-md5 —enable-eap-mschapv2 . For smart card support, —enable-pkcs11 . You may omit options you don’t need.

Configuration¶

• Click on nm-applet -> Edit Connections. (or VPN Connections -> Configure VPN. in older releases)
• Add -> IPsec/IKEv2 (strongswan) -> Create.
• Configure your client
• Click on nm-applet -> VPN Connections -> Your Connection
• Enter password

As you can see, there is no subnet configuration for the tunnel. We let the server administration choose the subnet(s); the client always proposes 0.0.0.0/0 for the remote network and the server narrows that down to the configured subnet(s).

If you use Certificate/private key authentication, please store your certificate and private key in separate files.

Smart card requirements¶

The use of smart cards should be as simple as possible to the end user, which brings some restrictions. For instance, the daemon automatically selects the first certificate with a private key on any token in any slot.

First, you’ll need to specify the PKCS#11 module in strongswan.conf. Please refer to the general description of smart card support with IKEv2 for details on how to do so (use the charon-nm prefix to only load a module in the NM backend).

You may define multiple modules, the daemon looks for the first certificate/private key in the specified module order.

The daemon uses the following mechanism to find a private key:

• enumerate all certificates which have the TLS Client Auth Extended Key usage, but no CA constraint
• for each certificate:
  • extract the subjectKeyIdentifier
  • enumerate all modules with all tokens
  • for each token:
    • look for a public key having the certificates subjectKeyIdentifier as ID
    • if not found, enumerate all public keys and look for a certificate with a matching subjectKeyIdentifier and use its ID
      • if found, log in to the smart card using the supplied PIN
      • if logged in, load the associated private key

In short, the private key on the token must have a public key readable without login, and both objects must have a matching ID. Before 5.5.1 both objects had to have an ID matching the certificates subjectKeyIdentifier (or the hash of the subjectPublicKey field of the public key).

The certificate needs the TLS CLient Auth Extended Key usage flag.

The daemon uses the first subjectAltName of the selected certificate as IKEv2 identity, or uses the full DN if none found. Since 5.8.3 / NetworkManager-strongswan 1.5.0 the client identity may also be configured explicitly.

Источник

Обзор IPSEC демона StrongSwan

Введение

Обзор демона StrongSwan

StrongSwan является демоном IPSEC, который поддерживает IKEv1 и IKEv2. На данный момент это развивающий продукт. Установка StrongSwan может быть выполнена из исходников или репазитория. Установка из исходников описана на сайте StrongSwan.
Установка из репазитория происходит без проблем командой:
Файлы конфигурирования по умолчанию хранятся в директории /etc/ и имеют следующие названия:

• ipsec.conf – определяет параметры IPSEC-соединений и параметры подключений в целом;
• ipsec.secrets – служит для хранения ссылок на сертификаты и ключи аутентификации;
• strongswan.conf – для подключения криптографических алгоритмов и дополнительных функций.

Помимо этого во время установки программного обеспечения для хранения сертификатов и CRL-файлов используемых демонами pluto и charon создается директория /etc/ipsec.d, в которой находятся следующие каталоги:

• private – содержит закрытые ключи RSA и ECDSA;
• certs – содержит сертификаты X.509 и PGP;
• crls – хранит список отозванных сертиифкатов;
• cacerts – хранит доверенные сертификаты CA;
• ocspcerts – содержит подписанные OCSP сертификаты;
• reqs – содержит запросы на сертификаты в формате PKCS#10.

Файл /etc/ipsec.secrets содержит неограниченное количество следующих типов ключей (паролей):

• RSA для определения пароля к сертификату открытого ключа;
• ECDS для определения пароля к сертификату открытого ключа;
• PSK для определения Pre-shared ключа;
• EAP для учетных записей EAP;
• NTLM для учетных записей NTLM;
• XAUTH для учетных записей XAUTH;
• PIN для пин-кода смарт-карт.

Соответственно поддерживаются все типы аутентификации.
Основные параметры команды ipsec, которая управляет подключениями StrongSwan:

• start|restart|stop;
• ipsec status|statusall — для просмотра состояния IPSEC-соединений;
• up|down|route|unroute — для управления IPSEC-соединений.

Логи хранятся в /var/log/auth.log и /var/log/daemon.log.

Настройка Remote Access VPN на сертификатах

Генерация сертификатов

Генерация сертификатов является самой ответственной частью и самой трудной, именно от нее будет зависеть работоспособность нашего IPSEC=тунеля.
Сертификаты генерировались с помощью OPENSSL.
Сначала настраиваем OPENSSL:

Создаем директорию для новых сертификатов и файл с серийником для OPENSSL

Генерируем сертификат для сервера:

При генерации сертификата обязательно нужно задать для серверного сертификата в openssl.cnf параметр subjectAltName=IP:
Генерируем сертификат для клиента:

Настройка StrongSwan

Основными файлами для настройки являются etc/ipsec.conf и ipsec.secrets.
Начнем с ipsec.conf

Более подробно ознакомиться с директивами данного файла можно по ссылке.

Настройка IPSEC подключения для Win7 и импорт сертификатов .

Дальше можно подключиться клиентом и проверить статус соединения командой ipsec statusall и просмотром логов, ну и в Windows должно быть успешно подключено VPN-соединение и пинги будут бегать.

Источник

VPN везде и всюду: IPsec без L2TP со strongSwan

достаточно сильный лебедь

Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.

Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.

Небольшое введение в мир IPsec

Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.

В современном IPsec используются:

• Authentication Header (AH) — протокол, обеспечивающий аутентификацию отправителя и целостность данных. Подписывает не только данные пакета, но и все заголовки, кроме изменяемых полей (ToS, TTL, чексумма).
• Encapsulating Security Payload (ESP) — протокол, обеспечивающий аутентификацию, целостность и конфиденциальность
• Security Association (SA) — параметр с настройками шифрования канала
• Internet Key Exchange (IKE и IKEv2) — протокол обмена параметрами, настройками и согласования SA

AH и ESP — транспортные протоколы, инкапсулируемые прямо в IP, имеющие собственные значение для поля Protocol в IP-заголовке. В современном мире, где NAT стоит за NAT у NAT с NAT’ом, следует использовать что-то более привычное, поэтому сейчас повсеместно используется инкапсуляция ESP-пакетов в UDP. AH не поддерживает работу через NAT.

Сам IPsec поддерживает работу в двух режимах:

• Транспортный режим. Подписывает заголовки и данные (если AH) или подписывает и шифрует данные (если ESP) пакета. Не скрывает IP-адрес получателя пакета, если он маршрутизируется. Этот режим используется для связки L2TP+IPsec.
• Туннельный режим. Подписывает (если AH) и еще шифрует (если ESP) весь пакет.

Протокол IKE позволяет проводить аутентификацию клиента с использованием X.509-сертификатов, Pre-Shared Key и Extensible Authentication Protocol (EAP). Поддерживается двухэтапная аутентификация.

Все современные десктопные ОС (Windows Vista/7/8/8.1, OS X, Linux), мобильные устройства (Android, iOS, Windows Phone, Blackberry) и некоторые роутеры поддерживают VPN с использованием IPsec ESP в туннельном режиме и его настройкой через протокол Internet Key Exchange (IKE) версии 1 или 2, а значит IPsec мы именно так и будем настраивать.

Кстати, писать правильно IPsec, но Cisco IPSec.

IPsec в Linux

В OpenVZ есть поддержка IPsec, и она вполне себе годна для запуска L2TP+IPsec, но там что-то явно не так с маршрутизацией на не-локальные интерфейсы. Вероятно, это можно починить добавлением пары правил на хостовую машину, но это довольно проблематично, если у вас нет доступа к ней, как бывает во подавляющем большинстве случаев. Поэтому для OpenVZ необходимо использовать userspace IPsec, который можно собрать параметром —enable-kernel-libipsec

Жизнь со swanctl:

Жизнь без swanctl:

Нам могут потребоваться некоторые модули, которых может не быть в стандартной поставке:

• xauth-noauth — поддельный аутентификатор, позволяет вводить любой логин и пароль. Нужен для iPhone и iPad при аутентификации только по ключам, т.к. там нет возможности отключить аутентификацию по логину и паролю.
• vici — интерфейс для swanctl.
• libipsec — для userspace IPsec (для OpenVZ и, возможно, других контейнеров).

Если вас не смущает необходимость вводить логин и пароль на iPhone, вам не нужен swanctl и вы не собираетесь запускать это все в OpenVZ-контейнере, то и пересобирать ничего не нужно.
К большому сожалению, мейнтейнеры strongSwan в Debian не запаковали ничего из этого (на февраль 2015), поэтому я сделал патчик, который вы можете использовать.

Переходим к настройке

Будем настраивать подключение через IKEv2 (Windows, Linux, Blackberry), IKEv1+XAUTH (iOS, OS X, Android) и IKEv2+EAP-TLS (Windows Phone). Используем ключи, никаких PSK!
Разработчики strongSwan предлагают нам использовать команду «ipsec pki» для генерации ключей, но она настолько же неудобная, насколько и обычный openssl, поэтому я адаптировал Easy-RSA v3 из OpenVPN для генерации как OpenVPN, так и IPsec-совместимых ключей. С ним вы можете использовать одну связку ключей для двух протоколов!
github.com/ValdikSS/easy-rsa-ipsec
Easy-RSA чрезвычайно простой, поддерживать PKI-инфраструктуру с ним одно удовольствие!

Итак, инициализируем PKI и создаем CA, серверный и клиентский ключи. Важно, чтобы название серверного ключа совпадало с FQDN (доменом, проще говоря) вашего сервера!

Ключи сгенерированы. Я добавлял параметр nopass на каждом шагу, чтобы ключи не были защищены паролем (его можно установить позже в любое время).

Теперь нам необходимо скопировать их в нужные директории внутри /etc/ipsec.d/ , чтобы strongSwan нашел их:

Переходим к настройке strongSwan!
Первым делом, указываем наш приватный ключ в /etc/ipsec.secrets
Редактируем конфигурационный файл /etc/ipsec.conf

Как видите, конфигурационный файл состоит из нескольких секций. В секции config setup два закомментированных параметра: strictcrlpolicy = yes будет требовать неистекший лист отзывов для проведения аутентификации клиента, а uniqueids = no позволяет подключаться нескольким клиентам с одним сертификатом одновременно.
Далее идут секции с описаниями подключений. Секция с названием %default описывает подключение по умолчанию, от которого будут наследоваться другие подключения. Здесь устанавливаются следующие параметры:

• dpdaction=clear включает механизм Dead Peer Detection (DPD) и указывает, что нужно забывать о клиенте, если он не отзывался дольше таймаута
• dpddelay=35s — задержка до включения DPD
• dpdtimeout=300s — таймаут для DPD
• fragmentation=yes — включение внутренней фрагментации пакетов. Позволяет использовать IPsec с провайдерами, у которых сломана IP-фрагментация пакетов (привет, мобильный МТС!)
• rekey=no — выключение инициации смены ключей со стороны сервера. Windows это не любит.
• ike — перечень ciphersuites для использования с IKE (т.е. во время установки шифрованного соединения для передачи конфигурационных параметров, в том числе и ключей для установки SA)
• esp — перечень ciphersuites для шифрования трафика
• left и right — случаем все интерфейсы и принимаем всех клиентов
• leftid — указываем наш FQDN. Нужно для сломанного IKEv2 в OS X El Capitan
• leftauth/rightauth=pubkey — используем аутентификацию по ключам
• leftsubnet — подсети, которые мы отправляем клиенту для маршрутизации (весь IPv4 и IPv6-интернет). Уберите IPv6, если не используете его.
• rightsourceip — пул IP-адресов, из которого выдаем адрес клиенту. Уберите IPv6, если не используете его.
• rightdns — IP-адреса DNS-серверов

Давайте разберемся с ciphersuites в ike и esp. Здесь перечислены методы шифрования в порядке убывания приоритета, и их так много из-за того, что некоторые из них могут быть недоступны на каких-то устройствах, например, мобильных. Первым делом идут так называемые AEAD-алгоритмы, т.е. такие шифры, которые не требуют отдельного алгоритма для аутентификации, с убывающей группой Диффи-Хеллмана для реализации Perfect Forward Secrecy (PFS). Это самые быстрые шифры, которые доступны в IPsec. Хоть это и AEAD-режим, в ike должны быть алгоритмы хеширования для процесса хендшейка. Затем идет привычный AES-CBC с группами Диффи-Хеллмана. Клиентам, которые не поддерживают PFS, мы не позволим подключиться.

Если у вас нет модуля xauth-noauth для соединения ikev1-fakexauth , то вы можете заменить его просто на xauth и создать пользователя в /etc/ipsec.secrets , например, с логином и паролем client1:

Теперь у нас есть три подключения: ikev2-pubkey для IKEv2, ikev1-fakexauth для IKEv1 с фейковой проверкой логина и пароля и ikev2-eap-tls — IKEv2+EAP-TLS для Windows Phone. Перезапускаем strongSwan.

Если все верно, вы увидите следующий вывод команды swanctl -L

Проблемы MTU

Из-за особенностей и ошибок в реализации разных IPsec-клиентов, MTU внутри туннеля нельзя угадать заранее, а на Android вообще устанавливается MTU 1500, из-за чего большие пакеты не передаются и вообще ничего не работает. Чтобы нивелировать этот недостаток, достаточно изменять параметр TCP MSS в момент установки TCP-соединения на стороне сервера. Будем использовать значение 1360 для IPv4 и 1340 для IPv6, чтобы размер пакета не превышал 1400 байт внутри туннеля:

На этом настройка сервера закончена. Не забудьте настроить NAT, если вам он нужен!

Настройка клиентов

Алгоритм настройки клиентов в общих чертах заключается в импорте сертификатов из файла *.p12, создании нового подключения с типом IPsec PKI, IPsec XAUTH RSA или IKEv2 (в зависимости от устройства), указания клиентского сертификата и адреса сервера.
Внимание! Нужно вводить именно тот адрес сервера, который вы вводили при создании серверного ключа. Подключиться по другому домену или просто по IP-адресу, если сертификат был сгенерирован на домен, не получится!

Windows

OS X и iOS

Android

Вы можете использовать как IPsec-клиент Android и подключаться по протоколу IKE, так и клиент strongSwan и использовать IKEv2. Клиент strongSwan работает стабильнее и надежно переподключает в случае потери соединения.

Импортируйте сертификат либо через файловый менеджер, либо используя пункт «Установка с SD-карты» в разделе «Безопасность». Перейдите в настройки VPN, создайте новое подключение с типом «IPSec Xauth RSA», в поле «Адрес сервера» впишите, собственно, адрес сервера, в поле «Сертификат пользователя IPSec» и «Сертификат ЦС IPSec» укажите сертификат «client1». Нажмите на соединение, введите любые логин и пароль и попробуйте подключиться.

Источник