Cisco Switch Configuration to Make Multicast Load Sharing Working on Checkpoint ClusterXL Firewalls

Working on Checkpoint Cluster XL Load Sharing configuration, and found one blog post from Technopath LLC regarding Cisco switch configuration. It should be helpful for my next step.

The topology like this:

1. Configure the following command on the internal router (usually it is layer 3 switch and 0100.5e16.0de2 is Internal Checkpoint VIP Multicast Mac Address):
•  arp 192.168.20.2 0100.5e16.0de2 arpa  
2. Configure the following commands on the internal switch where the port numbers shown below are the port numbers to which your firewall interfaces are connected:
• mac address-table static 0100.5e16.0de2 vlan 10 interface gi1/0/2 gi1/0/3 gi1/0/4
• no ip igmp snooping vlan 10
3. The multicast mac address of the firewall cluster's internal VIP (shown above in the commands) is obtained by looking at the topology information of the cluster in the SmartDashboard and clicking on the edit option for the cluster IP and then clicking on the advanced button. That should show you the mulitcast MAC address. Checkpoint has an sk technote which shows a different way of getting the MAC address using the cphaconf debug_data command on the command line. This DOES NOT work as it gives you the wrong MAC address.
4. The same configuration commands (with the correct IP and MAC for the external cluster) are performed on the external router pointing to the external VIP (0100.5e16.0de3 is Checkpoint External VIP Multicast Mac Address):
•  arp 192.168.15.2 0100.5e16.0de3 arpa
5. And the same configuration command on the external switch:
• mac address-table static 0100.5e16.0de3 vlan 20 interface gi1/0/5 gi1/0/6 gi1/0/7
• no ip igmp snooping vlan 20

Only Primary SRX Cluster Member Got IDP Signature Update from NSM with Virtual Chassis

1. Situation:

In my environment, there are a couple of SRX Clusters managed by NSM. NSM downloads IDP signature updates from Internet then push those updates to each SRX clusters. Most of SRX cluster members will get IDP signature updates except one pair managed by NSM through Virtual Chassis.

2. Symptoms:

For this pair SRX cluster which is managed by NSM through Virtual Chassis, always only primary cluster member get the signature update, not the secondary one. Even after failover, the secondary becomes primary, the NSM will think this pair SRX cluster has been updated to latest signature database then stop to push.

3. Solutions:

Juniper has a KB to manually sync the database between two cluster members. As long as you have one member got the signature database, the second one can be manually copied in and install it.

Step 1: Copy the signature from Primary folder to Secondary

root@fw-srx-2% rlogin -T node0

--- JUNOS 11.4R10.3 built 2013-11-15 06:56:20 UTC

root@fw-srx-2% ls -l /var/db/idpd/nsm-download/
total 75784
-rwxr-xr-x  1 root  wheel  23406109 Apr 20 15:04 SignatureUpdate.xml
-rwxr-xr-x  1 root  wheel    223243 Apr 20 15:04 application_groups.xml
-rwxr-xr-x  1 root  wheel     31953 Apr 20 15:05 application_groups2.xml.gz
-rwxr-xr-x  1 root  wheel   1678841 Apr 20 15:04 applications.xml
-rwxr-xr-x  1 root  wheel     11823 Apr 20 15:07 applications.xsd
-rwxr-xr-x  1 root  wheel    232937 Apr 20 15:06 applications2.xml.gz
-rwxr-xr-x  1 root  wheel   4413629 Apr 20 15:06 compiled_ai.bin2
-rwxr-xr-x  1 root  wheel     18360 Apr 20 15:06 contexts.xml.gz
-rwxr-xr-x  1 root  wheel       851 Apr 20 15:06 filters.xml.gz
-rwxr-xr-x  1 root  wheel   4067651 Apr 20 15:07 groups.xml
-rwxr-xr-x  1 root  wheel       753 Apr 20 15:07 heuristics.bin.gz
-rwxr-xr-x  1 root  wheel   1349960 Apr 20 15:07 libidp-detector.so.tgz.v
-rwxr-xr-x  1 root  wheel   3093356 Apr 20 15:04 libqmprotocols.tgz
-rwxr-xr-x  1 root  wheel       472 Apr 20 15:07 platforms.xml
-rwxr-xr-x  1 root  wheel     59327 Apr 20 15:05 products.xml.gz
-rwxr-xr-x  1 root  wheel       921 Apr 20 15:06 services.xml.gz
-rwxr-xr-x  1 root  wheel      2832 Apr 20 15:06 templates.xml.gz


