cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
459
Views
0
Helpful
1
Replies

Tunnel dies and can't be re-established

seth_fox
Level 1
Level 1

We're using two PIX firewalls (506 and 515) between two sites to establish a tunnel. We have no problem getting the initial tunnel working, and traffic routes fine over said tunnel for the entire day. It seems as though the tunnel dies around the same time each night (~10:30PM), and cannot be re-established until the routes are removed on the 515 and re-built (where the smaller lab is forwarding all traffic, including internet, over the tunnel...ie. the 515 acts as a hub in our architecture). To add to the equation, the 515 has a pretty comprehensive routing table to handle this internet traffic (see below), sending it to an internal router, which then routes it to another firewall, and out to the internet.

We've tried manipulating different timeouts (xlate, conn, arp), reducing the size of the MTU to 1400, and changing the lifetime of the tunnel anywhere from 1000 seconds to 43200 (12 hours). The behavior seems to happen regardless of these changes.

The routes are as follows (with 9.26.192.1 being the internal router, and the specific 9.26.x.x subnets being our internal addresses):

route inside 0.0.0.0 248.0.0.0 9.26.192.1 1

route outside 0.0.0.0 0.0.0.0 204.138.98.2 1

route inside 8.0.0.0 255.0.0.0 9.26.192.1 1

route inside 9.0.0.0 255.240.0.0 9.26.192.1 1

route inside 9.16.0.0 255.248.0.0 9.26.192.1 1

route inside 9.24.0.0 255.254.0.0 9.26.192.1 1

route inside 9.26.0.0 255.255.128.0 9.26.192.1 1

route inside 9.26.128.0 255.255.192.0 9.26.192.1 1

route inside 9.26.196.0 255.255.254.0 9.26.192.1

route inside 9.26.200.0 255.255.252.0 9.26.192.1

route inside 9.26.208.0 255.255.240.0 9.26.192.1 1

route inside 9.26.224.0 255.255.224.0 9.26.192.1 1

route inside 9.27.0.0 255.255.0.0 9.26.192.1 1

route inside 9.28.0.0 255.252.0.0 9.26.192.1 1

route inside 9.32.0.0 255.224.0.0 9.26.192.1 1

route inside 9.64.0.0 255.192.0.0 9.26.192.1 1

route inside 9.128.0.0 255.128.0.0 9.26.192.1 1

route inside 11.0.0.0 255.0.0.0 9.26.192.1 1

route inside 12.0.0.0 252.0.0.0 9.26.192.1 1

route inside 16.0.0.0 240.0.0.0 9.26.192.1 1

route inside 32.0.0.0 224.0.0.0 9.26.192.1 1

route inside 64.0.0.0 192.0.0.0 9.26.192.1 1

route inside 128.0.0.0 128.0.0.0 9.26.192.1 1

This works perfectly for several hours, but as I said previously, dies once activity and traffic over the tunnel starts to decrease. Until these routes are flushed, it looks as if tunnel creation is attempted on the PIX's, but doing a 'show crypto isakmp sa' reveals that the PIX that initiates the tunnel remains in a MM_NO_STATE and the other PIX is in a MM_SA_SETUP state. As well, a 'show crypto ipsec sa' shows that nothing is being encrypted, and only send errors are showing.

Any help would certainly be appreciated. Thanks.

1 Reply 1

lmessenger
Level 1
Level 1

Have you tried clearing the SA's and running a Debug IP Packet, whilst getting the Tunnel to re-establish. It could be you have an access-list that is stopping the traffic going to or from the other PIX to initiate the tunnel

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: