Captive Portal Fails to Load Properly or Returns 404

Captive Portal Fails to Load Properly or Returns 404

This article describes how to fix the issue whereby captive portal fails to load, is returned only partially without the user / pass fields or returns a 404 error. This also mitigates issues with:slow access to a Mobile Access gateway on wireless or lossy networks.

The mechanism responsible for the problems is “SACK” – an acronym for Selective ACKknowledgment. The “SACK-permitted” option and “SACK” option alter the acknowledgment behavior of TCP:

SACK-permitted

The SACK-permitted option is offered to the remote end during TCP setup as an option to an opening SYN packet. The SACK option permits selective acknowledgment of permitted data. The default TCP acknowledgment behavior is to acknowledge the highest sequence number of in-order bytes. This default behavior is prone to cause unnecessary retransmission of data, which can exacerbate a congestion condition that may have been the cause of the original packet loss.

A packet capture on the client or gateway will typically show many retransmitted packets and ends with the client eventually sending RST packets to the gateway.

SACK

The SACK option allows the receiver to modify the acknowledgment field to describe noncontinuous blocks of received data, so that the sender can retransmit only what is missing at the receiver’s end.

Solution

Disable Selective-ACK by setting the value of cpas_tcp_do_sack kernel parameter to “0” (zero).

Procedure:

To Disable Selective-ACK on-the-fly, run:

[Expert@gateway]# fw ctl set int cpas_tcp_do_sack 0

Check that the value was accepted:

[Expert@gateway]# fw ctl get int cpas_tcp_do_sack

To disable the parameter permanently:

Edit the $FWDIR/boot/modules/fwkern.conf file using Vi editor to add a line with the format “parameter_name=value", in this case:

cpas_tcp_do_sack=0

Reboot the gateway after any changes to the $FWDIR/boot/modules/fwkern.conf file.

Notes:

  • Disabling Selective-ACK can impact networking throughput when client/server are using large TCP Windows and there is packet loss between these hosts.
  • In Cluster, perform the procedure on all cluster members.

How To Repair A Corrupt Smartcenter Installation

Repair A Corrupt Smartcenter Installation

This article details how to repair a corrupt smartcenter step-by-step. This process is valid for both Windows and *nix-based installations and platform-specific instructions are pointed out where necessary.

In fact, the word “repair” is somewhat misleading as what we really do is create a new smartcenter and use configuration files from the old install to effectively make a clone – all certificates, ICA, VPN etc will remain as they were so no re-SIC will be required with the gateway modules once you are up and running.

There are two ways to restore – minimal and complete. “Minimal” will make sure that all objects, rules, certificates and the user database are restored which is all that is needed a lot of the time. If however you would like to do a “complete” restore including licensing, database versions then the files are specified as well.

In addition, at the end of the article are two simple commands which can be used to gather up all of the files and place them in an archive for easy retrieval!

 

Minimal Restore Requirements

Objects and Rulebase

The following files are required to restore a smartcenter’s rulebase, objects and user database. The first two files are absolutely necessary and there is no point proceeding without them, fwauth.NDB is necessary to restore the user database:

  • $FWDIR/conf/objects_5_0.C
  • $FWDIR/conf/rulebases_5_0.fws
  • $FWDIR/conf/slprulebases_5_0.fws
  • $FWDIR/conf/fgrules.fws
  • $FWDIR/conf/fwauth.NDB

Notes:

  1. Check Point stores all the rulebases in one file, called ‘rulebases_5_0.fws’. This is the only rulebase file needed.
  2. Check Point stores the desktop security rulebase in a database file called ‘slprulebases_5_0.fws’ (Secure LAN Policy).
  3. Check Point stores all the objects, services, etc in one database file called ‘objects_5_0.C’.
  4. Check Point users are stored in the file ‘fwauth.NDB’.
  5. On Windows machines, %FWDIR%\conf\fwauth.NDB is only the pointer to the real user database file, for example, %FWDIR%\conf\fwauth.NDB522. In this case, rename the real database file %FWDIR%\conf\fwauth.NDB522 with the name %FWDIR%\conf\fwauth.NDB
Internal Certificate Authority Files

