Azure Backup – Recovery Service Vault

  1. Login to  https://portal.azure.com
  2.  Search for Recovery service vault

Azure-1

3. Click on Recovery services vaults

Azure-2

4.  Provide Subscription name, Resource group, vault name and region details and click   review and create it.

5.  Now go to newly created recovery service vaultAzure-3

5.  Go to Settings  > Properties and configure backup configuration according to your requirement (Locally Redundant or Geo Redundant)

Azure-4

6.  Now go to getting started > Backup > Select workload as Azure and virtual machine under want do you to backup

Azure-5

7. Click on Backup, either select default policy or create a new policy according to your business requirement

Azure-6

Azure-7

 

8.  Click ok and now add virtual machine to the backup policy.

Azure-8

9. Click ok and deployment will start for backup.

10. Go to protected items > Backup items

Azure9

11. Now VM backup will happen according to the schedule configuration.

Azure-10

Restricting to the F5 webui access

  • To verify existing allowed subnets use the below command from F5 CLI:

tmsh list /sys httpd allow

  • To modify the existing allowed IP’s or subnets for F5 webui access use the below command.

             tmsh modify /sys httpd allow add { <IP address or IP address range> }

   tmsh modify /sys httpd allow add {1.1.1.1}

             tmsh modify /sys httpd allow add {172.1.0.0/255.255.0.0}

After updating the subnets save the configuration using the below command.

tmsh save /sys config

  •         To replace all the existing values use the below command.

            tmsh modify /sys httpd allow replace-all-with { <IP address or IP address range> }

          tmsh modify /sys httpd allow replace-all-with { 172.2.0.0/255.255.255.0 }

After updating the subnets save the configuration using the below command.

tmsh save /sys config

 

 

 

 

 

Enable checkpoint webui on different service port

Use below command to verify checkpoint webui daemon is enabled or not

Show web daemon-enable

Use the below command to verify present webui listening port

show web ssl-port

Now use the below command to change the webui listening service port

set web ssl-port 6783

Save the config using the below command

save config

Now you can try your checkpoint firewall webui using service port 6783

https://192.168.1.1:6783

 

 

 

 

Palo Alto Panorama and Firewall Upgrade Procedure:

PAN-OS upgrade Best Practice Document:

It is best practice to always download and install the latest maintenance release for each feature release and then reboot before you install the base image for the next feature release, which applies to each feature release through which you pass in the upgrade path.

In this example, we are upgrading from PAN-OS 7.1.16 to 8.1.8

Test firewall is configured in Active/Passive HA cluster managed by Panorama.
Best practice document:

Verify  all steps before the upgrade.
Dependencies:

A. Before you upgrade, make sure the firewall is running a version of app + threat (content version) that meets the minimum requirement of the new PAN-OS (see release notes).

B. Recommendation is  always run the latest version of content to ensure the most accurate and effective protections are being applied.