root@fw-srx-2% rcp -r -T  /var/db/idpd/nsm-download/* node0:/var/db/idpd/nsm-download/
root@fw-srx-2% cli

root@fw-srx-1% cd /var/db/idpd/nsm-download/
root@fw-srx-1% ls -l
total 75784
-rwxr-xr-x  1 root  wheel  23406109 Apr 21 14:55 SignatureUpdate.xml
-rwxr-xr-x  1 root  wheel    223243 Apr 21 14:55 application_groups.xml
-rwxr-xr-x  1 root  wheel     31953 Apr 21 14:55 application_groups2.xml.gz
-rwxr-xr-x  1 root  wheel   1678841 Apr 21 14:56 applications.xml
-rwxr-xr-x  1 root  wheel     11823 Apr 21 14:56 applications.xsd
-rwxr-xr-x  1 root  wheel    232937 Apr 21 14:56 applications2.xml.gz
-rwxr-xr-x  1 root  wheel   4413629 Apr 21 14:56 compiled_ai.bin2
-rwxr-xr-x  1 root  wheel     18360 Apr 21 14:56 contexts.xml.gz
-rwxr-xr-x  1 root  wheel       851 Apr 21 14:56 filters.xml.gz
-rwxr-xr-x  1 root  wheel   4067651 Apr 21 14:57 groups.xml
-rwxr-xr-x  1 root  wheel       753 Apr 21 14:57 heuristics.bin.gz
-rwxr-xr-x  1 root  wheel   1349960 Apr 21 14:57 libidp-detector.so.tgz.v
-rwxr-xr-x  1 root  wheel   3093356 Apr 21 14:58 libqmprotocols.tgz
-rwxr-xr-x  1 root  wheel       472 Apr 21 14:58 platforms.xml
-rwxr-xr-x  1 root  wheel     59327 Apr 21 14:58 products.xml.gz
-rwxr-xr-x  1 root  wheel       921 Apr 21 14:58 services.xml.gz
-rwxr-xr-x  1 root  wheel      2832 Apr 21 14:58 templates.xml.gz
root@fw-srx-1% cp * /var/db/idpd/sec-download/

Step 2: Install the copied signature database

{primary:node1}
root@fw-srx-2> request security idp security-package install node 0 
node0:
root@fw-srx-1% clear--------------------------------------------
Will be processed in async mode. Check the status using the status checking CLI

{primary:node1}
root@fw-srx-2> request security idp security-package install status    
node0:
--------------------------------------------------------------------------
Done;AI installation failed! Attack DB update failed!

node1:
--------------------------------------------------------------------------
Ready to accept a new request

{primary:node1}
root@fw-srx-2> request security idp security-package install status    
node0:
--------------------------------------------------------------------------
Done;Attack DB update : not performed
      due to the same version between downloaded one and installed one.
     Updating control and data-plane with new detector : not performed
      due to the same detector version between downloaded  and installed one.

node1:
--------------------------------------------------------------------------
Done;Attack DB update : successful - [UpdateNumber=2373,ExportDate=Tue May 13 16:22:18 2014 UTC,Detector=12.6.160140207]
     Updating control-plane with new detector : successful

     Updating data-plane with new attack or detector : successful


{secondary:node0}
root@fw-twinsburg-srx-1> ...security idp security-package install status    
node0:
--------------------------------------------------------------------------
In progress:Installing AI ...

node1:
--------------------------------------------------------------------------
Done;Attack DB update : not performed
      due to the same version between downloaded one and installed one.
     Updating control and data-plane with new detector : not performed

      due to the same detector version between downloaded  and installed one.


{primary:node1}
root@fw-srx-2> show security idp policy-commit-status 
node0:
--------------------------------------------------------------------------
 IDP policy[/var/db/idpd/bins/fw-tw-20140109.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully.
 The loaded policy size is:350641 Bytes

node1:
--------------------------------------------------------------------------
 IDP policy[/var/db/idpd/bins/fw-tw-20140109.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully.
 The loaded policy size is:415603 Bytes

Step 3: verify the installation status

root@fw-srx-2% rlogin -T node0

€

--- JUNOS 11.4R10.3 built 2013-11-15 06:56:20 UTC

{secondary:node0}

root@fw-srx-1> ...security idp security-package install status    

node0:

--------------------------------------------------------------------------

In progress:performing DB update for an xml (SignatureUpdate.xml)

node1:

--------------------------------------------------------------------------

Ready to accept a new request

{secondary:node0}

root@fw-srx-1> ...security idp security-package install status    

node0:

--------------------------------------------------------------------------

Done;Attack DB update : successful - [UpdateNumber=2365,ExportDate=Wed Apr 16 19:07:52 2014 UTC,Detector=12.6.160140207]

     Updating control-plane with new detector : successful

     Updating data-plane with new attack or detector : successful

node1:

--------------------------------------------------------------------------

Ready to accept a new request

{secondary:node0}

root@fw-srx-1> show security idp security-package-version 

node0:

--------------------------------------------------------------------------

  Attack database version:2365(Wed Apr 16 19:07:52 2014 UTC)

  Detector version :12.6.160140207

  Policy template version :N/A

node1:

--------------------------------------------------------------------------

  Attack database version:2365(Wed Apr 16 19:07:52 2014 UTC)

  Detector version :12.6.160140207

  Policy template version :N/A

Generate 2048 Bits CSR in Checkpoint Firewall

1. Situation

When submitting CSR to Symantec Verisign, it shows the CSR is not generated with a 2048 bit key. But from the place where to generate CSR in Checkpoint Smart Dashboard gateway properties window, there is no option to change 1024 bit key to 2048 bit or higher.

2. Research

It seems Checkpoint gateway is still using 1024 bit key. Checkpoint SK44961 has a solution for this.

3. Solutions

By default, when generating a CSR for 3rd party certificate use, the CSR is 1024bit. Some certificate vendors require 2048bit.

To change the default size of the CSR when generating it through the security gateway object:

1. Open the SmartDashboard.
2. Go to Policy -> Global Properties -> SmartDashboard Customization.
3. Click 'Configure'.
4. In the opened Advanced Configuration view go to 'Certificates and PKI properties'.
5. Edit the "host_certs_key_size" property accordingly.
6. Save and install the Security policy.

4. Verify

Best Free Network Performance Test tool - Iperf

According to wikipedia Iperf "is a commonly used network testing tool that can create TCP and UDP data streams and measure the throughput of a network that is carrying them. Iperf is a modern tool for network performance measurement written in C++." So far it is best free software to test network throughput I found. 

1. Download iperf 2 from http://iperf.fr/.

2. Running on one of your remote machine from command line as iperf server (ip address 100.99.136.66).

C:\Tools>iperf -s

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 8.00 KByte (default)

------------------------------------------------------------

[188] local 100.99.136.66 port 5001 connected with 100.94.200.14 port 48410

[ ID] Interval       Transfer     Bandwidth

[188]  0.0-10.0 sec   121 MBytes   101 Mbits/sec

3. Run iperf as client from another machine (ip address 100.94.200.14) of your network to evaluate the network throughput based on TCP connection.

C:\tools>iperf -c 100.99.136.66

------------------------------------------------------------

Client connecting to 100.99.136.66, TCP port 5001

TCP window size: 8.00 KByte (default)

------------------------------------------------------------

[1912] local 100.94.200.14 port 48410 connected with 100.99.136.66 port 5001

[ ID] Interval       Transfer     Bandwidth

[1912]  0.0-10.0 sec   121 MBytes   101 Mbits/sec

4. Send 100MBytes data for testing

iperf -c 100.99.136.66 -n 100m

5. Bi-direction test

Simultaneous bi-directional bandwidth measurement: (-d argument)

To measure the bi-directional bandwidths simultaneousely, use the -d argument. If you want to test the bandwidths sequentially, use the -r argument (see previous test).

By default (ie: without the -r or -d arguments), only the bandwidth from the client to the server is measured.

C:\tools> iperf -c 100.99.136.66  -d

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

------------------------------------------------------------

Client connecting to 10.1.1.1, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 5] local 10.6.2.5 port 60270 connected with 10.1.1.1 port 5001

[ 4] local 10.6.2.5 port 5001 connected with 10.1.1.1 port 2643

[ 4] 0.0-10.0 sec 76.3 MBytes 63.9 Mbits/sec

[ 5] 0.0-10.1 sec 1.55 MBytes 1.29 Mbits/sec

6. Parallel TCP connections

Parallel connections can be useful if you need to saturate the bandwidth of a link.  The bandwidth of a single TCP session can be greatly affected by the size of the receive window and the latency of the link.

iperf -s -i 1 (-i 1 means update terminal every second)

iperf -c 192.168.1.1 -t 30 -P 10

Add caption