Prev: Using SSH to connect to a Catalyst 1900 switch
Next: Problem with VPN on ASA 5505
From: Dmitry Melekhov on 19 Nov 2007 22:21
Hello!

I need to connect two 2801 over fast ethernet with ipsec encryption.
I also need ospf so I configuring gre over ipsec:

crypto isakmp policy 15
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
crypto isakmp key hryakwesdxc address 192.168.200.241
!
!
crypto ipsec transform-set hryak ah-sha-hmac esp-aes 256
mode transport
!
crypto map hryak local-address FastEthernet0/1
crypto map hryak 10 ipsec-isakmp
set peer 192.168.200.241
set transform-set hryak
set pfs group2
match address 187
qos pre-classify

interface Tunnel0
description Hohryak-P100-GRE
bandwidth 10240
ip address 192.168.200.226 255.255.255.252
ip mtu 1440
ip route-cache policy
no ip route-cache cef
ip route-cache flow
no ip mroute-cache
qos pre-classify
tunnel source FastEthernet0/1
tunnel destination 192.168.200.241
tunnel flow egress-records


This configuration doesn't work- ping work, but only small ping,
packets larger than 100 can't reach another router over ipsec.

If I add compression to transform set
crypto ipsec transform-set hryak ah-sha-hmac esp-aes 256 comp-lzs

than all is OK except of performance- I get just about 10Mbit
throughput and 100% cpu load- with IP Input.

I guess that compression is done on CPU.
I don't need compression anyway :-)

btw, all is OK with physical channel- if I remove crypto I get about
50Mbit throughput.

Could you tell me what is wrong? How can I get ipsec working without
compression?
May be this is IOS problem (I use 12.4.17a )?
From: Dmitry Melekhov on 28 Nov 2007 07:09

Hello!

I see following on one router:

*Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MSG_LEN_ERR:
decapsulate: packet has bad bad pad length for packet: decrypt error?
length destadr=1.38.2.161, prot=50, len=8
*Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac
verify failed for connection id=4

What does it mean?
From: Mike Rahl on 28 Nov 2007 10:13
On Nov 28, 7:09 am, Dmitry Melekhov <d...(a)belkam.com> wrote:
> Hello!
>
> I see following on one router:
>
> *Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MSG_LEN_ERR:
> decapsulate: packet has bad bad pad length for packet: decrypt error?
> length destadr=1.38.2.161, prot=50, len=8
> *Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac
> verify failed for connection id=4
>
> What does it mean?

Hi, there

You could try reducing the MTU on the tunnel interface to 1360.

Also, where is the crypto map applied? I don't see it applied either
to the physical interface or the tunnel interface here.
From: Dmitry Melekhov on 28 Nov 2007 12:46
On 28 ÎÏÑÂ, 19:13, Mike Rahl <miker...(a)gmail.com> wrote:
> On Nov 28, 7:09 am, Dmitry Melekhov <d...(a)belkam.com> wrote:
>
> > Hello!
>
> > I see following on one router:
>
> > *Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MSG_LEN_ERR:
> > decapsulate: packet has bad bad pad length for packet: decrypt error?
> > length destadr=1.38.2.161, prot=50, len=8
> > *Nov 26 09:50:27.134 SAMT: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac
> > verify failed for connection id=4
>
> > What does it mean?
>
> Hi, there
>
> You could try reducing the MTU on the tunnel interface to 1360.
>

It doesn't help :-(
p100-cr2801-1#ping 192.168.200.226

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.226, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
p100-cr2801-1#ping
Protocol [ip]:
Target IP address: 192.168.200.226
Repeat count [5]:
Datagram size [100]: 200
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 200-byte ICMP Echos to 192.168.200.226, timeout is 2
seconds:
.....
Success rate is 0 percent (0/5)



> Also, where is the crypto map applied? I don't see it applied either
> to the physical interface or the tunnel interface here.


Now I'm trying to use crypto tunnel with the same result :-(

interface Tunnel0
ip address 192.168.200.225 255.255.255.252
ip mtu 1360
no ip route-cache cef
no ip route-cache
ip ospf cost 2
ip ospf mtu-ignore
tunnel source 192.168.200.241
tunnel destination 192.168.200.242
tunnel mode ipsec ipv4
tunnel protection ipsec profile hryak-p
end

the same config on another end.

and

p100-cr2801-1#sh crypto sess
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.200.242 port 500
IKE SA: local 192.168.200.241/500 remote 192.168.200.242/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map


I can't understand why it works OK with compression, and all is OK
without encryption...
From: Dmitry Melekhov on 28 Nov 2007 13:43
On 28 нояб, 21:46, Dmitry Melekhov <d...(a)belkam.com> wrote:
> On 28 ÎÏÑÂ, 19:13, Mike Rahl <miker...(a)gmail.com> wrote:
>
>
> > You could try reducing the MTU on the tunnel interface to 1360.
>
> It doesn't help :-(

btw, it is very strange, but if I set ip mtu less then 120 on far end
(not otherwise) than large (1500) pings pass.
looks like something is wrong with ethernet channel.
but I can't understand what- unencrypted traffic has no problems on
this channel...
 |  Next  |  Last
Pages: 1 2
Prev: Using SSH to connect to a Catalyst 1900 switch
Next: Problem with VPN on ASA 5505