Tunnel

[infotech]

I have a vpn tunnel that works fine most of the time and then is just goes down for no reason any suggestion

[HULK]

Hello Infotech,

Is there any continuous traffic flowing through that IPsec tunnel..? Or did you identify a pattern i.e after every 8 Hrs or 24 Hrs the tunnel is going down.

Thanks

[infotech]

there isn't continuous traffic flowing down the tunnel. I haven't identifiy a specific pattern but it does seem to go down int he afternoon and is up again the next morning. I would be so concerned but none of the other tunnels configured similiar configuration and traffic

[mivaldi]

When there is no traffic traversing the tunnel, the tunnel will go down after it times out.

You can select an arbitrary private /30 network, and configure the IP addresses to the Tunnel Interfaces at the end of both tunnels.

Example:

172.16.0.0/30

IP on Tunnel Interface Endpoint A:

172.16.0.1

IP on Tunnel Interface Endpoint Z

172.16.0.2

If one of the two endpoints is the tunnel initiator, go to that endpoint. Select (Network> IPSec Tunnels: <Your Tunnel>)

(If the initiator was "Endpoint A" in our example...)

Once opened, mark the checkbox for "Tunnel Monitor". Enter the IP address of Endpoint Z. You can leave the Profile on None.

This will cause ICMP packets to be sent every few seconds, thus maintaining the tunnel up at all times.

You don't need to configure Tunnel Monitor at both ends, unless you need it. In some cases configuring it at both ends can cause the tunnel to flap.

[infotech]

But shouldn't I be able to bring it back up by doing a test and shouldn't the other used tunnels with the same configuration do the same thing?

[mivaldi]

They should do the same thing, unless a single packet traverses the tunnel before the tunnel times out, thereby keeping the tunnel alive.

[mario11584]

I've had this problem before too. I worked through this doc (Dead Peer Detection and Tunnel Monitoring) and it seemed to help. Tunnel monitoring will use pings over the tunnel to monitor the other side. The ping traffic will keep the tunnel up.

[infotech]

So shouldn't I be able to bring the tunnel back up by doing a test?

[infotech]

I will take a look at the document, Its just odd that is up until the afternoon goes down and then is back up the next morning. The other tunnels are configured the same an they don't do this. I was also trying to bring the tunnel back up by running a test and that didn't work either

[mario11584]

I understand the frustration. I had the exact same problem. It was only occurring on one tunnel and not the others. Its like the others are saying, the tunnel is "dying" because there isn't any traffic traversing it so it times out. Why it can't renegotiate after the timeout and come back up is beyond me. The cure is to keep it from dying and tunnel monitoring should resolve that. It will need to rekey once in a while but that should be transparent and nobody should notice any interruption in the tunnel. Also, if phase 1 is going down, but phase 2 is up...your traffic should still be able to cross the tunnel. Phase 1 sets up the agreements needed for phase 2. Phase 2 is used to determine encryption parameters for bulk data encryption. Phase 2 is the important phase, although phase 2 doesn't exist without phase 1. I hope this helps a little.

[infotech]

Exactly Mario

On the other side is a cisco firewall and when it is not working it give me the an SA error and I have no idea why because I didn't change anything.

[mivaldi]

If the initiator is the Palo Alto Networks firewall, you can bring the tunnel up with a test from the CLI like:

> test vpn ike-sa gateway <gateway_name>  (will bring Phase 1 up)

> test vpn ipsec-sa tunnel <tunnel_name> (will bring Phase 2 up)

[infotech]

Yes that what I was trying to do and it did not come up, I think mario hit it on the nail with the SA's

[infotech]

Here is what I am seeing when the tunnel is up

Parkway_IPSec_Tunnel5:DR_Networkactive

id 139
tunnel  Parkway_IPSec_Tunnel5:DR_Network
        id:                     139
        type:                   IPSec
        gateway id:             5
        local ip:               66.94.196.107
        peer ip:                66.94.196.108
        inner interface:        tunnel.5
        outer interface:        ethernet1/3
        state:                  active
        session:                184664
        tunnel mtu:             1428
        lifetime remain:        20799 sec
        latest rekey:           8001 seconds ago
        monitor:                off
        monitor packets seen:   0
        monitor packets reply:  0
        en/decap context:       100
        local spi:              B1874737
        remote spi:             CB7EC37F
        key type:               auto key
        protocol:               ESP
        auth algorithm:         SHA1
        enc  algorithm:         AES256
        proxy-id local ip:      10.135.100.0/24
        proxy-id remote ip:     10.135.11.0/25
        proxy-id protocol:      0
        proxy-id local port:    0
        proxy-id remote port:   0
        anti replay check:      yes
        copy tos:               no
        authentication errors:  0
        decryption errors:      0
        inner packet warnings:  0
        replay packets:         0
        packets received
          when lifetime expired:0
          when lifesize expired:0
        sending sequence:       212815
        receive sequence:       200841

[mario11584]

You said you're connecting the PA to an ASA? I would only recommend this for troubleshooting, but have you tried aggressive mode? When I used to work with ASAs, once upon a time, I found that different vendors didn't play well with ASAs (or vice versa, however you choose to look at it). I had to use aggressive mode. Which I don't recommend btw because they are less secure because plain text is used and reveals data about the endpoints. I'd say it's worth a shot though to see if that stabilizes the tunnel. Just a thought. Do you have other tunnels connecting to ASAs or just this one?