Я устанавливаю соединение IPSec от Westermo MRD310 к Cisco ASA5510 нашей компании.
У нас было много успешных установок с использованием этого метода, создания туннельной сети между удаленным местоположением и нашей внутренней сетью. На этот раз я пытаюсь выполнить эту настройку по скоростной сети GPRS (это то, что вы получаете на севере Швеции). Но это не пройдет.
Есть ли у кого-нибудь информация о том, что не удается, в следующем журнале или информация о минимальных скоростях передачи для установления туннеля IPSec. Кроме того, приветствуется любая информация о том, что может снизить требования к скорости передачи.
Я использую подписку с публичный, статический IP-адрес чтобы избежать NAT и неожиданных изменений адреса. Однако, поскольку инициатором является GPRS, статический IP-адрес не должен быть для этого требованием, я прав?
<83>Jun 21 23:00:57 ipsec__plutorun: Starting Pluto subsystem...
<27>Jun 21 23:00:57 ipsec_setup: ...Openswan IPsec started
<84>Jun 21 23:00:57 pluto[5860]: Starting Pluto (Openswan Version 2.4.12 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEKBzdY{wM]@)
<84>Jun 21 23:00:57 pluto[5860]: Setting NAT-Traversal port-4500 floating to on
<84>Jun 21 23:00:57 pluto[5860]: port floating activation criteria nat_t=1/port_fload=1
<84>Jun 21 23:00:57 pluto[5860]: including NAT-Traversal patch (Version 0.6c)
<86>Jun 21 23:00:57 ipsec__plutorun: Unknown default RSA hostkey scheme, not generating a default hostkey
<84>Jun 21 23:00:57 pluto[5860]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
<84>Jun 21 23:00:57 pluto[5860]: no helpers will be started, all cryptographic operations will be done inline
<84>Jun 21 23:00:57 pluto[5860]: Using KLIPS IPsec interface code on 2.6.25-uc0
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/cacerts'
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/aacerts'
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/ocspcerts'
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/crls'
<84>Jun 21 23:00:57 pluto[5860]: Warning: empty directory
<27>Jun 21 23:00:57 ipsec_setup: Starting Openswan IPsec 2.4.12...
<84>Jun 21 23:00:58 pluto[5860]: loading secrets from "/etc/config/ipsec.secrets"
<84>Jun 21 23:01:01 pluto[5860]: added connection description "SPMVPN"
<84>Jun 21 23:01:01 pluto[5860]: listening for IKE messages
<84>Jun 21 23:01:01 pluto[5860]: adding interface ipsec0/hso0 85.117.XXX.XX:500
<84>Jun 21 23:01:01 pluto[5860]: adding interface ipsec0/hso0 85.117.XXX.XX:4500
<84>Jun 21 23:01:01 pluto[5860]: forgetting secrets
<84>Jun 21 23:01:01 pluto[5860]: loading secrets from "/etc/config/ipsec.secrets"
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: initiating Main Mode
<27>Jun 21 23:01:02 ipsec__plutorun: 104 "SPMVPN" #1: STATE_MAIN_I1: initiate
<27>Jun 21 23:01:02 ipsec__plutorun: ...could not start conn "SPMVPN"
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: STATE_MAIN_I2: sent MI2, expecting MR2
<84>Jun 21 23:01:13 pluto[5860]: "SPMVPN" #1: ignoring informational payload, type INVALID_COOKIE
<84>Jun 21 23:01:13 pluto[5860]: "SPMVPN" #1: received and ignored informational message
<84>Jun 21 23:01:32 pluto[5860]: "SPMVPN" #1: ignoring informational payload, type INVALID_COOKIE
<84>Jun 21 23:01:32 pluto[5860]: "SPMVPN" #1: received and ignored informational message
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #1: max number of retransmissions (2) reached STATE_MAIN_I2
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #1: starting keying attempt 2 of an unlimited number
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: initiating Main Mode to replace #1
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: ignoring Vendor ID payload [FRAGMENTATION c0000000]
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: STATE_MAIN_I2: sent MI2, expecting MR2
<84>Jun 21 23:02:22 pluto[5860]: "SPMVPN" #2: ignoring informational payload, type INVALID_COOKIE
<84>Jun 21 23:02:22 pluto[5860]: "SPMVPN" #2: received and ignored informational message
<84>Jun 21 23:02:42 pluto[5860]: "SPMVPN" #2: ignoring informational payload, type INVALID_COOKIE
<84>Jun 21 23:02:42 pluto[5860]: "SPMVPN" #2: received and ignored informational message
Хорошо, парни. После перезапуска брандмауэра моей компании (из-за ошибки в ASDM я не смог запустить интерфейс ASDM после того, как время безотказной работы брандмауэра превысило 1 год), я смог прочитать сообщение журнала, поступающее на ASA 5510.
Оказывается, все это было опечатка IP-адреса в одноранговом VPN-туннеле настройка в ASA. Поменял на правильный IP адрес и гляди, все заработало!
Боюсь, это может повлиять на меня как на новичка в этой области. Но, черт возьми, я никого не обманываю и так ..
Спасибо за помощь и идеи, но иногда человеческий фактор является корнем всего плохого.
Я испытал нечто очень похожее при использовании ключа 3G. Мы предоставили всем нашим удаленным пользователям эти ключи 3G, чтобы они могли подключиться к нашей системе через VPN, находясь на сайте клиентов. В областях с низким уровнем сигнала (особенно в областях GPRS) мы часто теряли связь с VPN, однако подключение к Интернету с электронного ключа выглядело нормально.
В конечном итоге после ОЧЕНЬ долгого и разочаровывающего расследования мы определили, что GPRS-соединение на мгновение прерывается и восстанавливается, а поставщик электронного ключа выдавал другой IP-адрес DHCP. Посмотрев журналы брандмауэра, он увидел это изменение IP-адреса и подумал, что это человек в середине атаки, и прервал соединение VPN. Я не знаю, смотрит ли на это ваш брандмауэр, но, возможно, стоит посмотреть.
К сожалению, мы ничего не можем с этим поделать, но, по крайней мере, мы знаем Зачем он падает.
По какой-то причине я не могу объяснить, просто знать, почему возникает проблема, отчасти утешает, хотя я бессилен исправить это.
Когда вы говорите, что уже делали это раньше, использовали ли вы VPN-соединение этого стиля через сеть передачи данных этого сотового провайдера, используя конкретный APN, который это соединение использует?
Скорость не должна быть проблемой, по крайней мере, не на 30-60 кбит / с, которые поддерживает GPRS. Это будет медленно, но все должно работать нормально. Что гораздо более вероятно, так это то, что у сотового провайдера есть двойной NAT (по какой-то причине я не знаю почему) или тот, который специально настроен не для поддержки трафика VPN (гораздо более вероятно, что они часто это делали. чтобы заставить вас использовать бизнес-тариф).
Другая возможность - особенно с учетом местоположения - заключается в том, что их провайдер использует некоторую форму ускорителя для увеличения «нормального» интернет-трафика, и этот механизм изменяет некоторые пакеты таким образом, что квитирование IKE приводит к сбою.