You have created a single lea client connection, but have resulted in multiple checkpoint devices shown in manage monitored device.
To clarify the use of product filtering, it is used for 2 purposes
- To assign any logs coming from this lea connection to have a specifics address, or
- Ignore any logs coming from this lea connection according to its product type
To explain further on (1), when you connect to the checkpoint SmartView to collect logs, those logs will be divided according to the interface of the FW, and will create a new device in enVision according to each network interface of the FW (This is what customer being observing). To resolve this, in the filter string, we can configure to have logs coming from a particular product (e.g: VPN-1/Express) to have a specifics IP address. To do this, fill in the product name (e.g: VPN-1 Pro/Express, SecureClient), uncheck the ignore button, and then type in the IP address you wish to address for this product. For example, I can have all the logs generated by the VPN-1 Pro/Express device will be logged as 10.32.27.177, while all the logs generated by SecureClient device will be logged as 10.32.27.188
This way, you can restrict how many different IP will be generated from this single connection point (instead of enVision generating a number of devices by the FW interface). Technically, you can assign all products to have the same IP address. In this case, this lea connection point will generate only 1 single device, where all the logs will appear to come from the same IP. Certainly this won?t affect the source / destination address as recorded in the message payload, i.e: no information in the actual log will be altered, rather we are just altering the source IP where these logs are come from
Thus, to ensure we can properly manage the number of devices generated by this connection point, we need to ensure that in our product filtering sections, we have created an entry for each of the products displayed in the Checkpoint SmartView.
On the other hand, the product filtering can also be used to just ignore any product logs that you are not interested in. For e.g: I?m not interested in any logs collected by the FloodGate-1. In this case, I can use the ignore checkbox to have all of these logs dropped. In this case, it will also help to minimise the number of devices generated by this lea connection
Because we are ignoring logs collected by the FloodGate-1, it is contradictory (in its usage) to have this assign an IP address. Thus when the Ignore checkbox is checked, the IP address field becomes unavailable for that product
Related Articles
Explanation of successful authentication followed by passcode reuse and bad tokencode messages in RSA Authentication Manag… 2.11KNumber of Views Explanation of Next Tokencode Mode and Small, Medium and Large authentication windows in RSA Authentication Manager 2.33KNumber of Views Integrating checkpoint logs with Envision 184Number of Views Explanation of the failover.dat file used by RSA Authentication Manager 8.x 226Number of Views Determine the correct root (base DN) and user search filter when configuring an identity source for the RSA SecurID Access… 132Number of Views
Trending Articles
Downloading RSA Authentication Manager license files or RSA Software token seed records RSA Release Notes for RSA Authentication Manager 8.8 RSA Authentication Manager 8.9 Release Notes (January 2026) How to configure RSA Authentication Manager 8.4 or later to send data to multiple remote syslog servers Download RSA SecurID Access Cloud User Event audit logs using Cloud Administration REST API CLU