C. Panorama should be running the same or a later version of a feature release than the firewall (more than two feature versions is supported but not recommended as of June 2016).
D. Panorama should also be running the same or later version of a maintenance release than the firewall (up to two maintenance versions is supported.

E. Panorama may manage a firewall that is running on a later maintenance release than it’s own, but more than 2 versions is not recommended (ie. Panorama 9.0.0 can manage firewalls up to 9.0.2)

If the firewall is running Panorama versions supported are
PAN-OS 7.1.x  7.1.x, 8.0.x, 8.1.x, 9.0.x
PAN-OS 8.0.x 8.0.x, 8.1.x, 9.0.x
PAN-OS 8.1.x 8.1.x, 9.0.x
PAN-OS 9.0.x 9.0.x

 

TABLE OF CONTENTS

  1. Determine the need to upgrade
  2. Pre-upgrade checklist
  3. Panorama upgrade procedure
  4. Firewall upgrade procedure (HA)
  5. Post-upgrade checklist
  6. Troubleshooting resources
  7. Downgrade procedure

 

 

1) Determine the Need to Upgrade:

  1. Upgrade should be considered for only the following reasons:

    A. New features that are not available in current version
    B. Patches for security vulnerabilities in PAN-OS (see Security Advisories page)
    C. Bug fixes that are not available in current version
    D. Current version is going to End of Life soon (see PAN-OS EOL policy)

    For a generic PAN-OS Software release guidance refer: Preferred PAN-OS release
    Consult with Palo Alto Networks account team for upgrade decision, so that vendor
    account team can provide you with a more tailored release guidance and a recommended PAN-OS version, specifically for your environments .

    For the purpose of this document, we will be upgrading from 7.1.x to 8.1.x to demonstrate the upgrading process across two major releases (7.1 > 8.0 > 8.1).

    NOTE:For any PAN-OS version prior to PAN-OS 8.0 (PAN-OS 7.1 and lower), it is recommended to go to the latest maintenance release to prevent running into issues during the upgrade.

    HA Upgrade NOTE: When upgrading across two major release versions at a time, you will likely experience a network outage. However, if the devices are upgraded one major version at a time, HA will remain active and continue to synchronize sessions and no network outage will be seen.

    To maintain HA sync and activity, upgrade the HA pair in tandem one major release at a time.
    A. If you upgrade one device by two major upgrades, the newly upgraded device will stay in suspended mode with the error peer OS too old.
    B. Upgrading one device by two major upgrades, would lead to loss HA functionality and may result in undesirable network impact.

    2) Pre-Upgrade Checklist:

    A. Review release notes.
    B. Do not schedule Panorama and firewall upgrades at the same time.
    C. Upgrade Panorama first, wait at least 24 hours and then upgrade the firewall.
    D. Upgrade should be carried out during non-business hours or a scheduled maintenance window to minimize impact.
    E. Allocate sufficient time in the change window for upgrade, troubleshooting and possible downgrade procedures. It may take up to 2-3 hours to upgrade a slower or older system, depending on config. Multiply if upgrading across multiple versions.
    F. Identify business contacts who will help verify application and network functionalities after the upgrade.

    Back up configuration and device state before upgrade.

    View of PAN-OS Device setup screen in Configuration Management

  2. Device > Setup > Operations > Save Named Configuration Snapshot
  3. Device > Setup > Operations > Export Named Configuration Snapshot
  4. Device > Setup > Operations > Export Device State
  5. Device > Support > Generate Tech Support File

View of PAN-OS Device support screen in Tech Support File

Document any non-standard settings that should be applied post-upgrade:
Disable TCP state checking
Non-syn TCP reject
Any debug setting if existing (not recommended)

Depending on the target PAN-OS release you want to, determine the upgrade path. Refer here

Stage/Download necessary PAN-OS images ahead of time. You will need both the base image and the latest maintenance release.
The base image should be installed but need not rebooted.

In this example, we need to download the following versions:

– The latest preferred 7.1.x maintenance release. (it is recommended to bring your current Feature release to the latest recommended maintenance release before proceeding)
– 8.0.0 for firewalls, 8.0.2 for Panorama (base image) NOTE: the 8.0 base image and maintenance versions will not become visible in the download section until you have a version of 7.1 installed.
– The latest preferred 8.0.x maintenance release.
– 8.1.0 (base image)
– The latest preferred 8.1.x maintenance release.

Following the PAN-OS upgrade, you may need to upgrade associated software (such as GlobalProtect agent or User-ID agent).

– See the Associated Software Versions chart in the release notes.

Console connectivity:

Arrange for Out-of-Band access (Console access) to the firewall if possible. This is to help recover from any unexpected situations where we lose connectivity to the firewall after upgrade.

3) Panorama Upgrade Procedure:

A. Make sure no policy or configuration changes are being made by acquiring a config lock.
View of PAN-OS GUI PadLock

B. Click the padlock on the upper-righthand corner of GUI
C. If there are any locks, remove the locks and talk with the admin who placed the lock there and remove or commit.
D. Clear or complete any pending commit job making a commit to panorama before starting the upgrade.

Recommended: Post-upgrade fail over testing:

