F5 SNAT port exhaustion occurring

This is a real life sample alert from indeni

Description:

You are encountering SNAT port exahustion. The logs from /var/log/ltm are:
01010201:2: Inet port exhaustion on 10.1.21.26 to 172.28.21.71:53 (proto 17)
01010201:2: Inet port exhaustion on 10.10.10.211 to 172.28.21.123:80 (proto 6)

Manual Remediation Steps:

Follow SOL7820 to resolve this. Note that if CMP is used, you should also read SOL11004.

How does this alert work?

indeni reviews the logs in files such as /var/log/ltm and compares them with the available knowledge pertaining to what those logs mean.

Jobs Failed Palo Alto Networks Alert Guide

Data connections and led lights in an industrial building grain visable in areas and colours removed from certain images to enhance them., Low aperture used to create a shallow DOF on on connections or lights

This is a real life sample alert from indeni from our Palo Alto Networks Firewall Alert Guide.

Description:

Some jobs have failed on the device, please review the list below.

Jobs:

  • Job ID: 10
    The job has failed due to “Error: can’t find cert ‘your_cert’ for vsys 1”. Please review DOC-7890.
  • Job ID: 9
    The job has failed due to “dynamic-url Not available for PAN-DB”. Please review DOC-4388.

Manual Remediation Steps:

In the above list of failed jobs, please review the error message and the DOC if included.

How does this alert work?

indeni runs “show jobs all” repeatedly and compares any error messages with its own knowledge base as well as the one available on live.paloaltonetworks.com.

Check Point firewalls Alert of the Week: Two cluster members differ in their SecureXL configuration

This is a real life sample alert from indeni.

Description:

This cluster member has SecureXL disabled. This does not match the SecureXL configuration of other cluster members.

Manual Remediation Steps:

Compare the SecureXL configuration of all members of this cluster using “fwaccel stat” and identify discrepancies.
We also suggest reading SK41397.

How does this alert work?

indeni automatically identifies when several devices are part of a cluster and then compares their configurations. In this case, it compares the output of “fwaccel stat”.

The Rise of the VAR/MSP

The Managed Service Provider (MSP) market is exploding. It’s been this way for a few years now. It makes a ton of sense – MSPs can offer something organizations are lacking and for a lower cost: expertise in 24/7 operation of critical infrastructure.

Some, usually larger, enterprises are unable to use MSPs today due to security and confidentiality requirements. However, many who can, choose to use MSPs to run their infrastructure. We, at indeni, are happy to see this trend as MSPs are a great partner of ours. Take Fujitsu, for example, a leading MSP in the UK & Ireland who has converted their MSP offering to run around indeni’s technology.

One thing that we started seeing more and more in 2014 and now 2015, is the rise of the VAR/MSP. Value Added Resellers (VARs) are those who sell network equipment and professional services to large enterprises. Historically, their business was primarily around making a low margin on physical equipment sale (and maintenance) and a higher margin on professional services (design and implementation of projects).

However, much like startups and more established tech vendors have figured out, a recurring revenue stream can greatly increase the business’s profitability. Almost all such vendors today use (or are moving to) annual subscriptions to provide services instead of selling perpetual licenses. It provides them with an ability to forecast future revenues, increase margins and build a solid business.

VARs are now going the same way. They are leveraging their expertise (built through reselling equipment and providing professional services around it) to build strong MSP offerings. Several of our VARs have already begun offering this and many others are in the planning/building process. We’re very happy about this development – as indeni is becoming a core element of delivering these services. Our pricing model aligns with that very well too, so MSPs have considerable flexibility in rolling out indeni across their existing and new customers.

These are exciting times!

F5 Mirroring and production traffic using the same VLAN

https://indeni.com/wp-content/uploads/2015/03/download-14.jpg

This is a real life sample alert from indeni

Description:

SOL13478 recommends that you do not mix mirroring and production traffic on the same VLAN. Your mirror IP is 192.168.16.2 which is on 192.168.16.0/24, a production network.

Manual Remediation Steps:

Change the network design and the mirror IPs so they are on a dedicated VLAN.

How does this alert work?

indeni reviews the configuration for the mirroring IPs (those you set via “modify /cm device <device_name> mirror-ip <IP address> mirror-secondary-ip <IP address>”) and compares to them to what it knows regarding traffic flow. If production traffic flows through the same VLAN as the mirroring traffic, an alert will be generated.

F5 Configuration changes shouldn’t be made to the standby device

This is a real life sample alert from indeni for F5 Load Balancing Methods

Description:

You have made configuration changes to the standby device in a device group. This is contrary to best practices as an unplanned config sync can result in an outage. It is best to make changes directly to the active device during an approved maintenance operation.

Manual Remediation Steps:

Make the changes on the active device and sync to the standby device. More information on how to track configuration changes can be found in SOL13946 under “Viewing the commit ID updates”.

How does this alert work?

indeni uses “tmsh run /cm watch-devicegroup-device” to track the commits being made on the standby device and where they are coming from.

Top Configuration Issues To Look Out For In Check Point Firewalls

We have been running a webinar for a while now that discusses the top configuration-related mistakes we see people making with Check Point firewalls. Some of the sessions I ran myself!

Since many attendees asked for a document detailing the tips, we thought we’d make it available here.

Top checks to run regularly on your firewalls (once a month or so):

  • Make sure NTP is not just configured but actually works. For example, in Gaia, you should go into clish, run “show ntp servers” and then go into expert mode. Once there, run “ntpdate -u <ntp_server_ip>” for each NTP server configured. Look for errors like “no server suitable for synchronization found”.
  • Compare static routing tables between members of a cluster. We suggest running “netstat -rn | wc -l” as a first step to see if the number of routes is the same.
  • Compare the CoreXL configuration across cluster members using “fw ctl multik stat”. Note that if your ClusterXL is in Ready state (shown in the output of “cphaprob stat”) it may be because the CoreXL configuration is different between the members of the cluster.
  • Compare the SecureXL configuration across cluster members using “fwaccel stat”. Note that the only other way for you to know there is a configuration difference is to see a massive spike in CPU usage on the secondary cluster member when it becomes active.
  • Make sure that no one has left debug on as it can really hog the CPU. To disable debug at the kernel level, run “fw ctl debug 0”. At the user level you need to use the “fw debug” command as described by Kellman Meghu.

In the webinar we go through a few more checks we recommend doing regularly. Come join us, it’s free!

F5 Hash persistence profile shouldn’t be applied to FastL4 virtual servers

This is a real life sample alert from indeni for F5 Balancing Methods

Description:

You have applied a hash persistence profile to a FastL4 virtual server. That is not supported. The following appeared in /var/log/tmm:
local/Test1 notice mcp error: 1031000 in mcpmsg_to_database

Manual Remediation Steps:

Follow the workaround detailed in SOL12078.

How does this alert work?

indeni reads the configuration of the F5 LTM and crosses that with the contents of log files (such as /var/log/tmm) to identify possible issues that match certain SOLs. For more info on F5 balancing methods, sign up for our indeni newsletter.