cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1538
Views
0
Helpful
5
Replies

IPSec tunnel doesn't restore after one peer reboots

d.stepanenko
Level 1
Level 1

Hello, all,

Can anybody help in such a situation:

I have two Cisco routers, 2610 and 1720 (and two LANs behind them) connected, roughly speaking, via Internet with ipsec tunnel. And here is a problem:

If one of routers reloads, a connection between LANs does not recover automatically, although a connection between routers itself recovers easily.

I should do one of the following things to get a successful ping between LANs:

1) Either clear security associations (clear crypro sa) on the router that _did_not_ reboot or

2) Ping from the router that _did_ reboot to the opposite one. Fortunately this is possible, no matter what end of the tunnel you are on, because telnet between two cisco comes up automatically.

After this is done, all return to life, the connection between two LANs comes up, and intensive SA creation activity can be observed in debug log at this time.

But this does not satisfy me, because it is very desirable the channel to restore automatically (what if it goes down at night?)

So, did anybody encounter such a problem or does anybody know how to cure it?

Next follow the excerpts from configs. Note: both LANs use private addresses. One router (2610) lives

in 10.8.6.0/24 subnet and its tunnel interface real address is, say, x.x.x.x, another one (1720)lives in 10.8.15.0/24, and its real address is, say, y.y.y.y.

So, configs:

From 2610 side:

crypto isakmp policy 10

encryption des

hash md5

authentication rsa-encr

group 1

lifetime 86400

crypto isakmp identity address

crypto key pubkey-chain rsa

addressed-key y.y.y.y

key-string

....................................................................

quit

ip access-list extended IpsecForSlav

permit ip 10.0.0.0 0.255.255.255 any

permit ip any 10.0.0.0 0.255.255.255

permit ip host x.x.x.x host y.y.y.y

crypto ipsec transform-set Kram-SlavXfm esp-des

mode tunnel

crypto map Slav-ipsec 10 ipsec-isakmp

set peer y.y.y.y

match address IpsecForSlav

set transform-set Kram-SlavXfm

ip access-list extended SlavWall

permit icmp any host x.x.x.x

deny tcp any host x.x.x.x eq telnet

deny tcp any host x.x.x.x eq cmd

permit ip host y.y.y.y host x.x.x.x

permit ip 10.8.15.0 0.0.0.255 any

interface Serial0/0.4 point-to-point

description Slavyansk

bandwidth 64

frame-relay interface-dlci 47

frame-relay class Kram-Slav

ip address x.x.x.x 255.255.255.252

ip access-group SlavWall in

ip audit Karatzupa in

ip nat inside

ip access-group SlavWall in

ip policy route-map SvcPolicyUp

crypto map Slav-ipsec

From 1720 side:

crypto isakmp policy 10

encryption des

hash md5

authentication rsa-encr

group 1

lifetime 86400

crypto isakmp identity address

crypto key pubkey-chain rsa

addressed-key x.x.x.x

key-string

....................................................

quit

ip access-list extended IpsecForKram

permit ip 10.0.0.0 0.255.255.255 any

permit ip any 10.0.0.0 0.255.255.255

permit ip host y.y.y.y host x.x.x.x

crypto ipsec transform-set Kram-SlavXfm esp-des

mode tunnel

crypto map Kram-ipsec 10 ipsec-isakmp

set peer x.x.x.x

match address IpsecForKram

set transform-set Kram-SlavXfm

ip access-list extended KramWall

permit icmp any host y.y.y.y

deny tcp any host y.y.y.y eq telnet

deny tcp any host y.y.y.y eq cmd

permit ip host x.x.x.x host y.y.y.y

permit ip any 10.8.15.0 0.0.0.255

interface Serial0

physical-layer sync

description Kramatorsk

bandwidth 64

ip address y.y.y.y 255.255.255.252

encapsulation hdlc

ip access-group KramWall in

crypto map Kram-ipsec

5 Replies 5

cjacinto
Cisco Employee
Cisco Employee

See resiliency options on:

http://www.cisco.com/warp/public/cc/so/neso/vpn/vpne/vpne_an.htm

You might want to consider using keepalives or gre tunnels.

Thank you very much, keepalives seem to work.

What about GRE, I've tried it before and left this idea because of GRE+ipsec significant overhead and the troubles with transmitting data through SMB connections over GRE+ipsec tunnel (probably these troubles were related to the specific IOS release).

GRE adds another set of header plus now you get to IPSec protect it so you have to be careful with your

mtu sizes, because of these extra header. It would work, if you set say the mtu on the end hosts to say

1400. You could review the article on: http://www.cisco.com/warp/public/105/38.shtml

g.raymakers
Level 1
Level 1

You should enable isakmp keepalives, this will detect whether a remote peer is not available anymore and it will clear the sa's and the router(s). When the one peetr comes up again, th IPSec tunnel will be restored. The issue that you might have now is, I believe, called Stalled SA's.

Alternatively you could use GRE in IPSec tunnels and run some routing protocols over it. It all depends how the setup is. However GRE will add some additional headers to the packets, but if you run GRE/IPSec with IPSEC in transport mode, the penalty for using GRE is 'only' 4 bytes. One 'good' feature to enable when using GRE is 'ip tcp adjust-mss'. This command will make sure that any TCP session will use the TCP-MSS that is specified in the above command.

Good luck

Guy

Thank you very much. I already get a similar recommendation from CJACINTO and keepalives helped. But thanks anyway.

Now I start to incline that GRE is a better solution. But I've experimented with IPSEC+GRE before and left this idea because I've encountered some problems, probably MTU-related. Now I think I should return to the experiments with GRE.