LINUX.ORG.RU
решено ФорумAdmin

Cisco <-> Linux туннель GRE + IPSEC

 , , , ,


0

1

Добре Вам,

уже третьи сутки бьюсь головой об клаву, не могу победить IPSEXC.

Ситуация: две локалки, GRE туннели между ними, с одной стороны Cisco с последней прошивкой ADVIPSERVICESK9-M Version 12.4(24)T8, с другой стороны сервачок с openSUSE 13.1 на борту + ipsec-tools-0.7.3. Нужно туннель зашифровать.

Сейчас пытаюсь разобраться c IPSEC, так что туннель пока потушен с обоих концов. Пытаюсь добиться чтобы просто хотя бы ходил трафик в шифрованном виде между этими двумя точками.

На линухе айпишник 1.1.1.1, на циске 2.2.2.2.

Конфиг на циске:

crypto isakmp policy 30
 encr aes 
 authentication pre-share
 group 5  
 lifetime 28800
crypto isakmp key fxPJ941oLxesoq8F1nDrMtSBTrbl3MiG address 1.1.1.1
!         
crypto ipsec transform-set SUN_SET esp-aes esp-sha-hmac 
!         
crypto map SUN 30 ipsec-isakmp 
 description SUN_TUN_KZT
 set peer 1.1.1.1
 set transform-set SUN_SET 
 match address 110
!
ip access-list extended BLA
 permit ip host 2.2.2.2 host 1.1.1.1
 permit ip host 1.1.1.1 host 2.2.2.2
!
interface FastEthernet0/0
 ip address 2.2.2.2 255.255.255.248
 crypto map SUN
!

На линухе, racoon.conf:

remote anonymous
{
    exchange_mode aggressive,main;
    doi ipsec_doi;
    situation identity_only;
    my_identifier address 1.1.1.1;
    peers_identifier address 2.2.2.2;
    lifetime time 8 hour;
    passive off;
    proposal_check obey;
    generate_policy off;

    proposal {
        encryption_algorithm aes 128;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        lifetime time 28800 sec;
        dh_group 5;
    }
}

sainfo anonymous
{
    pfs_group 5;
    lifetime time 28800 sec;
    encryption_algorithm aes 128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

setkey.conf

flush;
spdflush;

spdadd 1.1.1.1 2.2.2.2 any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require;
spdadd 2.2.2.2 1.1.1.1 any -P in ipsec esp/tunnel/1.1.1.1-2.2.2.2/require;

psk.txt

2.2.2.2 fxPJ941oLxesoq8F1nDrMtSBTrbl3MiG

В итоге с логах все хорошо... циска:

*Dec  4 14:34:01.770: IPSEC(create_sa): sa created,
  (sa) sa_dest= 2.2.2.2, sa_proto= 50, 
    sa_spi= 0x17516333(391209779), 
    sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 35
    sa_lifetime(k/sec)= (4581842/3600)
*Dec  4 14:34:01.770: IPSEC(create_sa): sa created,
  (sa) sa_dest= 1.1.1.1, sa_proto= 50, 
    sa_spi= 0x67A1DC4(108666308), 
    sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 36
    sa_lifetime(k/sec)= (4581842/3600)

линуха:

2013-12-04T14:14:48.651365+06:00 sun racoon: INFO: IPsec-SA established: ESP/Tunnel 1.1.1.1[500]->2.2.2.2[500] spi=391209779(0x17516333)

Пинги не ходят.

Запускаю пинг в количестве 1 шт. имотрю tcpdump на линухе... С линухи на циску:

14:10:43.166677 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x53fa4b7c,seq=0x10), length 132
14:10:43.175262 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0a5e45e5,seq=0x10), length 132
14:10:43.175262 IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 22116, seq 1, length 64
С циски на линуху:
14:10:55.471651 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0a5e45e5,seq=0x11), length 148
14:10:55.471651 IP 2.2.2.2 > 1.1.1.1: ICMP echo request, id 43, seq 0, length 80

То есть с линухи уходит ICMP пакет в зашифрованном виде, приходит 1 пакет с ответом в зашифрованном виде и 1 в открытом? Или это так tcpdump отображает один и тот же пакет до и после расшифровки? С циски пинг так же приходит по два раза, в зашифрованном виде и в открытом. Линуха при этом не отвечает.

Если мониторить со стороны циски... пинг с циски на линуху:

*Dec  4 14:51:24.774: IP: s=2.2.2.2 (local), d=1.1.1.1 (FastEthernet0/0), len 100, sending
*Dec  4 14:51:24.774: IP: s=2.2.2.2 (local), d=1.1.1.1 (FastEthernet0/0), len 100, output feature, IPSec output classification(25), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec  4 14:51:24.774: pak 47A81C50 consumed in output feature , packet consumed, IPSec: to crypto engine(54), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec  4 14:51:24.774: IP: s=2.2.2.2 (local), d=1.1.1.1 (FastEthernet0/0), len 168, post-encap feature, (1), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec  4 14:51:24.774: IP: s=2.2.2.2 (local), d=1.1.1.1 (FastEthernet0/0), len 168, post-encap feature, FastEther Channel(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec  4 14:51:24.774: IP: s=2.2.2.2 (local), d=1.1.1.1 (FastEthernet0/0), len 168, sending full packet

Видно, что зашифрован и отправлен 1 пакет, ответа от линухи нет. Копии пакета в открытом виде нет, так что скорее всего tcpdump показывает действительно пакеты по два раз.

Вот и получается фигня какая-то, IPSEC договорились, пакеты ходят, но связи нет. Видно, что загвоздка в линухе... но где копать?

Прошу помощи у более опытных специалистов, чем я, настроивших over 0 IPSEC каналов. На третьи сутки уже ум за разум заходит.


Или это так tcpdump отображает один и тот же пакет до и после расшифровки?

Ага.
Сам я енота не настраивал, все больше pluto, но давай глянем вот что:
твой setkey.conf:

spdadd 1.1.1.1 2.2.2.2 any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require;
spdadd 2.2.2.2 1.1.1.1 any -P in ipsec esp/tunnel/1.1.1.1-2.2.2.2/require;
setkey.conf из интернетов:
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec esp/tunnel/192.168.1.100-192.168.2.100/require;
spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/192.168.2.100-192.168.1.100/require;
Т.е. в эталонном конфиге твоя вторая строчка выглядела бы как .../2.2.2.2-1.1.1.1/...
А вообще это пальцем в небо.
Покажи
ip xfrm policy list
ip xfrm state list
при поднятом тоннеле.
Ну и иптаблесы заодно.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Епт... спасибо, заработало. /Стыдоба то какая :)

В голове уже каша. Сначала пытался сразу прикрутить с туннелем к рабочей конфигурации, но потом решил начать с основы.

Так, как это еще не конец, прошу тему пока не крыть.

ZigmunD
() автор топика
Ответ на: комментарий от blind_oracle

Лучше с енота на StrongSwan переходи, там всё гораздо проще.

Сейчас этим и занимаюсь.

С енотом еще одна болячка приключилась - при обрыве связи не хочет переподнимать IPSEC, пока циска это дело не инициирует.

В частности: со стороны линухи хоть запингуйся, не будет связи. Со стороны циски достаточно одного пакета, IPSEC поднимется и связь восстановится в течении секунды.

ZigmunD
() автор топика
Ответ на: комментарий от blind_oracle

Поднял стронгсван - тоже сам не переподнимает связь без пинка со стороны циски.

В принципе, это не страшно, потому как все равно раз в пару секунд по туннелю будут пакеты ospf бегать. Просто интересно что за бабуйня и как ее победить.

ZigmunD
() автор топика
Ответ на: комментарий от ZigmunD

Поднял стронгсван - тоже сам не переподнимает связь без пинка со стороны циски.

Настрой DPD (Dead Peer Detection), будет инициировать сам.

У меня между 2мя линухами примерно так:

config setup
    plutostart=no
    charondebug="ike 0, enc 0, net 0"

conn %default
    ikelifetime=360m
    keylife=60m
    rekeymargin=10m
    keyingtries=%forever
    authby=secret
    mobike=no
    keyexchange=ikev2
    compress=yes
    ike=aes256gcm128-sha2_512-modp4096!
    esp=aes128gcm64-modp4096!
    type=transport

    closeaction=clear
    dpdaction=restart
    dpddelay=60s

    auto=start

conn xxx
    left=1.1.1.1
    right=2.2.2.2

blind_oracle ★★★★★
()

Появилась еще одна проблема - как на циске задать source ip для IPSEC соединения?

Ситуация: есть два интерфейса, первый - WAN с ипом 1.1.1.2. второй - локалка с реальными внешними адресами 2.2.2.0/24, на циске 2.2.2.1 дефолт гв - 1.1.1.1

Весь трафик уходит в мир через WAN с ипом 1.1.1.1. Нужно либо в одном из IPSEC-соединений задать явно source ip 2.2.2.1, потому что на другом конце IPSEC настроен на этот ип. Или же поставить source ip 2.2.2.1 для определенного назначения, аналог линухового: iptables -t nat -A POSTROUTING -d 3.3.3.3 -j SNAT --to-source 2.2.2.1

Хотелось бы обойтись без ната и поберечь ресурсы, так как трафик будет не маленький, а еще плюс 3 IPSEC соединения.

ZigmunD
() автор топика
Ответ на: комментарий от ZigmunD

Или аналогичная ситуация: на одном интерфейсе 2 ипа - 1.1.1.1 праймари и 2.2.2.1 секондари. 2 IPSEC соединения, настроенные на эти два ипа и работает только то, которое на 1.1.1.1 настроено, так как трафик выходит всегда с праймари source ip.

ZigmunD
() автор топика

Лучше новую тему создам, так как первоначальная проблема решена.

ZigmunD
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.