I have two CSS devices, one set up at HQ and the other in DR.
Both are outside our Firewalls in one armed config mode.
Normal operation has HQ interenet intact and Web requests go to HQ servers, if HQ servers are down, the HQ CSS directs to DR through internal network.
If we loose HQ internet, the reverse happens from DR.
All of this is working as expected, but the source NAT from CSS using "destination service" is causing us problems and we need to get away from it.
The Firewalls will have to see the source IP addresses of the clients.
I am wondering if I were to move to the Global Server Load Balancing using DNS will solve this problem?
If the CSS stays where it is and is resolving names to the servers for the client, and the address is a NATed address on the Firewall, I should be ok as far as the servers seeing the source address of the request correct?
you first need to understand why you have the client nat (group) in place.
I would say this is because you are in one-armed first and also because you use in HQ servers that are remote (DR).
When in one-armed the response from the server will by default bypass the CSS.
But the CSS needs to see it for the communication to work.
So the basic solution to do client nat.
If you remove client-nat, you need to find another way to guarantee that the response fro m the servers goes back to the CSS.
Could be policy routing or making the CSS the default gateway. Another solution is to move to inline instead of one-armed.
Then, the remote servers.
There you have no choice but doing client-nat.
GSLB could be a solutionas well or if you are using exclusively HTTP, you could use an http redirect.
With GSLB, don't forget that dns response are cached by dns proxy. So, if a site goes down, it could take sometimes to see the connections being forwarded to the other side.
Might be easier to reconfigure the firewall to accept connections from the nated ip address.
Maybe by using a different ip for the nating.
Thanks for the reply.
The problem is that we need to track the source IP addresses of clients hitting our servers. This is part of authentication challenge.
Currently the CSS sits on the Outside Internface of our Firewalls.
The services in the CSS at HQ take the requests from the clients looking to the VIP (public IP Address), then forwards them to the available service which is also a Public IP Address NATed on Firewall Outside Interface for HQ server. If that is not available, it forwards to the DR server which is a Public IP Address NATed to the outside Interface of the Firewall.
So, if I allow it in the firewall, both the HQ and DR servers would allow client requests directly to Public IP Addresses.
Currently the only IP address thatt hits the NATed Public IP of the HQ and DR servers (in HQ Firewalls) is the "destination-service" ip address configured in the CSS.
I am thinking that I should be able to have the CSS use the DNS funtion to help solve this problem.
All I am looking to do is have the CSS resolve the name for the client of the primary server, if that is not available to secondary server.
If the HQ internet is down, go to DR CSS.
So basically, I need the CSS to do name resolution and have the client connect directly to which NATed public IP Address I want.
Can I do this with a CSS in my current layout?
If the CSS is only resolving names for the client, it should have the client connect directly to the resolved name which will be the PIX NATed addres for the server, correct?
You would need a GSS to do that.
You might get something working with GSLB on the CSS by configuring dns-record on each CSS pointing to the local vip with one of the keepalive to detect if the vip is alive or not
dns-record a www.gduf.net 10.1.1.1 5 single kal-icmp
Also add the preferlocal option
dns-record a www.gduf.net 10.1.1.1 5 single kal-icmp 10.1.1.5 254 sticky-enabled preferlocal
This requires app-udp.
It should work like this.
However, this is not always perfect as client usually do not query the CSS directly but their local dns server which does cache the answer.
How does the GSS solve the problem of the client cache?
Maybe you can help me understand this:
If the CSS becomes Authoritive for the Zones I create on it, and I tell my DNS host guy this, and he updates his DNS server,
why wouldn't all DNS servers be updated with this new information to look to the same place my DNS host has pointed his DNS server to, which would be my CSS?
the GSS won't help for the caching of the response. It just allows to better control what response to send to the dns query.
For the problem of direct dns access to the css, a client is always setup to query its own dns server which in turn queries the root server which, redirect the request to your site, which delegates the 'www' address to the css which does see the request coming from one of those intermediate dns server but never the client.
The response is then cached by those dns servers.
For http traffic, you can use http redirect so if the client still comes back to the wrong css, you can send it a redirect to the other css.
Can we use a CSS to replace load-balancing product
like Linkproof and F5 link-controller? I mean can perform inbound and outbound load-balancing .
the CSS is not an ISP/WAN link loadbalancer.
It was designed to loadbalance requests coming to a virtual server to a group of real server.
However, you could use it to loadbalance between routers, each one having a different WAN link.
Thanks for the reply,
a couple more questions:
Is the cache a huge problem in production?
For example, according to Microsoft, the unsuccessful rety attemt interval for cached DNS entried is five minutes, successful is one day.
So, if I have a server failover, when the remot eclient tries to connect from the cached entry and gets "Page cannot be displayed", within five minutes the client should requery DNS correct?
Or is the problem other DNS hosting server cahcing their entry for longer periods of time?
Do you hear of alot of problems using the CSS this way?
With zone based DNS can you still configure the service to check an index page in the keepalive?
If so, how would that be done?
I have never heard of somebody complaining about dns cached information.
But I always set the expectation correctly :-)
You can use whatever keepalive you want for your service. However, the dns-record uses its own keepalive system which is different.
Use the '?' to see available option.
I believe kal-icmp or kal-vip are there.
You could have vip using your service, that uses the http kal and then you use a dns-record using a kal-vip pointing to that vip. [hope this makes sense like this - I don't have access to my lab right now, so can't send you sample configs)
Here is an example of dns-record using the public ip for the response, but the private ip for the keepalive.
dns-record a www.gduf.net 126.96.36.199 5 single kal-icmp 10.1.1.5 254 sticky-enabled preferlocal
So, 188.8.131.52 would be the public ip and 10.1.1.5 the private.
Wouldn't using the VIP put me back to having to use the "destination service" because I am in one armed mode?
not sure what you mean here by using the vip.
If I understand you goal, you want to use a dns answer that would redirect the user to the appropriate site.
So, your dns-recor will be setup with your local public ip.
The remote css will be setup with its own local public ip.
You then configure app between the sites so the 2 CSS can exchange their dns-record info.