- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-12-2015 06:45 AM
I am having some issues as well with 6.1.2 and LSVPN to hub which is on 6.0.5h3. This is vaguely referenced here by others Anyone use 6.1.2? Is it stable where everyone affected, says yeah there's this IPSEC issue and never actually describes what they are seeing. So I'm going to detail what I am seeing.
I had two PA-200 devices overnight go offline, same ISP(Could have been coincidence) on US-EST but at different times. My routers could see each other properly at either end but the PA-200 satellite devices would not respond on their public facing IP's at all. I could route right up to the devices but could not get in on https via port 4443 or via ssh. Definitely seemed like a bug that might have been caused by some blip in the ISP maybe but the only way to fix it was to reboot the devices. As soon as they rebooted LSVPN came back up.
Reading through the satellite's syslogs at the time the device went down, there's no particular indication other than 'GlobalProtect Satellite connection to gateway failed. Satellite failed to connect to Gateway 'IP-w.x.y.z' due to "connection failed".' This error continued until we rebooted the PA-200's at which point they immediately came back. Devices showed in ARP on routers and everything but they wouldn't respond whatsoever to any Layer3 requests/comm. It's like the security and interface management policies just plain failed.
*** An additional but somewhat related issue I have been having is with devices indicating active LSVPN connections but in fact they are not passing any traffic. Tunnel monitor is set to the hub device's tunnel interface IP. This only happens to one device at a time and all other of my 40 or so PA-200's stay active without issue. It seems sometimes this happens when the IP changes in a failover scenario and others it seems like it just drops off after a rekey. I know there are some fixes in indicated in 6.1.2 for this and since my hubs are not yet on 6.1.2 I did not reach out to support on this yet. But now I don't think we can go to 6.1.2 if there is a known bug/issue. I had to have people drive in and reboot these thigns in the middle of the night. Needless to say they are not feeling very happy about our 'upgrade' to Palo Alto from tried and true but old Netscreen/SSGs.
03-18-2015 06:18 AM
This is bug in panos (any version). My problem is similar but effect is the same – FW hangs and reboot required.
Palo write:
· > Do we know what is the main reason of this problem ?
·
· so far we know that one of the internal timers gets stuck, it is not
· clear in which conditions that happens
·
· > Is there any configuration change we can do to minimize these downsides ?
·
· disabling the qos, which you already did is the only one known so far to
· limit how often it happens
·
· > When do you plan to fully address this issue ?
·
· once the releases with additional debugs are out in the field this
· should accelerate the resolution. No other time frame can be provided at
· the moment
·
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!