Tunnel

[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?

[infotech]

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.

[mario11584]

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

[infotech]

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?

[mario11584]

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!

[infotech]

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.' )