BugTraq.Ru: форум / networking / Разве строчки с "my_identifier address" и "peers_identifier address" в "racoon.conf" не должны определять разные ID на инициаторе?

информационная безопасность
без паники и всерьез

подробно о проекте

Анализ криптографических сетевых...

Модель надежности двухузлового...

Специальные марковские модели надежности...

Бэкдор в xz/liblzma, предназначенный...

Три миллиона электронных замков...

Doom на газонокосилках

bugtraq.ru / форум / networking

Имя

Пароль

если вы видите этот текст, отключите в настройках форума использование JavaScript


ФОРУМ


регистрация

Легенда:

новое сообщение

закрытая нитка

новое сообщение

в закрытой нитке

старое сообщение

Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
Новичкам также крайне полезно ознакомиться с данным документом.

Разве строчки с "my_identifier address" и "peers_identifier address" в "racoon.conf" не должны определять разные ID на инициаторе? 03.02.04 15:54 Число просмотров: 1895
Автор: Damage Статус: Незарегистрированный пользователь

<"чистая" ссылка>

> > isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
> > 2004-02-02 16:37:36: DEBUG:
> > isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
> > 2004-02-02 16:37:36: DEBUG:
>
> Это должны быть initiator ID и responder ID
> соответственно. Поля эти используются опционально и их
> использование зависит от решения инициатора соединения.
> Одинаковые ID - это не правильно. Посмотрите настройки
> (если они есть) параметров использования этих полей (в
> приведенных настройках я их не увидел, там содержатся
> только параметры контекста безопасности).
>

См. строчку в приведенном файле racoon.conf в разделе remote anonymous:
....
remote anonymous
{
# exchange_mode main,aggressive;
exchange_mode aggressive, main;
doi ipsec_doi;
#situation identity_only;

#my_identifier address;
------>my_identifier address 10.0.1.109; #user_fqdn "sakane@kame.net";
------>peers_identifier address 10.0.1.108; # user_fqdn "sakane@kame.net";
#certificate_type x509 "mycert" "mypriv";
...

Разве эти строчки не должны определять разные ID на инициаторе (в данном случае - FreeBSD Gateway)?

Trouble,configuring ipsec tunnel with ike within solaris9 and freebsd. 02.02.04 20:02 [JINN, !mm, fly4life, ZaDNiCa]
Автор: Damage Статус: Незарегистрированный пользователь

<"чистая" ссылка>

There is an aim to establish tunnel 10.0.2.108 (Solaris Host) - 10.0.1.108 (Solaris Gateway) < - > 10.0.1.109 (FreeBSD Gateway) - 10.0.1.109 (FreeBSD Host).
If Solaris-Gateway is Initiator and FreeBSD-Gateway is Responder then -> all ok. But if FreeBSD is Initiator there is touble on Phase 2 of IKE proceccing.

Here is configs for Solaris:
File -> ipsecinit.conf:
{laddr 10.0.1.108 raddr 10.0.1.109} ipsec {encr_algs any encr_auth_algs any sa shared}
{laddr 10.0.1.109 raddr 10.0.1.108} ipsec {encr_algs any encr_auth_algs any sa shared}

File -> ike.config:
## Phase 1 transform defaults...

p1_lifetime_secs 30 # 14400
p1_nonce_len 16 #40
p2_nonce_len 16
#p2_lifetime_secs 30

## Parameters that may also show up in rules.

p1_xform { auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des }
p2_pfs 1 # 2

### Now some rules...

{
label "sun-ca_server"
local_id_type ipv4
local_addr 10.0.1.108
remote_addr 10.0.1.109

p2_pfs 1

p1_xform
{auth_method preshared oakley_group 5 auth_alg md5 encr_alg 3des}
}

File -> ike.preshared:
{ # sun-ca_server preshared
localidtype IP
localid 10.0.1.108
remoteidtype IP
remoteid 10.0.1.109
#preshared key
key 282828282828282828282129292929292929292929
}

ifconfig trace(Solaris):
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
le0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.1.108 netmask ffffff00 broadcast 10.0.1.255
ether 8:0:20:91:ce:e7
le0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.0.108 netmask ffffff00 broadcast 10.255.255.255
le0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.2.108 netmask ffffff00 broadcast 10.255.255.255
ip.tun0: flags=10028d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED,IPv4> mtu 1480 index 4
inet tunnel src 10.0.1.108 tunnel dst 10.0.1.109
tunnel security settings esp (3des-cbc/hmac-md5)
tunnel hop limit 60
inet 10.0.2.108 --> 10.0.2.109 netmask ffffff00

Here is configs for FreeBSD Gateway:

Ipsec policy File:

spdadd 0.0.0.0 0.0.0.0 any -P out ipsec esp/tunnel/10.0.1.109-10.0.1.108/require;
spdadd 0.0.0.0 0.0.0.0 any -P in ipsec esp/tunnel/10.0.1.108-10.0.1.109/require;

spdadd 10.0.2.109 10.0.2.108 any -P out ipsec esp/tunnel/10.0.1.109-10.0.1.108/require;
spdadd 10.0.2.108 10.0.2.109 any -P in ipsec esp/tunnel/10.0.1.108-10.0.1.109/require;

IKE daemon File -> racoon.conf:

# "padding" defines some parameter of padding. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}

# if no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
#isakmp ::1 [7000];
#isakmp 202.249.11.124 [500];
#admin [7002]; # administrative's port by kmpstat.
#strict_address; # required all addresses must be bound.
}

# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec; # maximum interval to resend.
persend 1; # the number of packets per a send.

# timer for waiting to complete each phase.
phase1 30 sec;
phase2 30 sec;
}

remote anonymous
{
# exchange_mode main,aggressive;
exchange_mode aggressive, main;
doi ipsec_doi;
#situation identity_only;

#my_identifier address;
my_identifier address 10.0.1.109; #user_fqdn "sakane@kame.net";
peers_identifier address 10.0.1.108; # user_fqdn "sakane@kame.net";
#certificate_type x509 "mycert" "mypriv";

nonce_size 16; #40; #was: 20;
lifetime time 30 sec; #14400 sec; # 1 min; # sec,min,hour
initial_contact off;
#support_mip6 on;
proposal_check obey; # obey, strict or claim

proposal {
encryption_algorithm 3des;
hash_algorithm md5; # sha1;
authentication_method pre_shared_key ;
dh_group 5;
}
}

sainfo anonymous
{
pfs_group 1; # 2;
lifetime time 30 sec; #1 min;
encryption_algorithm 3des; #des; #tested: rijndael,
authentication_algorithm hmac_md5; #hmac_sha1; # non_auth;
compression_algorithm deflate ;
}

File -> preshared.secret:

10.0.1.108 ((((((((((!))))))))))

ifconfig trace(FreeBSD):
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.109 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:05:5d:34:fc:21
media: Ethernet autoselect (10baseT/UTP)
status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.1.109 netmask 0xffffff00 broadcast 10.0.1.255
inet 10.0.2.109 netmask 0xffffff00 broadcast 10.0.2.255
ether 00:05:5d:4c:5f:ef
media: Ethernet autoselect (10baseT/UTP)
status: active
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 10.0.1.109 --> 10.0.1.108
inet 10.0.2.109 --> 10.0.2.108 netmask 0xffffff00

