# IPSec VPN IKEv1 между UserGate и Linux-серверов
# Симптомы

Не строится Site-to-Site VPN IKEv1 между UserGate и strongSwan, Libreswan, NSX Edge. В настройках безопасности с двух сторон указаны идентичные алгоритмы шифрования и общий ключ PSK, при подключении выдаёт "Ошибка подключения VPN-клиента - неверный общий ключ".

# Решение

Для настройки Site-to-Site VPN между UserGate и Linux-сервером вы можете воспользоваться следующей инструкцией - [https://support.usergate.com/ru/kb/version/6x/usergate-6/129-nastroyka-ipsec-vpn-tunnelya-mezhdu-usergate-i-linux-serverom](https://support.usergate.com/ru/kb/version/6x/usergate-6/129-nastroyka-ipsec-vpn-tunnelya-mezhdu-usergate-i-linux-serverom)

После корректного выполнения всех настроек в клиентском правиле UserGate при подключении может выдавать "Ошибка подключения VPN-клиента - неверный общий ключ" в трёх случаях:

1\) Туннель IPsec строится с secondary адреса внешнего интерфейса UserGate

2\) UserGate находится за NAT

3\) Linux-сервер находится за NAT

Для решения пунктов 1 и 2 можно воспользоваться параметрами идентификации в свойствах клиентского профиля безопасности начиная с версии UserGate 7.1, в котором необходимо выбрать "Тип идентификации - IPv4", 

"Значение идентификации - secondary IP для пункта 1, и серый IP, с которого будут отправляться пакеты после NAT для пункта 2". 
В версии 6.1.9 данную настройку выполнить невозможно.

Для решения пункта 3 необходимо в конфигурации Linux-сервера прописать следующий параметр:

```txt
nat-ikev1-method=both
```

# Причина

Это происходит потому, что VPN клиент UserGate в поле identification шлет IP, который не совпадает с IP адресом, с которого приходят пакеты ISAKMP, поэтому strongSwan (Libreswan, NSX Edge) в ответ шлёт auth failed.

Данная проблема уже исправлена в рамках задачи **SUM-3554**, которое вошло начиная с версии 7.1.0.