Suspend Secondary Panorama to fail connection back to Primary Panorama to make sure failover still works after upgrade.

– CLI: > request high-availability state suspend
– GUI: Device > High Availability > Operations > click Suspend Local Device
– Verify suspend status on Secondary Panorama
– Verify all firewalls are connected to Primary Panorama
– Re-enable Secondary Panorama and High Availability function
– – CLI: > request high-availability state functional
– – GUI: Device > High Availability > Operations > click Make Local Device Functional

Primary Panorama Upgrade procedure:

– Disable Pre-emption if enabled.
(Disable preemption on High Availability settings to avoid unexpected fail overs. Disabling preempt configuration change must be committed on both peers. Once completed, re-enabling must be committed on both peers)

– Go to Device > High Availability > Election Settings and uncheck Preemptive. Then, commit the change.

View of PAN-OS Device High Availability screen in Election Settings

– Suspend Primary Panorama to make Secondary Panorama as active
– From Primary Panorama, suspend High Availability function:
– – CLI: > request high-availability state suspend
– – GUI: Device > High Availability > Operations > click Suspend Local Device

View of PAN-OS Device High Availability screen in Optional Commands

– Verify suspend status on Primary/passive Panorama.
– Verify all firewalls are connected to Secondary/active Panorama.
– On the Primary Panorama, download, install and reboot the latest preferred 7.1.x maintenance release.
– Save/export tech support and device state and save named device config snapshots (this is in case downgrade is needed).
– Download 8.0.2 (base version).
– Download and install the latest preferred 8.0.x maintenance release and reboot to complete the upgrade.
– Save/export tech support and device state and save named device config snapshots (this is in case downgrade is needed).
– Download 8.1.0 (base version).
– Download and install the latest preferred 8.1.x maintenance release, and reboot to complete the upgrade.
– re-enable pre-empt if desired
– This concludes upgrade on Primary Panorama.

Secondary Panorama Upgrade procedure:

– Download and install the latest preferred 7.1.x maintenance release and reboot to complete the upgrade.
– Download 8.0.2 (base version).
– Download and install the latest preferred 8.0.x maintenance release and reboot to complete the upgrade.
– Save/export tech support and device state and save named device config snapshots (this is in case downgrade is needed).
– Download 8.1.0 (base version).
– Download and install the latest preferred 8.1.x maintenance release, and reboot to complete the upgrade.
– This concludes upgrade on Secondary Panorama.

Backup config and device state files just in case: (BACK UP CONFIGURATION AND DEVICE STATE FROM THE CLI)

(Optional but recommended) Post-upgrade verification:

– Verify connectivity between Panorama and Firewalls. If something is not working, skip to troubleshooting section
(For example, check if Panorama is receiving logs with correct time stamp from firewalls after upgrade is completed)

– Test commit-all operations to managed devices, and verify new changes are applied as expected locally on the devices.

4) Firewall Upgrade Procedure (HA):

IMPORTANT NOTE:
If you have the pair in HA(active/passive) then you have to upgrade only to next version of PAN-OS then failover and proceed to upgrade for the second version of PAN-OS. Only upgrade one version at a time.

Example: If you are at PAN-OS 7.1.x then you should go to 8.0.x version(let it be any version of PAN-OS) then failover and check the functionality. Otherwise you will run into the error and the HA pairs will no longer be in sync.
Additionally Remember that if there is more than 1 version of difference between the HA pairs then you will run into the “Peer version too old” issue.

It is recommended to upgrade the Primary firewall first and then upgrade the Secondary firewall. This is done for two reasons:

1) Ensure that HA failover is functioning properly
2) Ensure that the passive firewall is functioning properly and is able to pass traffic without issues

Disable Preemption if enabled.

Disable Preemption on High Availability settings to avoid unexpected fail overs.

Disabling preempt configuration change must be committed on both peers. Once completed, re-enabling must be committed on both peers.

To Disable, got to: Device > High Availability > General > Election Settings > Edit > Uncheck Preemptive.

