>>>Что за фамильярности? А автору приношу извинения - был невнимателен.
>>
>>Даже более того - команда есть подобная и в иосе, но смысл
>>она имеет только тогда, когда сессия уже сложилась. А сама по
>>себе описываемой проблемы она не решит.
>
>Вот странно , давно я делал сейчас могу неточнг сказать , но
>если у вас клиент за Патом ,
>то в чём проблема туннель устанавливаеться клиентом до первого гетевея , он
>получает адресс , а потом его можно натить сколько угодно дальше
>же он не шифруеться и не идентифицируеться то есть получаеться
>клиент - гетевей -получили адреса тут уже далеше пойдёт обычный траф
>-- далее можно уже поднимать второй туннуль между кошкой и кошкой
>к примеру , если жу клиент одращаеться через роутер ваш к
>примеру на другой гетевей другой кошки это уже другой случай ..
>
>Так какой же случай у вас ?? что то немогу понять
Log Buffer (4096 bytes):
18.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 192.168.5.10/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel-UDP),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x400
002175: Apr 9 18:21:35.896 Moscow: IPSEC(validate_proposal_request): proposal part #2,
(key eng. msg.) INBOUND local= x.x.x.x, remote= 217.118.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 192.168.5.10/255.255.255.255/0/0 (type=1),
protocol= PCP, transform= comp-lzs (Tunnel-UDP),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x400
002176: Apr 9 18:21:35.896 Moscow: IPSEC(validate_transform_proposal): transform proposal not supported for identity:
{esp-3des esp-sha-hmac comp-lzs }
002177: Apr 9 18:21:35.896 Moscow: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= x.x.x.x, remote= 217.118.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
--More-- remote_proxy= 192.168.5.10/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-md5-hmac (Tunnel-UDP),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x400
002178: Apr 9 18:21:35.896 Moscow: IPSEC(validate_transform_proposal): transform proposal not supported for identity:
{esp-3des esp-md5-hmac }
002179: Apr 9 18:21:35.896 Moscow: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= x.x.x.x, remote= 217.118.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 192.168.5.10/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel-UDP),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x400
002180: Apr 9 18:21:35.900 Moscow: IPSEC(key_engine): got a queue event with 1 kei messages
002181: Apr 9 18:21:35.900 Moscow: IPSEC(spi_response): getting spi 3389206550 for SA
from x.x.x.x to 217.118.66.56 for prot 3
002182: Apr 9 18:21:35.904 Moscow: IPSEC(key_engine): got a queue event with 2 kei messages
002183: Apr 9 18:21:35.904 Moscow: IPSEC(initialize_sas): ,
--More-- (key eng. msg.) INBOUND local= x.x.x.x, remote= 217.118.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 192.168.5.10/0.0.0.0/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel-UDP),
lifedur= 2147483s and 0kb,
spi= 0xCA033016(3389206550), conn_id= 0, keysize= 0, flags= 0x400
002184: Apr 9 18:21:35.904 Moscow: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= x.x.x.x, remote= 217.118.66.56,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 192.168.5.10/0.0.0.0/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel-UDP),
lifedur= 2147483s and 0kb,
spi= 0xC5867503(3313923331), conn_id= 0, keysize= 0, flags= 0x408
002185: Apr 9 18:21:35.904 Moscow: IPSEC(rte_mgr): VPN Route Added 192.168.5.10 255.255.255.255 via 217.118.66.56 in IP DEFAULT TABLE
002186: Apr 9 18:21:35.904 Moscow: IPSec: Flow_switching Allocated flow for sibling 800000FE
002187: Apr 9 18:21:35.904 Moscow: IPSEC(policy_db_add_ident): src 0.0.0.0, dest 192.168.5.10, dest_port 0
002188: Apr 9 18:21:35.904 Moscow: IPSEC(create_sa): sa created,
(sa) sa_dest= x.x.x.x, sa_proto= 50,
sa_spi= 0xCA033016(3389206550),
--More-- sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 4003
002189: Apr 9 18:21:35.904 Moscow: IPSEC(create_sa): sa created,
(sa) sa_dest= 217.118.66.56, sa_proto= 50,
sa_spi= 0xC5867503(3313923331),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 4014
002190: Apr 9 18:21:36.644 Moscow: IPSEC(key_engine): got a queue event with 1 kei messages
002191: Apr 9 18:21:36.644 Moscow: IPSEC(key_engine_enable_outbound): rec'd enable notify from ISAKMP
002192: Apr 9 18:21:36.644 Moscow: IPSEC(key_engine_enable_outbound): enable SA with spi 3313923331/50
002193: Apr 9 18:21:38.176 Moscow: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection id=3
Вот такая вот петрушка получается
Здесь х.х.х.х - адрес циски.
217.118.66.56 - адрес ната провайдера.
VPN канал установился, но при доставке пакета через тунель циска не может сделать
декрипт. Какого ей надо?