Туннель OpenSwan не устанавливается с Watchguard

Я борюсь с этой проблемой уже несколько недель. Сначала я подумал, что это на стороне Сторожевой Стражи, но похоже, что это наша сторона. Вот настройка: 1. Экземпляр EC2 под управлением Amazon Linux и OpenSwan (без iptables) 2. Другая сторона (правая сторона) под управлением WatchGuard. Туннель не настраивается. Я переношу тот же файл ipsec.conf на сервер в RackSpace, на котором работает CentoS, и туннель устанавливается. Понятия не имею почему. Я приложил файл conf и файл журнала, если кто-то может помочь. Большое спасибо.

#nual:     ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf

version 2.0 # conforms to second version of ipsec.conf specification

# basic configuration
config setup
    # Debug-logging controls:  "none" for (almost) none, "all" for lots.
    klipsdebug=all
    plutodebug=all
    # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
    protostack=netkey
    nat_traversal=yes
    #virtual_private=
    oe=off
    # Enable this if you see "failed to find any available worker"
    #nhelpers=0


#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.

include /etc/ipsec.d/*.conf

/etc/ipsec.d/conn.conf

conn TestConn
     authby=secret
     auto=start
     forceencaps=yes
        left=%defaultroute
        leftid=209.20.92.47
        leftsourceip=209.20.92.47
        leftsubnet=10.183.128.9/32
        leftnexthop=%defaultroute

     right=50.206.18.58
     rightsubnet=10.10.2.61/32


        esp=3des-sha1
        #auth=esp
        keyexchange=ike
        ike=3des-sha1;modp1024
        #salifetime=43200s
        pfs=no
        #dpdaction=restart
        #aggrmode=no

Журнал Плутона

Jan 19 19:32:24 ip-10-1-201-245 ipsec__plutorun: Starting Pluto subsystem...
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: nss directory plutomain: /etc/ipsec.d
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: NSS Initialized
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: Non-fips mode set in /proc/sys/crypto/fips_enabled
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: Starting Pluto (Openswan Version 2.6.37; Vendor ID OEu\134d\134jy\134\134ap) pid:29440
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: Non-fips mode set in /proc/sys/crypto/fips_enabled
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: LEAK_DETECTIVE support [disabled]
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: OCF support for IKE [disabled]
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: SAref support [disabled]: Protocol not available
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: SAbind support [disabled]: Protocol not available
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: NSS support [enabled]
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: HAVE_STATSD notification support not compiled in
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: Setting NAT-Traversal port-4500 floating to on
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]:    port floating activation criteria nat_t=1/port_float=1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]:    NAT-Traversal support  [enabled]
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | inserting event EVENT_REINIT_SECRET, timeout in 3600 seconds
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | event added at head of queue
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | inserting event EVENT_PENDING_DDNS, timeout in 60 seconds
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | event added at head of queue
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | inserting event EVENT_PENDING_PHASE2, timeout in 120 seconds
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | event added after event EVENT_PENDING_DDNS
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: starting up 1 cryptographic helpers
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: started helper (thread) pid=140152581191424 (fd:8)
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: Using Linux 2.6 IPsec interface code on 4.1.13-18.26.amzn1.x86_64 (experimental code)
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | status value returned by setting the priority of this thread (id=0) 22
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | helper 0 waiting on fd: 9
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | process 29440 listening for PF_KEY_V2 on file descriptor 12
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | finish_pfkey_msg: K_SADB_REGISTER message 1 for AH
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: |   02 07 00 02  02 00 00 00  01 00 00 00  00 73 00 00
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | pfkey_get: K_SADB_REGISTER message 1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | AH registered with kernel.
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | finish_pfkey_msg: K_SADB_REGISTER message 2 for ESP
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: |   02 07 00 03  02 00 00 00  02 00 00 00  00 73 00 00
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | pfkey_get: K_SADB_REGISTER message 2
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | alg_init():memset(0x558361de3500, 0, 2016) memset(0x558361de3ce0, 0, 2048)
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: sadb_msg_len=22 sadb_supported_len=72
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_add():satype=3, exttype=14, alg_id=251
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: alg[0], exttype=14, satype=3, alg_id=251, alg_ivlen=0, alg_minbits=0, alg_maxbits=0, res=0, ret=1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_add():satype=3, exttype=14, alg_id=2
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: alg[1], exttype=14, satype=3, alg_id=2, alg_ivlen=0, alg_minbits=128, alg_maxbits=128, res=0, ret=1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_add():satype=3, exttype=14, alg_id=3
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: alg[2], exttype=14, satype=3, alg_id=3, alg_ivlen=0, alg_minbits=160, alg_maxbits=160, res=0, ret=1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_add():satype=3, exttype=14, alg_id=5
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: alg[3], exttype=14, satype=3, alg_id=5, alg_ivlen=0, alg_minbits=256, alg_maxbits=256, res=0, ret=1
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_add():satype=3, exttype=14, alg_id=6
Jan 19 19:32:24 ip-10-1-201-245 pluto[29440]: | kernel_alg_register_pfkey(): SADB_SATYPE_ESP: alg[4], exttype=14, satype=3, alg_id=6, alg_ivlen=0, alg_minbits=384, alg_maxbits=384, res=0, ret=1

Изменить. Я не мог понять, что происходит с Amazon Linux / OpenSwan. Итак, я переключился на Ubuntu Linux, и с тем же файлом конфигурации туннель был установлен с первой попытки !! Обе стороны видят, что туннель установлен. Однако мы не можем пинговать. Когда я пингую, я вижу, что пакеты проходят через туннель, я вижу это с помощью tcpdump. С другой стороны мои пакеты доходят до меня. Однако ответные пакеты не доходят до моего сервера. Я подозреваю, что что-то не так с настройкой AWS. Я отключил проверку источника / назначения для экземпляра, я добавил маршрут в таблицу маршрутов подсети для маршрутизации пакетов, предназначенных для туннеля, для перехода к экземпляру, на котором запущен OpenSwan. По-прежнему не удается пинговать.

Есть идеи, почему пинг может не работать? Я также разместил это на форуме AWS, пока нет ответов. https://forums.aws.amazon.com/thread.jspa?threadID=223853&tstart=0


person user618886    schedule 20.01.2016    source источник


Ответы (1)


Открыл тикет с поддержкой AWS. Они просмотрели файлы журналов и конфигурацию и дали мне ответ на вопрос, почему туннель не устанавливается. С моей стороны это была глупая ошибка. Маршрут, подключенный к экземпляру Amazon Linux, на котором запущен OpenSwan, не имел маршрута к Интернету, поэтому он не достиг WG. Как только я добавил этот маршрут, туннель был установлен. Причина, по которой Ubuntu сработала, заключается в том, что я создал экземпляр этой машины в новой подсети, у которой был путь в Интернет. Поэтому всегда сначала пингуйте публичный ip другого конца. Я впечатлен командой поддержки AWS. Они знают, что делают.

person user618886    schedule 29.01.2016