PA Ipsec 2/3 phase 2 coming up only

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PA Ipsec 2/3 phase 2 coming up only

L3 Networker

Hi there,

I have a unique linux firewall box (that connects back to PA via Ipsec tunnels) on one of my sites. It is unique in the fact it requires 5 NIC's for the networks there. It only uses 3 phase 2 Ipsec tunnels which is the same on all my sites, but I have noticed some issues.

Namely that some of the time only 2 out of 3 tunnels come up. Sometimes all 3 come up, sometimes only 2. Fortunately the Main LAN always comes up, so users are not affected. Phase 1 tunnel comes up fine every time.

So I am trying to build a replacement box to test (as well as a backup in case the live one goes down), but when I boot the box up I get the Phase 1 come up fine. Then the main LAN Ipsec tunnel comes up. But for some reason it takes a very long time for that 2nd one to come up.

The original box was built by my predecessor and he left no documentation as to how he built this box.

I realize that this isn't necessarily a Palo problem, but it connects back to my PA firewall and all my other boxes of the same build are connecting without issue.

Any suggestions would be greatly appreciated. Is there perhaps some way I can monitor the Phase 2 portions of the Ipsec so that I can see what is happening? Apart from the system logs is there anywhere I can look to try help me identify the issue?

1 ACCEPTED SOLUTION

Accepted Solutions

L5 Sessionator

Hello JRussell,

On the Palo Alto firewall, you monitor ikemgr.log while phase-2 is negotiating. For that you would need to setup the ike daemon to 'debug' level and tail follow the log.

> debug ike global on debug (make sure you give this command twice to make sure that the daemon logging is set at debug level rather than info level )

**************************************

> debug ike global on debug

sw.ikedaemon.debug.global: normal

> debug ike global on debug

sw.ikedaemon.debug.global: debug

**************************************

Once that is done, you can execute the following command:

> tail follow yes mp-log ikemgr.log

2014-06-19 14:34:16.194 -0500 ikemgr: panike_daemon phase 1 finished with status 1

2014-06-19 14:34:22.829 -0500 ikemgr: panike_daemon phase 2 started

2014-06-19 14:34:22.829 -0500 pan IKE cfg phase-2 triggered.

2014-06-19 14:34:22.829 -0500 pan IKE cfg phase-2 triggered when not necessary, skipped.

2014-06-19 14:34:22.829 -0500 ikemgr: panike_daemon phase 2 finished

2014-06-20 10:51:19 [INFO]: panike_debug_level_cb 4 => 5

2014-06-20 10:51:20.603 -0500 debug: ifmon_request_put(daemon/panike_sysd_if.c:916): 16 write to pipe: debug_level

2014-06-20 10:51:20.603 -0500 debug: ifmon_request_get(daemon/panike_sysd_if.c:932): 16 read from pipe, msg type 1

.

,

.

.

and so forth....

To turn off the debugging:

> debug ike global on normal

sw.ikedaemon.debug.global: debug

The following document helps troubleshooting VPN scenarios:

How to Troubleshoot VPN Connectivity Issues

Hope that gets your started!

Thanks and regards,

Kunal Adak

View solution in original post

5 REPLIES 5

L5 Sessionator

Hello JRussell,

On the Palo Alto firewall, you monitor ikemgr.log while phase-2 is negotiating. For that you would need to setup the ike daemon to 'debug' level and tail follow the log.

> debug ike global on debug (make sure you give this command twice to make sure that the daemon logging is set at debug level rather than info level )

**************************************

> debug ike global on debug

sw.ikedaemon.debug.global: normal

> debug ike global on debug

sw.ikedaemon.debug.global: debug

**************************************

Once that is done, you can execute the following command:

> tail follow yes mp-log ikemgr.log

2014-06-19 14:34:16.194 -0500 ikemgr: panike_daemon phase 1 finished with status 1

2014-06-19 14:34:22.829 -0500 ikemgr: panike_daemon phase 2 started

2014-06-19 14:34:22.829 -0500 pan IKE cfg phase-2 triggered.

2014-06-19 14:34:22.829 -0500 pan IKE cfg phase-2 triggered when not necessary, skipped.

2014-06-19 14:34:22.829 -0500 ikemgr: panike_daemon phase 2 finished

2014-06-20 10:51:19 [INFO]: panike_debug_level_cb 4 => 5

2014-06-20 10:51:20.603 -0500 debug: ifmon_request_put(daemon/panike_sysd_if.c:916): 16 write to pipe: debug_level

2014-06-20 10:51:20.603 -0500 debug: ifmon_request_get(daemon/panike_sysd_if.c:932): 16 read from pipe, msg type 1

.

,

.

.

and so forth....

To turn off the debugging:

> debug ike global on normal

sw.ikedaemon.debug.global: debug

The following document helps troubleshooting VPN scenarios:

How to Troubleshoot VPN Connectivity Issues

Hope that gets your started!

Thanks and regards,

Kunal Adak

Thanks Kunal,

I will give that a read. But just looking at that command. Won't that give me all phase 2 negotiations? I ask because that will give me an absolute tone of data returned as we have about 40 sites, all with 3 tunnels on them.

Is there any way to refine those Ike debug to only show the one site and it's tunnels?

Ideally, you would be able to pipe the results of the tail command to grep, but there's nothing in the PAN-OS command line reference doc that indicates that's possible.

Am I missing something that would allow you to filter the output of a tail command?

You should be able to start with the system log events in the Monitor tab.  Filter for the ipsec messages here and see what top level error messages you might be getting from the failed connection.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

L3 Networker

Somehow through doing all those troubleshooting guides and mucking around with the firewall settings on the other end I managed to get it up and running.

Thanks all for your suggestions!

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!