The ICA is what all other certificates are based on – SIC, VPN etc. restoreing these is necessary to avoid having to re-setup certificate-based VPNs, remote-worker certificates and re-establishing SICwith all managed gateways.

  • $FWDIR/conf/InternalCA.*
  • $FWDIR/conf/ICA*.*
  • $CPDIR/conf/sic_cert.p12
  • $FWDIR/conf/crls/*
Registry Data – SecurePlatform & Gaia

/opt/CPshared/registry/HKLM_registry.data

– copy everything under ‘SIC’

Registry Data – Windows OS

HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\SIC

(export this key and then import it on the target machine)


 

Full Restore Requirements

The following represents the complete set of files essential for a database restore:
• $CPDIR/conf/cp.license
• $CPDIR/conf/sic_cert.p12
• $CPDIR/database/*.C
• $CPDIR/registry/*
• $FWDIR/conf/lists/*
• $FWDIR/conf/*.fws
• $FWDIR/conf/*.conf (except for ‘components_reg.conf’, ‘fwrl.conf’, ‘cpmad_rulebase.conf’)
• $FWDIR/conf/masters
• $FWDIR/conf/fwmusers
• $FWDIR/conf/gui-clients
• $FWDIR/conf/*.C (except for ‘mv_doc.C’, ‘classes.C’, ‘scheme.C’, ‘fields.C’, ‘tables.C’, ‘rtmclasses.C’, ‘default_objects.C’)
• $FWDIR/conf/db_versions/Database/versioning_db.fws
• $FWDIR/conf/vpe/*
• $FWDIR/conf/XML/*
• $FWDIR/conf/cpsc/*
• $FWDIR/conf/I*
• $FWDIR/conf/crls/*
• $FWDIR/conf/db_versions/repository/*
• $FWDIR/conf/fwauth.NDB
• $FWDIR/conf/DiapCpdList.NDB
• $FWDIR/conf/DiapFwmList.NDB
• $FWDIR/conf/DAIP_RS_Database.NDB
• $FWDIR/conf/robo-gateways.NDB
• $FWDIR/conf/robo-control.NDB
• $FWDIR/conf/robo-ike.NDB

Note: If logs are required then the contents of $FWDIR/log/ should also be included (note that $FWDIR/log/ is a symbolic link to another partition on the hard disk and files should be retrieved from there).

Restore Process

  1. Back up the files noted herein, offloading to a secure location.
  2. Install the same version and feature set onto the replacement Security Management Server, ensuring that the same hostname and leading IP address are used.
  3. Perform the installation as though this was a clean (new) Security Management Server installation.
  4. If the new Security Management Server is rebooted at the conclusion of the installation, run ‘cpstop’ before restoring the files.
  5. Copy the backups from Step 1 to the fresh installation.
  6. Extract the backups to their appropriate locations.
  7.   Before executing ‘cpstart’, delete the $FWDIR/conf/applications.C and $FWDIR/conf/CPMILink*

Automate File Retrieval

Use the below commands to automate retrieval of the files specified above. The files will be bundled into two files named backup1.tgz and backup2.tgz

Note: This does assume that the Check Point path variables $CPDIR and $FWDIR are available:
[Expert@mgmt]# tar -czvf backup1.tgz $FWDIR/conf/objects_5_0.C $FWDIR/conf/gui-clients $FWDIR/conf/fwmusers $FWDIR/conf/rulebases_5_0.fws $FWDIR/conf/slprulebases_5_0.fws $FWDIR/conf/fgrules.fws $FWDIR/conf/fwauth.NDB $FWDIR/conf/InternalCA.* $FWDIR/conf/ICA*.* $CPDIR/conf/sic_cert.p12 $CPDIR/conf/cp.license $CPDIR/registry/HKLM_registry.data $FWDIR/conf/crls

 

[Expert@mgmt]# tar -czvf backup2.tgz $CPDIR/conf/cp.license $CPDIR/conf/sic_cert.p12 $CPDIR/database/*.C $CPDIR/registry $FWDIR/conf/lists/* $FWDIR/conf/*.fws $FWDIR/conf/*.conf $FWDIR/conf/fwmusers $FWDIR/conf/masters $FWDIR/conf/*.C $FWDIR/conf/db_versions/Database/versioning_db.fws $FWDIR/conf/gui-clients $FWDIR/conf/vpe/* $FWDIR/conf/XML/* $FWDIR/conf/cpsc/* $FWDIR/conf/I* $FWDIR/conf/crls/* $FWDIR/conf/*.NDB

Checkpoint: Long Delay When Logging In Via SSH or Console

How to mitigate the issue where this a long delay when logging in via SSH or console.

When an SSH session is initiated to a linux box, the SSH server tries to perform a lookup on the client’s IP; in certain situations this is not going to be possible, e.g.:

  • the configured DNS server is offline
  • the firewall / smartcentre cannot talk to the configured DNS because of a policy
  • the external internet connection is down etc.etc.

This DNS timeout manifests itself as an incredibly long delay for the user trying to log in – fortunately there is a very quick fix for this:

  • delete the nameservers entirely!
  • configure nameservers that the machine is able to reach
  • use internal nameservers if your internet connection is flaky

This is the case for all Checkpoint linux-based machines as well as IPSO and Gaia.