cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
488
Views
0
Helpful
18
Replies
Highlighted
Enthusiast

GSS4480 and CSS using RFC 1918 addressing

We are in the process of testing out a load balancing/redundancy setup using the GSS4480 and a CSS11506. Right now the CSS is setup with RFC 1918 addressing and we NAT out to the internet using a Checkpoint firewall. If I setup my VIP answer file to poll the 1918 address of the CSS, then that will be the answer that is given out when a client requests a name lookup which won't work. There has to be a way to configure this or then all diagrams I have seen are using internet routable name spaces. Looking at the docs and playing with the GUI I don't see any way of configuring it to use RFC 1918 addressing behind the firewall and still give out internet routable domain names. The docs show's the GSS and CSS being behind firewalls. I guess I am just missing something. Can the CSS be configured to link the RFC1918 address to a public address for KAP-AP purposes? Also is there any issues with NATing to RFC 1918 addresses for the health probes to other GSS's. We would like the health probes to go out over the internet not over our back end. Thanks

18 REPLIES 18
Highlighted

Hi,

I have just been told Checkpoint does not support DNS data NATing or ALG (Application Layer Gateways)how did you get arround this problem.

Frank

Highlighted

our issue really isn't the DNS request as more it is the APP session between the GSS and CSS. We have 2 GSS devices that will be located at different data centers. Going by how the GSS docs say they work, the primary GSS synchronizes its database to the secondary when it comes online. With this the case we can't give our GSS(s) 1918 addresses since they'll be in different locations the secondary won't be able to reach the 1918 address of the primary. We have not proven this, but going on what the documentation says this is how it works. Now if we can configure our GSS(s) with 1918 addresses and just NAT their connection as they go out the FW and that's how they learn of each other then that issue becomes moot.

Going with our current problem here's the rest. Since the GSS(s) are outside the firewall they are polling CSS(s) that are located behind the firewall. All NAT is done on the FW so the CSS is completely 1918 addressed. The GSS is polling the circuit IP of the CSS which is a real address that the FW NATs to the 1918 address. The problem arises when the GSS queries the CSS the request is received, however it's for a real address and not a 1918 address.

We thought about duplicating all the content rules with the real addresses as the VIP; this works, but since the users aren't going through those rules the GSS is never going to get anything more than 2 on the load.

Highlighted

I'm a bit new to this stuff, but wouldn't a purpose-specific VPN or tunnel resolve the issue? Allow the two units that are remote to each other pass update info through the VPN/Tunnel?

Or perhaps a static NAT mapping (this address to that device/port) implemented each way?

Chances are I'm out of line, but some flavor of encrypted tunnel ought to allow you to permit the two devices to communicate without jumping through too many hoops (if I'm understanding the problem).

Possible?

.02

Scott

Highlighted

if you read this thread, you will see that the solution to polling the CSS, is to use KAL-AP by TAG.

Using a TAG is not dependent on the ip address being

used for the communication.

For the first part of the question, I assume static NAT should resolve the problem.

Gilles.