topic Re: GSS4480 and CSS using RFC 1918 addressing in Application Networking

GSS4480 and CSS using RFC 1918 addressing

miwitte — Mon, 21 Jul 2003 18:48:28 GMT

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

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Wed, 23 Jul 2003 07:59:28 GMT

this is a firewall issue.

The firewall needs to translate the dns response.

At least Cisco Pix firewall do so.

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Wed, 23 Jul 2003 11:31:55 GMT

The firewall is a checkpoint so there is no isssue with NATing the DNS response. The question here is how do I give out a internet routable address say 12.12.12.12 from the GSS when the VIP of the CSS is 10.10.10.10?? When I set up the shared keepalives to be the IP address of the load balancer(CSS)this is the IP address(10.10.10.10) that is used as a answer to the client request. Since this is not routable on the internet the DNS query won't work. The only way I can see making this work is to put the GSS in front of the firewall and it would query the NATed internet address of the VIP(12.12.12.12). Then this address would be used as a answer. The only issue I see here is does the KAL-AP by VIP need to go to the actual address of the VIP on the CSS(10.10.10.10) or would the NATed VIP work? Most of the diagrams I have seen are showing the GSS and the CSS in back of the firewall. Are they using internet routable addressing here?? Thanks.

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Wed, 23 Jul 2003 12:03:53 GMT

sorry but I don't see why the DNS query won't work just because this is 10.x.x.x address.

I understand you have this

client --- FW ---- GSS ---- CSS

The query for www.yourcompany.com will come to the GSS, and the response will be 10.10.10.10.

The FW, should look into the DNS payload and replace 10.10.10.10 with a public address 12.12.12.12.

Everything will then work fine.

Once again, the Pix firewall will do this.

You can move the GSS in front of the FW (this is just not very secure since you expose your GSS box to possible attacks).

The response to the Internet will contain the public address.

The KAL to the public address will be translated to the private address. This is no problem.

However, internal users will have the same DNS problem.

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Wed, 23 Jul 2003 12:13:35 GMT

I am not the firewall guy here and need to do a little reasearch on the PIX to see how that works. Is there any links on this. Is this something special the PIX does or is it just standard NATing. I need to see if the Checkpoint will do this otherwise we will have to put the GSS on the internet which of course is not secure. I will look into the PIX, but if you can direct me to a doc on that it would be helpful. If it does change the DNS payload then it will work. Thanks!

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Wed, 23 Jul 2003 13:03:06 GMT

Hi Gilles;

Is this DNS doctoring? I found this link:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aee.shtml

I haven't seen that before.

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Wed, 23 Jul 2003 14:51:06 GMT

yes - that's it 🙂

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Wed, 23 Jul 2003 14:59:22 GMT

That's a new one to me. Now I need the Checkpoint box to do the same thing 😉 If not and I put the GSS outside the firewall and look at the NATed VIP from the CSS, will KAL-AP have trouble with that since the CSS will be reporting that 10.10.10.10 is ok while I am querying the shared keepalive at the NAted address of 12.12.12.12. HMMM

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Thu, 24 Jul 2003 09:30:48 GMT

you can use TAG instead of ip address if the GSS is in front of the firewall.

See the below from the documentation :

If you chose a KAL-AP keepalive type, from the KAL Type drop-down list, choose the format of the KAL-AP keepalive query that you will be sending.

The choices are:

– KAL-AP By Tag—Embeds a unique alphanumeric tag in the KAL-AP request. The tag value is used to match the correct VIP on the SLB, avoiding confusion that can be caused when probing for the status of a VIP on an SLB that is located behind a firewall using network Address Translation (NAT) or that is applying multiple content rules to incoming

requests.

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Thu, 24 Jul 2003 10:26:01 GMT

Sweet! Another solution would be to use some PIX boxes just for DNS but I don't think that would be cost effective. As far a the KAL-AP by tag:

Enter a unique alphanumeric value in the Tag field. This is used as a "key" by the Content Services Switch or the Content Switching Module to match the KAL-AP request with the appropriate VIP. Does this key need to have a matching key on the CSS? Thanks for all the help so far.

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Fri, 25 Jul 2003 07:57:13 GMT

on the CSS, you first need to configure app-udp in global config mode, then under the content rule you define the TAG/key with the command:

"add dns "

I think we're close to the solution now 🙂

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Fri, 25 Jul 2003 12:34:11 GMT

It looks like app-udp is on by default. as far as the tag: On the GSS, I would go into the shared keepalives and specify the NATed VIP of our CSS. Then configure KAL-AP by TAG and use the tag "TESTTAG" . Then under the content rule define this tag:

content WebServers

protocol tcp

port 80

vip address 10.10.10.10

add service USSvr1

add service USSvr2

add dns TESTTAG

Sound about right?

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Fri, 25 Jul 2003 12:45:03 GMT

Looks good to me.

Gilles.

Re: GSS4480 and CSS using RFC 1918 addressing

miwitte — Fri, 25 Jul 2003 13:46:51 GMT

I let you know how we make out. Thanks for all the help this was not straight forward.

Re: GSS4480 and CSS using RFC 1918 addressing

cbuzzard — Mon, 28 Jul 2003 16:46:51 GMT

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.

Re: GSS4480 and CSS using RFC 1918 addressing

fhunter — Fri, 10 Oct 2003 10:11:57 GMT

Hi,

Did you find a similar feature to the PIX DNS Doctor on the Checkpoint? I have a very simaler problem and need to NAT the data portion of a DNS responce through a Checkpoint FW.

Frank

Re: GSS4480 and CSS using RFC 1918 addressing

fhunter — Fri, 10 Oct 2003 10:15:43 GMT

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

Re: GSS4480 and CSS using RFC 1918 addressing

scottmac — Sun, 12 Oct 2003 14:49:14 GMT

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

Re: GSS4480 and CSS using RFC 1918 addressing

Gilles Dufour — Mon, 13 Oct 2003 10:07:14 GMT

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.