Is it possible to add a second internet connection to a CheckPoint Splat firewall?

Hi,

No, there should be no issues with the above configuration;

Regarding wanting your incoming web connections to always go through your cable isp, you would need to make sure the cable ISP is your first link in the table and statically NAT your webserver to a free public IP on that external subnet.

As long as both links are up and working this will suffice. In order to satisfy failover in case of cable ISP link failure however, you would need to have an free IP on both external subnets and configure as per Secure Knowledge article sk25152 which reads as follows:

Outgoing Static NAT with ISP redundancy

Cause
By default, statically translated hosts, in an ISP redundancy configuration, are not allowed for open outgoing connections.
Solution
To allow statically translated hosts in an ISP redundancy configuration for open outgoing connections, use the following procedure.

Notes:

    * Assume that an internal host has an internal IP address, as well as one valid IP address from the address space of each Internet Service Provider (ISP).

    * Use the following notation:

      HOST_INTERNAL = internal IP address of the host
      HOST_VALID_A = valid address of the host from ISP_A (the first ISP)
      HOST_VALID_B = valid address of the host from ISP_B (the second ISP)


On the SmartCenter server:

   1. Define two dynamic objects: "DYN_ISP_A" and "DYN_ISP_B"

   2. Define an object with the IP address of HOST_INTERNAL.

   3. Define an object with the IP address of HOST_VALID_A.

   4. Define an object with the IP address of HOST_VALID_B.

   5. Define two Manual NAT rules, as follows:

      Rule 1

      Source = HOST_INTERNAL
      Destination = DYN_ISP_A
      XlateSRC = HOST_VALID_A
      XlateDST = Orig

      Rule 2

      Source = HOST_INTERNAL
      Destination = DYN_ISP_B
      XlateSRC = HOST_VALID_B
      XlateDST = Orig


      Notes:
          * You still need an inbound static NAT for incoming connections.

          * Do not use the DYN_ISP_objects, created for outbound connections, on the incoming NAT rule. Using them causes the Security Gateways to stop passing all traffic, and you will then need to run fw unloadlocal, and push policy again. Use the HOST_VALID_ objects for incoming connections. For example:

            Rule 1

            Source = Any
            Destination = HOST_VALID_A
            XlateSRC = Orig
            XlateDST = HOST_INTERNAL

            Rule 2

            Source = Any
            Destination = HOST_VALID_B
            XlateSRC = Orig
            XlateDST = HOST_INTERNAL


   6. Run cpstop on the Security Gateway or cluster (on each cluster member).

   7. Run the following commands on the Security Gateway or cluster (on each cluster member):

      dynamic_objects -n DYN_ISP_A
      dynamic_objects -n DYN_ISP_B
      dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a
      dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a


   8. On the Security Gateway or cluster (on each cluster member), edit $FWDIR/bin/cpisp_update, and add the following lines before the "exit" line:

      if ($USE_LINK1 == "1") then

        dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -a

        dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -d

        dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a  

      else

        dynamic_objects -o DYN_ISP_B -r 0.0.0.0 255.255.255.255 -a

        dynamic_objects -o DYN_ISP_A -r 0.0.0.0 255.255.255.255 -d

        dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a

      endif



   9. Run cpstart on the Security Gateway or cluster (on each cluster member).

  10. Install the Security Policy on the Security Gateway/cluster.


Limitation:

In an ISP redundancy Load Sharing configuration, connections originating from HOST_INTERNAL will not be load shared. Instead, they will be routed through the first ISP link, as long as it is active. If the first link fails, outgoing connections from HOST_INTERNAL will be routed through the second ISP link.

Important: You must also configure the Operating System to answer ARP requests for the manual NAT IPs created above.

    * For a single Security Gateway, you can configure permanent ARP entries directly in the OS, or on the upstream router, or by using Check Point's $FWDIR/conf/local.arp file.

    * For clustered Security Gateways, you will need to use the $FWDIR/conf/local.arp file, for the NATs to persist after a failover.