VPN tunnel failing, not sure why

We had a LAN to LAN tunnel set up on our Watchguard firewalls.
Both FW are same make model. What are these logs telling me?

The VPN was workign for about 18 hours, went down for about 8, then just came back up out of the blue.  These are logs from during the downtime.


2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)ike_match_if_name: Match pcy [Staff_mu] dev:anyE, pkt if[3]:eth1, pri=7, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)ike_match_if_name: Match pcy [gateway.1] dev:eth1, pkt if[3]:eth1, pri=7, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Found IKE Policy [gateway.1, dev:eth1] for peer IP:xxx.xxx.35.99, numXform:1, pkt ifIndex:3, pri=7, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Process Notify Payload : NOTIFY-TYPE : 32769 , pri=7, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Process ISAKMP Notify : from peer 0x5ee42363 protocol 1 SPI e9a69400, pri=7, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)IkeNotifyPayloadHtoN : net order spi(0xe9 0xa6 0x94 0000) , pri=6, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Sending keepalive_request message to xxx.xxx.35.99:500, pri=6, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)******** RECV an IKE packet at xxx.xxx.94.146:500(socket:11 ifIndex:3) from Peer xxx.xxx.35.99:500 ********, pri=6, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)IkeNotifyPayloadNtoH : SPI Size 16 first4(0x0094a6e9), pri=6, proc_id=iked, msg_id=
2014-01-04 22:52:58      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Received a keepalive_ack message from xxx.xxx.35.99:500, pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:14      FWStatus, ******** RECV message on fd_server(7) ********, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:14      FWStatus, recv CMD XPATH(/ping), need to process it, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)ike_match_if_name: Match pcy [Staff_mu] dev:anyE, pkt if[3]:eth1, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)ike_match_if_name: Match pcy [gateway.1] dev:eth1, pkt if[3]:eth1, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Found IKE Policy [gateway.1, dev:eth1] for peer IP:xxx.xxx.35.99, numXform:1, pkt ifIndex:3, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Process Notify Payload : NOTIFY-TYPE : 32768 , pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Process ISAKMP Notify : from peer 0x5ee42363 protocol 1 SPI e9a69400, pri=7, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)******** RECV an IKE packet at xxx.xxx.94.146:500(socket:11 ifIndex:3) from Peer xxx.xxx.35.99:500 ********, pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)IkeNotifyPayloadNtoH : SPI Size 16 first4(0x0094a6e9), pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Received a keepalive_request message from xxx.xxx.35.99:500, pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)IkeNotifyPayloadHtoN : net order spi(0xe9 0xa6 0x94 0000) , pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:28      FWStatus, (xxx.xxx.94.146<->xxx.xxx.35.99)Sending keepalive_ack message to xxx.xxx.35.99:500, pri=6, proc_id=iked, msg_id=
2014-01-04 22:53:44      FWStatus, ******** RECV message on fd_server(7) ********, pri=7, proc_id=iked, msg_id=
LVL 1
wannabecraigAsked:
Who is Participating?
 
MiftaulCommented:
Was the port 500 blocked by something, may be by the ISP.

How did the log look like when IPSec was down.
0
 
JohnBusiness Consultant (Owner)Commented:
In addition to Keep Alive, you should see timeout settings in the IPsec Phases. These timeout after a period of inactivity. That may be what is causing the issue.

... Thinkpads_User
0
 
wannabecraigAuthor Commented:
This is when the IPSec was down.  port 500 should not have been blocked.
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
wannabecraigAuthor Commented:
There is no timeout set, the tunnel is set to keep alive every 30 seconds.  There was also traffic trying to be set out on that connection so it didnt go down because on inactivity.
0
 
JohnBusiness Consultant (Owner)Commented:
I have a policy in the IPsec setting for Juniper Netscreen connections that is called Policy Lifetime. I have my connection set for 8 hours but it can be set for days as well.

I am not saying this is your problem, but it may be worth investigating.

You are saying (I think) that ports are not blocked, so the Policy settings see a reasonable thing to consider.

Servers have a user settings that can allow for disconnection for 8 hours overnight (if you wish to set it).  Are you sure just the tunnel is now, or did resources it connects to go down as well.

... Thinkpads_User
0
 
wannabecraigAuthor Commented:
Just the tunnel, we have a monitor on it and it should be up constantly. There is the option for time limits on it but we have it set through always on.
0
 
MiftaulCommented:
I notice IKE phase1(udp 500) is working fine, but where is phase 2 ESP(IP 50)?
0
 
JohnBusiness Consultant (Owner)Commented:
Both phases have to be up to even connect (at least that is so for Juniper Netscreen)

I wonder if the 8 hour time frame might be a red herring. Reason:  At this point we are looking for things to be gone for 8 hours.

Is it always an 8 hour outage?  

.... Thinkpads_User
0
 
wannabecraigAuthor Commented:
There was never an 8 hour outage.  Not at this side anyway.
0
 
JohnBusiness Consultant (Owner)Commented:
Your first post says "down for 8"  which is why I asked.

So then, When it drops out, how long (normally) does it drop out for? and does it come back correctly on its own?

.... Thinkpads_User
0
 
wannabecraigAuthor Commented:
Was an ISP issue, they were blocking access.
0
 
MiftaulCommented:
Good that its identified.
Thanks.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.