destination source group

axfalk · ‎09-08-2008

I am trying to understand the rationale for destination source group, where one NATs source IP addresses and source ports for flows originating from a client on the public side of the CSS.. Wouldn't those addresses be public in the first place, so why NAT them?

thanks.

Syed Iftekhar Ahmed · ‎09-08-2008

Destination source group (or Source NAT) is needed in situations when there is a chance that response traffic from the Real Servers may bypass the CSS.

If Server's default gateway is pointing towards the CSS and its for sure that response traffic will always pass through the CSS then Destination group/Source NAt is not required.

HTH

Syed Iftekhar Ahmed

mrabetyoussef · ‎09-11-2008

Hi,

I understand your point, but it seems to me that using the group/destination source, the source address is translated to the VIP (on the public side) and not to the redundant-vip (on the private side).

If the server's default gateway doesn't point toward the CSS, this configuration makes it respond to the CSS on the public side. While this isn't a real problem, it's not really optimal in case the Server and the CSS are in the same private subnet. It would be better if the server can respond to the CSS on it's private side interface.

Question : is it possible to achieve this by making the CSS NAT the source address to its redundant-vip instead of its vip?

Youssef

mrabetyoussef · ‎09-11-2008

I meant to NAT the source address to the redundant-interface IP instead of the redundant-vip address.

Sorry

tim.metzinger · ‎09-09-2008

Way back when, we were told to put the CSS in the network path between back-end servers and clients.

With the source group, the CSS becomes a true NAT proxy, not just a "splicing" device. So the CSS may no longer be "between" source and destination.

Example:

I used to have my network like this

Router <-> firewall <-> CSS <-> LAN switch.

Problem was, if the CSS went down or rebooted, it was 5 minutes or so before I could pass any traffic to devices on that LAN switch. But I never had to worry about out-of-path returns as the CSS was always "between" the clients and the backend servers.

Now, I have it set up like this:

Router <-> firewall <-> LAN Switch, and the CSS hangs off of the LAN switch. When my CSS died one day and rebooted, I didn't lose connectivity with all the un-balanced servers on that LAN. All I lost was the CSS VIPs.

Hope this helps.

axfalk · ‎09-10-2008

Thanks for the responses. I understand the underlying reasons for using the source groups. I also understand the concept behind the source groups as the servers, by and large, have private addresses assigned to them. What I am trying to clarify is why do we need to NAT the clients' already public addresses when using the destination service to a group? Am I missing something here?

thanks..

Syed Iftekhar Ahmed · ‎09-10-2008

If CSS is deployed in one arm mode then there is a possibility of bypassing the CSS by Real Server responses.

Translating the client's public addresses (to IP addresses managed by CSS) ensures that the return traffic will pass through the CSS.

Syed Iftekhar Ahmed