topic Re: Tunnel in General Topics

Tunnel

infotech — Wed, 18 Jun 2014 15:13:40 GMT

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

Re: Tunnel

HULK — Wed, 18 Jun 2014 15:30:42 GMT

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

Re: Tunnel

infotech — Wed, 18 Jun 2014 15:45:57 GMT

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

Re: Tunnel

mivaldi — Thu, 19 Jun 2014 00:44:18 GMT

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.

Re: Tunnel

infotech — Thu, 19 Jun 2014 12:53:58 GMT

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?

Re: Tunnel

mivaldi — Thu, 19 Jun 2014 15:44:17 GMT

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

Re: Tunnel

mario11584 — Thu, 19 Jun 2014 15:53:29 GMT

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.

Re: Tunnel

infotech — Thu, 19 Jun 2014 15:53:34 GMT

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

Re: Tunnel

infotech — Thu, 19 Jun 2014 15:56:34 GMT

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

Re: Tunnel

mario11584 — Thu, 19 Jun 2014 16:04:51 GMT

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.

Re: Tunnel

infotech — Thu, 19 Jun 2014 16:10:22 GMT

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.

Re: Tunnel

mivaldi — Thu, 19 Jun 2014 16:16:19 GMT

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)

Re: Tunnel

infotech — Thu, 19 Jun 2014 16:25:41 GMT

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

Re: Tunnel

infotech — Fri, 20 Jun 2014 13:38:02 GMT

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

Re: Tunnel

mario11584 — Fri, 20 Jun 2014 15:02:24 GMT

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?

Re: Tunnel

infotech — Fri, 20 Jun 2014 15:05:57 GMT

Correct the other tunnels I have are also connectingfrom PA to ASA 5505 and using main mode. I have not used aggressive mode for the reason you just stated. It appears to be a very regular pattern of going off in the afternoon and back on the next day.

Re: Tunnel

mario11584 — Fri, 20 Jun 2014 15:10:16 GMT

What do the PA logs show during this time. Can you tell from the logs who is disconnecting or dropping the tunnel?

Re: Tunnel

infotech — Fri, 20 Jun 2014 15:15:09 GMT

I have been trying to search for the time when it actually dropped but I havent; found it yet. Is there a way on the PA to determine who dropped the traffic?

Re: Tunnel

mario11584 — Fri, 20 Jun 2014 15:41:49 GMT

Under system logs, search using the filter "( subtype eq vpn )". I'm not sure what event you would be searching for but this should be a good start. Using this filter and searching during the time it goes down should help you find what you are looking for. Good luck!

Re: Tunnel

infotech — Fri, 20 Jun 2014 16:02:48 GMT

I think this is when it is succeeding

and ( description contains 'IKE phase-2 negotiation is succeeded as responder, quick mode. Established SA: 66.94.196.107[500]-66.94.196.108[500] message id:0x1D8ADE40, SPI:0xB1874737/0xCB7EC37F.' )