PA-200 - commit change and then nothing

[bdunbar]

I have opened a critical ticket, but was looking for community feedback on this issue.

Setting up my new PA-200, troubleshooting a route problem.  I removed a rule to simplify troubleshooting, hit 'commit'  The progress bar reached '98%' then the device was unreachable by https.

I called the colocation staff, asked for a power reset.  The device never came back on the network, although they reported the lights on the NIC slots were blinking on/off.

Dinner, nap, drove to the site.  I can access CLI via the console port but there my knowledge ends: I'm a linux admin not a network guy.  I'm sure once they call me back, support can walk me through the steps needed to recover.

Is this common with a PA-200, or PAN software?  Did I do the wrong thing by requesting the colo staff to power off the device?  I can work around it, if so, by never executing changes remotely but man: I'd rather not drive out to the cage just to click 'commit' on every minor change in the firewall.

Thanks in advance,

Brian

[panos · Accepted solution]

well

it seems to be something changed also when you have removed the route maybe.if you have access try to rollback config and commit

configure

load config version .... (choose the second or third one from the bottom)

commit

see if anything changes.

[ajbool]

Two things I learnt quite early on with Palo Alto firewalls...

1. Always perform your remote management of the firewalls agaist the IP address of the management interface of the firewalls.  I realise you can technically manage them using addresses on the functional interfaces - but I found this is asking for problems similar to what you're suffering from now.

2. Make sure your network access when connecting to the management interface IP he firewall is direct and not across one of the functional interfaces of the same firewall (or its HA pair).  i.e. Don't have your management traffic crossing the functional interfaces of the firewall.

I guess this too late to help you right now; but may help for the future.

For getting your box up; start with the management IP and go from there  Good luck.

[bdunbar]

Yup - a thing I wasn't aware of was the roll-back option.  We figured out the problem: essentially I

Added a rule for access to RDP.  This didn't commit, because of a routing issue, but it worked so I let it be.

Later added a second rule to show all traffic with 'deny'.  Because it seemed like a neat idea.

Removed the RDP rule.  Hit 'Commit' ...

Which  - I conjecture - then told the thing to deny-all to all traffic.  Whoops.

[bdunbar]

Yes, a good ideas, all around.  Because this unit is a loaner from the reseller until 'ours' ships (it arrived on my desk last night) we didn't sweat the management connection to my backend switch because 'it's only a week' and 'working well enough to get to the (hah) important part which is configuring the servers and the data crunching application that will live on them.

There is always a proper order for doing things and one violates them at risk of perilous peril.  Don't be that guy.