RESULT:
1.FreeBSD# ping 10.0.2.108
100 % packets lost
2.tcpdump trace: (slompster is 10.0.1.109 (FreeBSD Gateway))
18:32:42.488416 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 1 I agg: [|sa]
18:32:43.215390 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 1 R agg: [|sa] (DF)
18:32:43.295001 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 1 I agg: (hash: len=16)
18:32:43.296546 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 2/others R inf[E]: [encrypted hash] (DF)
18:32:43.313588 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
18:32:43.387263 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 2/others R oakley-quick[E]: [encrypted hash] (DF)
18:32:43.392910 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I inf[E]: [encrypted hash]
18:32:54.555184 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
18:33:14.684040 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
18:33:27.930264 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 1 I agg: [|sa]
18:33:28.657742 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 1 R agg: [|sa] (DF)
18:33:28.730229 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 1 I agg:
(hash: len=16)
18:33:28.731661 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 2/others R inf[E]: [encrypted hash] (DF)
18:33:28.743277 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
18:33:28.818771 10.0.1.108.isakmp > slompster.isakmp: isakmp: phase 2/others R oakley-quick[E]: [encrypted hash] (DF)
18:33:28.824801 slompster.isakmp > 10.0.1.108.isakmp: isakmp: phase 2/others I inf[E]: [encrypted hash]
3. racoon.log
...
2004-02-02 16:37:36: DEBUG: oakley.c:2710:oakley_do_decrypt(): decrypted.
2004-02-02 16:37:36: DEBUG: plog.c:193:plogdump():
8bae6d6d a941c531 5f9c6529 1d000000 08102001 0618e42b 0000009c 01000014
059b5e83 ea341be0 6b6fa9f0 14de7b70 0a000030 00000001 00000001 00000024
01030401 3eadd611 00000018 01030000 80010001 8002001e 80040001 80050001
05000024 a5eb15b2 e621bf05 4d2d04fa 53c8e7eb 174e2057 951f97ed bec12312
cd95f5f5 0500000c 01000000 0a00016d 0000000c 01000000 0a00016c
2004-02-02 16:37:36: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin.
2004-02-02 16:37:36: DEBUG: isakmp.c:1112:isakmp_parsewoh(): begin.
2004-02-02 16:37:36: DEBUG: isakmp.c:1139:isakmp_parsewoh(): seen nptype=8(hash)
2004-02-02 16:37:36: DEBUG: isakmp.c:1139:isakmp_parsewoh(): seen nptype=1(sa)
2004-02-02 16:37:36: DEBUG: isakmp.c:1139:isakmp_parsewoh(): seen nptype=10(nonce)
2004-02-02 16:37:36: DEBUG: isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
2004-02-02 16:37:36: DEBUG: isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
2004-02-02 16:37:36: DEBUG: isakmp.c:1178:isakmp_parsewoh(): succeed.
2004-02-02 16:37:36: ERROR: isakmp_quick.c:439:quick_i2recv(): mismatched ID was returned.
2004-02-02 16:37:36: ERROR: isakmp.c:710:quick_main(): failed to pre-process packet.
...
2004-02-02 16:37:36: DEBUG: isakmp_inf.c:634:isakmp_info_send_common(): sendto Information notify.
2004-02-02 16:37:36: ERROR: isakmp.c:529:isakmp_main(): phase2 negotiation failed.
2004-02-02 16:37:36: DEBUG: schedule.c:210:sched_scrub_param(): an undead schedule has been deleted.
2004-02-02 16:37:36: DEBUG: schedule.c:210:sched_scrub_param(): an undead schedule has been deleted.

HELP PLEASE.

Это должны быть initiator ID и responder ID соответственно... 03.02.04 12:59
Автор: lunc <Alexander Krizhanovsky> Статус: Member

<"чистая" ссылка>

> isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
> 2004-02-02 16:37:36: DEBUG:
> isakmp.c:1139:isakmp_parsewoh(): seen nptype=5(id)
> 2004-02-02 16:37:36: DEBUG:

Это должны быть initiator ID и responder ID соответственно. Поля эти используются опционально и их использование зависит от решения инициатора соединения. Одинаковые ID - это не правильно. Посмотрите настройки (если они есть) параметров использования этих полей (в приведенных настройках я их не увидел, там содержатся только параметры контекста безопасности).

2JINN & Imm0rtal:
За что штраф?

Разве строчки с "my_identifier address" и "peers_identifier address" в "racoon.conf" не должны определять разные ID на инициаторе? 03.02.04 15:54
Автор: Damage Статус: Незарегистрированный пользователь

<"чистая" ссылка>

Я ошибся... 03.02.04 17:38
Автор: lunc <Alexander Krizhanovsky> Статус: Member

<"чистая" ссылка>

Строки seen nptype=5(id) - это тип обрабатываемого поля (ID), а не его содержимое.

Так понимаю, что то, что выдол plogdump - проблемный пакет. Есть утилита petscview для просмотра таких дампов (сейчас FreeBSD под рукой нет).
В ручную разобрать не получается. Исходя из формата IKE пакета первые 4 и 4-е 4 байта с конца - адреса респондера и инициатора соответственно.

Возможно вообще отключить использование идентификационных частей?

Page build time: 0 s

Design: Vadim Derkach