ISP Redundancy and routed public networks

[phima]

Dear all,

May I submit the following issue that some of you may have already encounter and solve ?

We have to migrate an old netfilter-based firewall to VPN-1 with ISP redundancy.
Let's say we have 2 ISPs, connected to the firewall through interconnection-only links, this way :
ISP1 Router : 200.1.1.1/29 - ISP1 firewall interface : 200.1.1.2/29
ISP2 Router : 100.2.1.1/29 - ISP2 firewall interface : 100.2.1.2/29
Additionnaly, each ISP router knows static routes to multiple IP blocks logically located behind the firewall :
ISP1 router knows that 201.1.1.0/25 is reachable via 200.1.1.2
ISP2 router knows that 101.1.1.0/25 and 102.1.1.0/24 are reachable via 200.2.1.2

We know that ISP redundancy works when NAT is performed from/to directly connected networks.
I mean that :
- if I perform nat from/to 200.1.1.3, the next hop will be 200.1.1.1
- If I perform nat from/ro 100.2.1.3, the next hop will be 100.2.1.1

But, when I perform nat from/to routed networks, the next hop used is the system's default one, so that networks
belonging to ISP2 might be seen as sources on ISP1's network, causing asymetric routing, and
concerned traffic to be dropped.
I tried to bybass this behaviour using source routing, but this does not work. I guess this is because routed networks are only used for nat, and no real IPs in the routed subnet really exist.

Can anybody help ?
Thanks,

Philippe / ExaProbe.

[mcnallym]

In ISP Redundancy then all outbound Static NAT traffic will go down the primary ISP link, wether set to use Load Balancing or Primary and Backup.

Your DG should be setup on the Primary ISP link. This is actually documented in the knowledgebase as a known issue, lookup under ISP Redundancy Static NAT. I believe Check Point class this as a design choice, not a fault as such.

I don't think that your existing setup is necessarily suited to Check Point ISP Redundancy as it currently is due to the way that Check Point works.

Normally what you would have is that the DNS points to a DNS Server located in your DMZ so that all DNS requests for your domain go through the Check Point gateway.

The Check Point gateway then intercepts the DNS lookup for A records and then responds with either an IP address from ISP-1 or ISP-2 depending upon how you configure the ISP Redundancy.

Other DNS lookups such as MX will be passed through the Check Point onto the DNS Server which will need to respond.

The traffic then arrives on ISP-1 or ISP2 and is then NATted through to the DMZ.

Effectively each publicly accessible server is NATted behind two IP addresses depending upon which ISP link connecting from.

In the outbound then you also need to create Static NAT's for each Server for going out via both ISP links, but effectively all of the traffic will go through the ISP-1

Hide NAT will need to be done using the AutoNAT with the option set to Hide Behind Gateway, so that the traffic leaves with the address of the gateway interface that the traffic leaves on.

You will need to NAT rather then Route traffic through the firewalls.

[mcnallym]

To allow statically translated hosts in an ISP redundancy configuration for open outgoing connections, use the following procedure. 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 - the internal IP address of the host
HOST_VALID_A - the valid address of the host from ISP_A (the first ISP)
HOST_VALID_B - the valid address of the host from ISP_B (the second ISP)

On the SmartCenter Server:

Define two dynamic objects: DYN_ISP_A and DYN_ISP_B

Define an object with the IP address of HOST_INTERNAL.

Define an object with the IP address of HOST_VALID_A.

Define an object with the IP address of HOST_VALID_B.

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

On the Security Gateway or cluster (on each cluster member), run cpstop.

On the Security Gateway or cluster (on each cluster member), run the following commands:
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
On the 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


On the Gateway or cluster (on each cluster member), run cpstart.

Install the Security Policy on the 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.

In addition to the steps above, you will need to configure the Operating System to answer ARP requests for the manual NAT IPs created above.

For a single firewall, 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 firewalls, you will need to use the $FWDIR/conf/local.arp file, for the NATs to persist after a failover.


Is the contents of the knowledgebase article I was referring too for Static NAT.


In order to ensure that the source IP address of Hide Network Address Translation (NAT) connections going out to the secondary ISP is translated to the IP address of the gateway external interface facing the secondary ISP, perform the following procedure from SmartDashboard:

Procedure:


Select Manage > Network Objects.


In the Network Objects dialog box, select the network object containing the source IP address of the Hide NAT connections from the network objects list.


Click 'Edit'.


In the Network Properties dialog box, select the NAT tab.


In the NAT tab, verify that the 'Add Automatic Address Translation rules' checkbox has been checked.


Select the 'Hide behind Gateway' option.


From the 'Install on Gateway' drop-down list, select the network object that represents the gateway that applies the Hide NAT.


Click 'OK' in the Network Properties dialog box.


Click 'Close' in the Network Objects dialog box.


Reinstall the security policy on the Security Gateway, applying Hide Network Address Translation (NAT).


Note:
The 'Help' files in the SmartDashboard recommend the following procedures for configuring Hide NAT for outgoing connections.

To allow outgoing connections via both ISP links, define automatic Hide NAT on network objects that initiate the outgoing connections.

For example, edit the internal_net object. In the General tab of the Network Properties window, select 'Add Automatic Address Translation Rules', Translation Method Hide, and 'Hide behind Gateway'.

After making the configuration modifications above, the source IP address of Hide Network Address Translation (NAT) connections going out to the secondary ISP is translated to the IP address of the gateway external interface facing the secondary ISP.

Is for HideNAT.

ISP Redundancy tends to be quite limited in my opinion and maybe will improve with time however

[Porter]

ISP Redundancy tends to be quite limited in my opinion and maybe will improve with time however

That's what I hopeing since R55, just recieved a fix from CP these days for ISP Red.