Then, perform a commit.

View of PAN-OS Device High Availability screen in Election Settings

NOTE: This procedure relies on the administrator having foreseen access to their devices at all times, either by being local or having OOB connectivity to the management network, which is a good practice when upgrading the firewall. In the case where you do not have the option of achieving either, it is a good idea to change the procedure slightly to ensure you don’t lose connectivity at the cost of having a less rigid upgrade path.

Having the preempt enabled will require you to keep this config change in mind during the whole process as it could unexpectedly switch over the active membership while upgrading.

Primary firewall upgrade Procedure:

– On Primary firewall, Suspend Primary firewall to make Secondary firewall active
– – CLI: > request high-availability state suspend
– – GUI:  Device > High Availability > Operations > click Suspend Local Device

NOTE: This will cause an HA failover. We recommend doing this first to verify the HA functionality is working before initiating the upgrade. Production traffic is now going through the Secondary firewall which is now active.

– Ask your business owners to verify all applications are working on the network. If there is a problem, skip to troubleshooting section. If there is any problem, fix it before proceeding with upgrade.
– Upgrade Primary firewall. You can do this by either directly downloading and installing software onto the firewall itself or via Panorama Device Deployment > Software option.
– Download, install and reboot the latest preferred 7.1.x maintenance release.
– Download 8.0.0 (base version).
– Download and install the latest preferred 8.0.x maintenance release and reboot to complete the upgrade.
– Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed).
STOP! Please read “Important Note” in step 4 above before continuing upgrade to 8.1.0
– Download 8.1.0 (base version).
– Download and install the latest preferred 8.1.x maintenance release and reboot to complete the upgrade.
​​​​– On the Primary firewall, verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step: > show jobs all
– Run the following command to make Primary firewall functional again: > request high-availability state functional
– This concludes upgrade on the Primary firewall.

Secondary firewall upgrade procedure:
– Suspend Secondary firewall to make Primary firewall active.
– From Secondary firewall, suspend High Availability function
– – CLI: > request high-availability state suspend
– – GUI: Device > High Availability > Operations > click Suspend Local Device

NOTE: This will cause an HA failover. Production traffic is now going through Primary firewall with new software installed.

– Ask your business owners to verify all applications are working on the network. If there is a problem, skip to troubleshooting section. If there is any problem, fix it before proceeding with upgrade.
– Upgrade Secondary firewall. You can do this by either directly downloading and installing software onto the firewall itself or via Panorama Device Deployment > Software option.
– Download, install and reboot the latest preferred 7.1.x maintenance release.
– Download 8.0.0 (base version).
– Download and install the latest preferred 8.0.x maintenance release and reboot to complete the upgrade.
– Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed).
– Download 8.1.0 (base version).
– Download and install the latest preferred 8.1.x maintenance release and reboot to complete the upgrade.
– Verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step: > show jobs all
– Run the following command to make Secondary firewall functional again: > request high-availability state functional
– This concludes upgrade on the Secondary firewall

Recommended: Arrange for Out-of-Band access (Console access) to the firewall if possible. This is to help you recover from any unexpected situations where we are unable to login to the firewall.

– Backup config and device state files just in case.
– Make sure no policy or configuration changes are being made by acquiring a config lock.
– Click on the padlock in the upper-righthand corner of the GUI
– Make sure no pending commit jobs on firewall.

Recommended: Post-upgrade verification:

– Now that both Primary and Secondary firewalls are both running the new software, it is a good idea to test failover functionality again.
– Run the following comma to suspend Primary firewall to fail traffic to the Secondary firewall
> request high-availability state suspend

– Ask your business owners to verify all applications are working on the network through the Secondary firewall. If there is a problem, skip to troubleshooting section.
– Run the following CLI command to make Primary firewall functional again:
> request high-availability state functional

– Repeat the process to verify traffic works fine through Primary firewall (suspend the Secondary firewall, test functionality on Primary firewall, then re-enable Secondary firewall).
– This concludes failover test.

