Назад | Перейти на главную страницу

Неверно сформированная полезная нагрузка, полученная от брандмауэра Juniper в libreswan при настройке туннеля IPSec

У меня есть система CentOS с libreswan за маршрутизатором со статическим IP-адресом, и я пытался настроить туннель IPSec с сервером в удаленном месте с брандмауэром можжевельника. Настройки IPSec VPN на удаленном сервере выполняются через брандмауэр. Я уже перепробовал почти все возможные комбинации настроек, но каждый раз встречается одна и та же ошибка «искаженная полезная нагрузка». Ниже приведен обычный журнал, отображаемый на экране оболочки CentOS:

002 "GeojitOMS" #6: initiating Main Mode
104 "GeojitOMS" #6: STATE_MAIN_I1: initiate
003 "GeojitOMS" #6: ignoring unknown Vendor ID payload [2c9d7e81995b9967d23f571ac641f9348122f1cc1200000014060000]
003 "GeojitOMS" #6: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
003 "GeojitOMS" #6: received Vendor ID payload [Dead Peer Detection]
003 "GeojitOMS" #6: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
002 "GeojitOMS" #6: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
002 "GeojitOMS" #6: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "GeojitOMS" #6: STATE_MAIN_I2: sent MI2, expecting MR2
003 "GeojitOMS" #6: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03 sender port 500: I am behind NAT+peer behind NAT
002 "GeojitOMS" #6: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "GeojitOMS" #6: STATE_MAIN_I3: sent MI3, expecting MR3
003 "GeojitOMS" #6: next payload type of ISAKMP Hash Payload has an unknown value: 210 (0xd2)
003 "GeojitOMS" #6: malformed payload in packet
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 500ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 1000ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 2000ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 4000ms for response
003 "GeojitOMS" #6: discarding duplicate packet; already STATE_MAIN_I3

Попробовав каждую комбинацию настроек на libreswan, мне интересно, связано ли это с тем, что версия на самой CentOS несовместима с можжевельником. Это версия libreswan и ядра:

[root@localhost xyz]# rpm -qa libreswan
libreswan-3.15-5.el7_1.x86_64
[root@localhost xyz]# uname -r
3.10.0-327.4.5.el7.x86_64

Порт 500 и 4500 UDP открыты на CentOS iptables. Также разрешен весь восходящий и нисходящий трафик на маршрутизаторе Beetel для портов. Вот моя последняя настройка подключения, которая все еще не работает:

Моя локальная подсеть: 10.0.0.0/24

Удаленная подсеть: 192.168.11.0/28

Предполагается, что VPN соединяет локальный компьютер с двумя ящиками в удаленной подсети, а именно 192.168.11.11 и 192.168.11.12, которые, как мне кажется, настроены через подсеть, если только в libreswan нет способа упомянуть такие два конкретных сервера в одном соединении. Файл /etc/ipsec.d/connection.conf:

conn Connection
    auto=start
    leftid=1.2.3.4 //Some pre-defined id for local machine
    left=10.0.0.16 //LAN IP of local machine
    #leftnexthop=xxx.yyy.zzz.www // Public static IP on router
    leftsubnet=10.0.0.0/24 //local subnet
    rightid=1.2.3.5 //Some pre-defined id for remote server
    right=www.zzz.yyy.xxx //Public IP of the remote server 
    rightsubnet=192.168.11.0/28 //Remote subnet
    #rightnexthop=192.168.11.11 //Remote server IP in remote LAN? not sure
    authby=secret
    ike=3des-sha1;modp1024
    phase2=esp
    phase2alg=3des-sha1
    #pfs=no
    forceencaps=yes
    compress=yes
    #ikev2=propose
    dpdaction=restart

Файл секретов /etc/ipsec.secrets: 1.2.3.4 1.2.3.5: PSK "sharedkey"

Испытываются различные комбинации переменных в conn с включением отключения nat_traversal. Но независимо от того, какая комбинация используется, я все равно получаю ту же ошибку. Что-то не хватает в этих настройках или существует проблема совместимости между можжевельником и libreswan или конкретной версией libreswan?

Я нашел документацию libreswan полезной Вот По поводу взаимодействия с Juniper.

Я чувствую твою боль. VPN общеизвестно сложно получить просто право. Даже самая маленькая вещь может сделать соединение нестабильным и / или бесполезным. Таким образом, я не могу определить именно какая настройка, которую вы разместили выше, неверна или отсутствует, поэтому я прокомментирую несколько строк, которые могут вызывать проблемы.

phase2=esp phase2alg=3des-sha1 #pfs=no

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

сжатие = да

Сжатие должно не быть включенным, потому что это уязвимость системы безопасности.

Для справки, я успешно создал туннель libreswan <--> Juniper со следующей (обфусцированной) конфигурацией. В этой конфигурации верно следующее:

левый == локальный (libreswan) и правый == удаленный (можжевельник).
ОС - CentOS 7.2
пакет libreswan libreswan-3.15-5.el7_1.x86_64
Локальный либресван находится за NAT. Статус NAT в Juniper неизвестен.
Единственная дополнительная информация о Juniper, которую мне дали:
- Общий ключ
- Фаза 1 == "pre-gp2-aes256-sha-24h"
- Фаза 2 == "g2-esp-aes128-sha"
nat_traversal=yes в /etc/ipsec.conf

Файл конфигурации:

conn MyConnection
        ike=aes256-sha1;modp1024
        esp=aes128-sha1
        authby=secret
        keyingtries=0

        left=10.111.111.111
        leftsourceip=10.111.111.111
        leftsubnet=10.111.111.0/24

        right=1.2.3.4
        rightsubnet=10.222.222.0/24
        rightnexthop=%defaultroute

        compress=no
        auto=start