Static NAT fails for outgoing connections through gateway with ISP Redundancy in Load Sharing mode

Symptoms
  • Static NAT fails for outgoing connections through gateway with ISP Redundancy in Load Sharing mode.
  • When one of the ISP links is down, connections are routed through incorrect interface.
  • Kernel debug shows (fw ctl debug -m fw + nat drop):
    FW-1: fw_first_packet_xlation: Dynamic object is already being resolved - vanishing packet
    fw_log_drop: Packet proto= ... dropped by fw_first_packet_xlation Reason: Dynamic object is already being resolved


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


Notes

  • Assume that a host in question (located on the internal network behind Security Gateway/Cluster) 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:
    • DYN_ISP_A = name of the object that represents first ISP (ISP_A)
    • DYN_ISP_B = name of the object that represents second ISP (ISP_B)
    • HOST_INTERNAL = name of the object that represents internal IP address of the host on the internal network behind the Gateway/ClusterXL
    • HOST_VALID_ISP_A = name of the object that represents valid address of the host from the pool of first ISP (ISP_A)
    • HOST_VALID_ISP_B = name of the object that represents valid address of the host from the pool of second ISP (ISP_B)

Procedure

  1. In SmartDashboard, define two Dynamic objects (Network Objects - Dynamic Objects - Dynamic Object...) that will represent the two ISP links: 'DYN_ISP_A' and 'DYN_ISP_B'.
  2. In SmartDashboard, create a Host Node object (Network Objects - Nodes - New Node - Host...) that will represent the internal IP address of the host on the internal network: 'HOST_INTERNAL'.
  3. In SmartDashboard, create a Host Node object (Network Objects - Nodes - New Node - Host...) that will represent the external IP address of the host from the IP address pool of first ISP: 'HOST_VALID_ISP_A'.
  4. In SmartDashboard, create a Host Node object (Network Objects - Nodes - New Node - Host...) that will represent the external IP address of the host from the IP address pool of second ISP: 'HOST_VALID_ISP_B'.
  5. In SmartDashboard, create a default NAT rule for HOST_INTERNAL that maps HOST_INTERNAL to HOST_VALID_ISP_A. This can be done either by editing the HOST_INTERNAL object and defining 'Automatic Static NAT', or by creating appropriate Manual Static NAT rules. If you create Manual Static NAT rules, make sure they are moved towards the bottom of the NAT rulebase.
  6. In SmartDashboard, define two Manual NAT rules for inbound connections (in case inbound connections are requried).
    Note: Order of incoming and outgoing connections is important. Placing outgoing rules before incoming rules may impair Security Server functionality.
    Example of rules:
    NoORIGINAL PACKETTRANSLATED PACKET
    SOURCEDESTINATIONSERVICESOURCEDESTINATIONSERVICE
    1AnyHOST_VALID_ISP_AAny= OriginalHOST_INTERNAL= Original
    2AnyHOST_VALID_ISP_BAny= OriginalHOST_INTERNAL= Original

  7. In SmartDashboard, define two Manual NAT rules for outgoing connections (a rule for each ISP link) - use the objects 'DYN_ISP_A' and 'DYN_ISP_B'.
    Note: Order of incoming and outgoing connections is important. Placing outgoing rules before incoming rules may impair Security Server functionality.
    Example of rules:
    NoORIGINAL PACKETTRANSLATED PACKET
    SOURCEDESTINATIONSERVICESOURCEDESTINATIONSERVICE
    3HOST_INTERNALDYN_ISP_AAnyHOST_VALID_ISP_A= Original= Original
    4HOST_INTERNALDYN_ISP_BAnyHOST_VALID_ISP_B= Original= Original

  8. On the Security Gateway / each member of ClusterXL, run 'cpstop' command.
  9. To complete the definition of Dynamic Objects, it is necessary to run the following commands on the Security Gateway / each member of ClusterXL:
    Note: "DYN_ISP_A" and "DYN_ISP_B" are the names of the objects that represent the first ISP and second ISP, respectively. When running the commands below, you have to use the exact object name from SmartDashboard (case-sensitive).
    [Expert@HostName]# dynamic_objects -n DYN_ISP_A
    [Expert@HostName]# dynamic_objects -n DYN_ISP_B
    [Expert@HostName]# dynamic_objects -o DYN_ISP_A -r 0.0.0.0 0.0.0.0 -a
    [Expert@HostName]# dynamic_objects -o DYN_ISP_B -r 0.0.0.0 0.0.0.0 -a
    
    Note: To see the correct usage and syntax, just run 'dynamic_objects' command.
  10. On the Security Gateway / each member of ClusterXL, edit the $FWDIR/bin/cpisp_update script, and add the following lines at the end of the script - before the "exit" line:
    Note: "DYN_ISP_A" and "DYN_ISP_B" are the names of the objects that represent the first ISP and second ISP, respectively. When running the commands below, you have to use the exact object name from SmartDashboard (case-sensitive).
    # Verify which link is up with this command: tail -f /tmp/cpisp_state
    echo "--------------------------" >> /tmp/cpisp_state
    echo `/bin/date +%d-%b-%Y_%Hh-%Mm-%Ss` >> /tmp/cpisp_state
    echo "RESTARTING SCRIPT" >> /tmp/cpisp_state
    echo "LINK1" >> /tmp/cpisp_state
    echo $LINK1_STATE >> /tmp/cpisp_state
    echo "LINK2" >> /tmp/cpisp_state
    echo $LINK2_STATE >> /tmp/cpisp_state
    echo "--------------------------" >> /tmp/cpisp_state
    echo " " >> /tmp/cpisp_state
    
    # Check if the Link is up or down
    if ($LINK2_STATE == "down") then
    fw tab -t dynobj_cache -x -y
    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 
    endif
    
    if ($LINK1_STATE == "down") then
    fw tab -t dynobj_cache -x -y
    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
    
    # if both Links are up, return to Load Sharing
    if (($LINK1_STATE == "up") && ($LINK2_STATE == "up")) then
    fw tab -t dynobj_cache -x -y
    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 -a
    endif
    
  11. On the Security Gateway / each member of ClusterXL, run 'cpstart' command.
  12. In SmartDashboard, install the Security Policy onto Security Gateway/ClusterXL.

Limitations

  • In ISP Redundancy in Load Sharing mode, 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 ISP link fails, outgoing connections from HOST_INTERNAL will be routed through the second ISP link.
  • In case of ISP Redundancy fail-over, existing connections originating from HOST_INTERNAL will lose connectivity.

Important

  • On the Security Gateway / each member of ClusterXL, it is also necessary to configure the Operating System to answer ARP Requests for the Manual NAT IP addresses that were created above. This is done with the help of $FWDIR/conf/local.arp file.
    Refer to  for instructions.
  • Before upgrading this Security Gateway / Cluster, back up the modified $FWDIR/bin/cpisp_update script because during the upgrade, it will be overwritten by the default script.
    After upgrading, replace the default script with your the modified script.

Comments

Popular posts from this blog

Download IOS Image for Router

tcpdumps in Checkpoint Firewall