Recommended: Enable preemption if it was disabled due to upgrade.

– Re-enabling preempt configuration change must be committed on both Likewise, once completed, re-enabling must be committed on both peers.

– Go to Device > High Availability > Election Settings and check Preemptive. Then, perform a commit.

– This completes upgrade on the HA pair.

View of PAN-OS Device High Availability screen in Election Settings for Preemptive

5) Post-Upgrade Checklist

The following Post-Implementation Activities should be performed prior to the change window end time. Performing these Post-Implementation Activities prior to the change window end time allows time to complete any potential corrective action that might be required after performing these activities.

Compare Post-Implementation results with Pre-Implementation results.

– Reapply the non-persistence settings from the pre-checklist.
– Check system logs for any unexpected errors.
– Check traffic logs for any traffic that is unexpectedly allowed or denied.
– If applicable, verify connectivity and network functionality between firewall and panorama, specifically make sure log forwarding from firewall to Panorama is working.
– Also, validate changes will commit between Panorama and the managed devices.
– Check system reports and incidents for any relevant outages.
– – Monitor help desk tickets post upgrade, this may take 24 to 48 hours.
– Contact all stake holders to communicate any change IDs, describe change activity results, and verify that there are no relevant network alarms, incidents, or outages.
– Monitor the appliance for any anomalies.

6) Troubleshooting Resources

If business applications no longer works after upgrade, reference the links below:
– PAN-OS Upgrade or Content Update Failure
– CONTENT VERSION ERROR UPGRADING MAJOR PLATFORM OS WITH AN OLDER CONTENT DATABASE 

If the device fails to complete auto-commit, reference the links below:
– HOW TO DETERMINE WHEN AUTO-COMMIT IS COMPLETE

If software fails to install, reference the links below:
– SOFTWARE INSTALL OR DOWNLOAD PUSH FROM PANORAMA TO DEVICE WILL NOT COMPLETE
– COMMIT FINISHES WITH AN ERROR RESPONSE: CFGPUSH.S1.DP1.COMM.CFG-DP: ERROR PRE-INSTALLING CONFIG
– LICENSE ERROR: FAILED TO INSTALL LICENSES. UNEXPECTED ERROR OCCURRED

If software fails to download, reference the links below:
– Error downloading 7.0.4, with 7.0.0 previously downloaded (General User Discussion)
– SOFTWARE DOWNLOAD ERROR: ‘FAILED TO DOWNLOAD DUE TO SERVER ERROR. FAILED TO DOWNLOAD FILE’
HA Upgrade issue:
Upgraded Device In HA Group Reports Status: Suspended (Peer version Too Old)

Panorama checklist reference links below:
– QUICK REFERENCE GUIDE: HELPFUL COMMANDS
– TROUBLESHOOTING PANORAMA CONNECTIVITY

If issues cannot be resolved:
– Contact Palo Alto Networks TAC using proactive case number.
– Save configurations of affected network devices.
– Save configurations of the Palo Alto Network devices.
– Add to pcaps, configurations, tech support files, and logs from near by networking devices for post mortem and troubleshooting by support teams.
– Go to the downgrade/back out procedure section.

7) Downgrade Procedure

If the issue cannot be resolved within the allotted change window, you should revert all changes:
– Verify 8.1.0 (base image version) is still present on the system.
– Download and install the latest preferred 8.1.x maintenance release, and reboot to complete the install.
– Verify 8.0.0 (base version) is still on the system.
– Download and install the latest preferred 8.0.x maintenance release, and reboot to complete the install.
– Verify 7.1.0 (base version) is still on the system.
– Download and install 7.1.16, and reboot to complete the downgrade.

NOTE: After the Secondary firewall is rebooted, the CLI prompt should show non-functional.
– On the primary firewall, verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step:
> show jobs all
– Run the following command to make it functional again:
> request high-availability state functional
– This concludes downgrade on the Primary firewall.

Downgrade the Primary firewall
– Suspend the primary firewall to fail traffic to Secondary.
– On the Primary device, suspend the unit from the CLI. Run the command:
> request high-availability state suspend

