> Конфигурация: > 10.0.2.108(Sun Host)-10.0.1.108(Sun > Gateway)<->10.0.1.109(FreeBSD > Gateway)-10.0.2.109(FreeBSD Host) > > Фаза 1 проходит нормально и шлюзы договариваются независимо > от того, кто инициатор. > Проблемы начинаются во второй фазе. > 1. Если FreeBSD является инициатором, то он шлет в качестве > идентификаторов ID: 10.0.2.109 и 10.0.2.108, а Sun-GW > возвращает ответ с другими идентификаторами(ид-ми шлюзов): > 10.0.1.109 10.0.1.108.
Не понятно, почему хост локальной сети (FreeBSD) устанавливает соединение со шлюзом (Sun-GW)?
> 2. Если же Sun-GW является инициатором, то он шлет > proposals, включающие идентификаторы 0.0.0.0(src) и > 0.0.0.0(dst). Но FreeBSD-GW сконфигурирован таким образом, > что в его базе SPDB содержатся правила (proposals) только > для туннеля с внутренними идентификаторами (inner id's): > 10.0.2.109 и 10.0.2.108.
То же самое. Шлюзы должны просто выполнять маршрутизацию пакетов. IKE пакеты заворачиваются в UDP и в таком виде должны перебрасываться в другую сеть. Если VPN натягивается на шлюзах, то почему используются внутренние адреса?
Так понимаю IKE здесь ни при чем. Здесь виновата обычная настройка маршрутизации.
Появилась проблема при настройке VPN/IPSec с использованием IKE
Конфигурация:
10.0.2.108(Sun Host)-10.0.1.108(Sun Gateway)<->10.0.1.109(FreeBSD Gateway)-10.0.2.109(FreeBSD Host)
Фаза 1 проходит нормально и шлюзы договариваются независимо от того, кто инициатор.
Проблемы начинаются во второй фазе.
1. Если FreeBSD является инициатором, то он шлет в качестве идентификаторов ID: 10.0.2.109 и 10.0.2.108, а Sun-GW возвращает ответ с другими идентификаторами(ид-ми шлюзов): 10.0.1.109 10.0.1.108. В результате, демон racoon (на FreeBSD-GW) не может договориться с in.iked (на Solaris-GW) и создать IPSec-SA между двумя шлюзами.
2. Если же Sun-GW является инициатором, то он шлет proposals, включающие идентификаторы 0.0.0.0(src) и 0.0.0.0(dst). Но FreeBSD-GW сконфигурирован таким образом, что в его базе SPDB содержатся правила (proposals) только для туннеля с внутренними идентификаторами (inner id's): 10.0.2.109 и 10.0.2.108. В результате не может быть найдено подходящего proposal'а и фаза 2 обламывается.
Если сделать финт ушами и добавить proposals с 0.0.0.0(src) и 0.0.0.0(dst) через ESP-tunnel в SPD base на FreeBSD-GW, тогда вторая фаза пройдет нормально и создадутся IPSec-SA, причем если Solaris-GW - инициатор. Если же при этом инициатором будет FreeBSD-GW - опять ничего не получиться см п.1.
<-------------Более детальная информация------------->
Конфиги для Solaris:
File -> ipsecinit.conf(IPSec политики):
{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}
## Parameters that may also show uere 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}
настройки 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
Конфиги для 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(настройки для демона racoon):
# "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;
}
> Конфигурация: > 10.0.2.108(Sun Host)-10.0.1.108(Sun > Gateway)<->10.0.1.109(FreeBSD > Gateway)-10.0.2.109(FreeBSD Host) > > Фаза 1 проходит нормально и шлюзы договариваются независимо > от того, кто инициатор. > Проблемы начинаются во второй фазе. > 1. Если FreeBSD является инициатором, то он шлет в качестве > идентификаторов ID: 10.0.2.109 и 10.0.2.108, а Sun-GW > возвращает ответ с другими идентификаторами(ид-ми шлюзов): > 10.0.1.109 10.0.1.108.
Не понятно, почему хост локальной сети (FreeBSD) устанавливает соединение со шлюзом (Sun-GW)?
> 2. Если же Sun-GW является инициатором, то он шлет > proposals, включающие идентификаторы 0.0.0.0(src) и > 0.0.0.0(dst). Но FreeBSD-GW сконфигурирован таким образом, > что в его базе SPDB содержатся правила (proposals) только > для туннеля с внутренними идентификаторами (inner id's): > 10.0.2.109 и 10.0.2.108.
То же самое. Шлюзы должны просто выполнять маршрутизацию пакетов. IKE пакеты заворачиваются в UDP и в таком виде должны перебрасываться в другую сеть. Если VPN натягивается на шлюзах, то почему используются внутренние адреса?
Так понимаю IKE здесь ни при чем. Здесь виновата обычная настройка маршрутизации.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