Save the following files for analysis:
– Save and export Tech support and device state from both active and passive firewalls.
– All core dump files if there is any.
– Packet capture of problem traffic, if observed.
– Assuming the firewall is currently running 8.0.6-h3 already and traffic is currently going through the Primary firewall, follow the same upgrade process but in reverse order.

Downgrade the Secondary firewall:
– Verify 8.1.0 (base image version) is still present on the system.
– Download and install the latest preferred 8.1.x maintenance release, and reboot to complete the install.
– Verify 8.0.0 (base version) is still on the system.
– Download and install the latest preferred 8.0.x maintenance release, and reboot to complete the install.
– Verify 7.1.0 (base version) is still on the system.
– Download and install 7.1.16, and reboot to complete the downgrade.

NOTE: After the Secondary firewall is rebooted, the CLI prompt should show non-functional.
– On the Secondary firewall, verify auto commit completes successfully (FIN OK) by running the CLI command before proceeding to the next step:
> show jobs all
– Run the following command to make it functional again:
> request high-availability state functional
– This concludes downgrade on the Secondary firewall.

Recommended: Enable preemption if it was disabled due to upgrade.
– Re-enabling preempt configuration change must be committed on both. Once completed, re-enabling must be committed on both peers.
– Go to Device > High Availability > Election Settings& and check Preemptive. Then, perform a commit.

View of PAN-OS Device High Availability screen in Election Settings for Preemptive Setting

Recommended: Ask your business owners to verify all applications are working on the network. If there is a problem, skip to troubleshooting section.
– Upload all files to the Palo Alto Networks proactive support case for troubleshooting later.
– This concludes the downgrade process.

Reference: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRrCAK

Palo Alto Firewall Software and Hardware Matrix:

1. Palo Alto Networks Next-Generation Firewalls Software Matrix:

https://docs.paloaltonetworks.com/compatibility-matrix/supported-os-releases-by-model/palo-alto-networks-next-gen-firewalls.html#id9680433e-055f-4f38-a7d0-6d31e7d557bc

2. Palo Alto Networks Appliances:

https://docs.paloaltonetworks.com/compatibility-matrix/supported-os-releases-by-model/palo-alto-networks-appliances.html

3. Palo Alto Associated Software and Content Versions:

https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-release-notes/pan-os-8-1-release-information/associated-software-and-content-versions

4. Palo Alto Software end of life Summary:

https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-life-summary

5. Palo Alto HA and Processor Support:

https://docs.paloaltonetworks.com/compatibility-matrix/supported-os-releases-by-model/ha-port-and-processor-support.html

Wide IP’s are down due to Device Certificate expiration on F5 Link Controller:

Issue:

Wideip’s will go down due to F5 device internal device certificate expiration.

Alerts:

DeviceA alert gtmd[13073]: 011ae0f3:1: SNMP_TRAP: big3d SSL cert EXPIRED at IP 10.1.1.1
Device A err gtmd[13073]: 011ae0fa:3: iqmgmt_ssl_connect: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (336134278)
Device A alert gtmd[13073]: 011ae0f3:1: SNMP_TRAP: big3d SSL cert EXPIRED at IP 192.168.1.1

Cause:

Internal F5 device certificates are expired

Solution:

A.

  1. Login to the standby F5 device
  2. Go to System  ››  Device Certificates : Device Certificate
  3. Click on Renew
  4. Update valid for 3650 days (according to your requirement)
  5. Click Finished

Perform steps from 1 to 5 on active device.

B. Now login into the active device through CLI and perform the below steps.

bigip_add < peer IP>

bigip_add script uses the SSH protocol to exchange iQuery SSL certificates with the remote BIG-IP system

The bigip_add script appends the local BIG-IP DNS system’s SSL certificate to the remote BIG-IP system’s list of authorized certificates.

C.

Now login into the sandby device through CLI and perform the below steps.

bigip_add < peer IP>

Once internal device certificates are exchanged, wideip’s will come to available status.