CSS, Groups, and return traffic

[mlanglois]

Can someone explain to me what the difference is when some of my content seems to load balance 'correctly'. Return traffic appears to be sent to the VIP... BUT some of the traffic I need to actually configure a group for... to get the return traffic to come back to the vip instead of directly to the client (and thereby failing when it hits the firewall)

[skumar1969]

Much talked about topic.

The CSS spoofs the client browser ip to the servers that it load balances. To stop this default behaviour configure "add destination service " under the group config. Drawback is you would see CSS circuit address as the source address, in the server logs that tells you who access your website.

On the other hand, if you do not SNAT (using groups) outgoing server initiated traffic never gets SNATed as expected and goes raw with the real server ip. I think this is your problem. Correct it by configuring a group for all the servers that needs outgoing access. May want to use ACL for this purpose.

thanks

[mlanglois]

Let's assume we are talking about DNS load balancing instead of http... or even port 8080 in the case of load balancing a proxy server...

Is the CSS still supposed to spoof the ip of the client or is that function only http and https?

[Gilles Dufour]

By default the CSS spoofs the client ip address.

Most people wants the CSS to do this because they run statistics on the server and they want to be able to see the real client ip address in the server logs.

If you do not need such thing, you can configure a group to nat all client ip addresses.

The advantage of this solution is that it guarantees the traffic to return to the CSS.

This is absolutely not dependent on the protocol.

Gilles.

[mlanglois]

I am at a loss then because my CSS is responding differently for 2 different protocols... If I do NOT create a group for the DNS content the DNS server will reply DIRECTLY to the client with it's very own IP... not the VIP.... I did not have to do this for https.

Here is how they are setup...

______________________________

service PubProxy1-DNS

port 53

ip address 192.168.1.6

service PubProxy1-HTTPS

port 443

keepalive type ssl

ip address 192.168.1.6

active

service PubProxy2-DNS

ip address 192.168.1.7

port 53

active

service PubProxy2-HTTPS

ip address 192.168.1.7

port 443

keepalive type ssl

service PubProxy3-DNS

ip address 192.168.1.9

port 53

active

service PubProxy3-HTTPS

ip address 192.168.1.9

port 443

keepalive type ssl

active

content Proxy-DNS

protocol udp

port 53

add service PubProxy2-DNS

add service PubProxy3-DNS

add service PubProxy1-DNS

vip address 192.168.1.13

active

content Proxy-HTTPS

add service PubProxy1-HTTPS

add service PubProxy2-HTTPS

vip address 192.168.1.8

protocol tcp

port 443

application ssl

balance aca

flow-timeout-multiplier 450

add service PubProxy3-HTTPS

active

group Proxy-DNS

vip address 192.168.1.13

add destination service PubProxy2-DNS

add destination service PubProxy3-DNS

active

[Gilles Dufour]

I was partially wrong.

The CSS makes a difference between TCP and UDP.

For TCP the CSS will create 2 flows. 1 for inbound traffic and 1 for outbound traffic.

Therefore when the server responds to the client, it will match the outbound flow and the CSS will know it must nat the server ip with the vip.

For udp, this is different.

The CSS only creates the inbound flow.

So, for the outbound flow, by default the CSS simply route the server traffic.

A group is always required for udp traffic.

But there are 2 options.

You can create a group to nat the inbound flow client ip address. In this case, the CSS will create a 2nd flow for the outbound direction.

The other solution is to create a group to catch the server traffic and perform nating of the server ip.

In your case you could do :

group DNS

vip address 192.168.1.8

add service PubProxy2-DNS

add service PubProxy3-DNS

active

The CSS will continue to spoof the client ip - on the backend/server side, but it will also catch the server response and perform nating for server ip into vip.

Hope this makes sense like this.

Gilles.

[mlanglois]

YES...!!!!!!!!!! that makes a lot of sense.... and was what I actually suspected but I couldn't find a link on cisco's website that would say what you just said.... THANK YOU!

I thought I saw this very same problem though with port 8080 traffic.. tcp.. when trying to load balance proxy services... however I am load balancing them across disparate LANS.... would that cause a flow/natting issue as well? The config is below...

Based on what you relayed to me... then even if it's tcp. If it isn't FORCED through the CSS... since the CSS spoofs the client ip... the traffic will simply head back to the client directly. If forced through the CSS though it will understand that it has a matching flow and 'rewrite' the packet to look like the reply is coming from the CSS?

service DRProxy1

ip address 192.168.48.28

port 8080

protocol tcp

keepalive port 8080

keepalive type tcp

weight 4

active

service Proxy1

ip address 192.168.96.17

port 8080

protocol tcp

keepalive port 8080

keepalive type tcp

weight 0

active

content Proxy

add service Proxy1

add service DRProxy1

balance aca

protocol tcp

port 8080

url "/*"

advanced-balance arrowpoint-cookie

vip address 192.168.97.248

active

group Servers

add destination service Proxy1

add destination service DRProxy1

vip address 192.168.97.248

active

[Gilles Dufour · Accepted solution]

indeed, even for tcp, you need to make sure the response from the server goes back through the CSS so that the appropriate address translation can be perform.

So, if your servers are one or more hops away, there is a chance that the response will bypass the CSS and go directly to the client which will reject it not expecting a response from the server but from the css.

With your group config in place, you do client nat. So, this should guarantee the response back to the CSS but as mentioned before will prevent the server to recognize the client based on its ip address since all traffic will be coming from the css address.

Gilles.

[mlanglois]

Thanks...

Very helpful...

[skumar1969]

Gilles,

When you say the following in quotes what exactly did you mean. You say for udp, things are different. If it is a TCP or UDP it doesn't matter to the CSS. You still need 2 groups. One group to do client NAT-ing the inbound and another group to do the SNAT-ing the outbound.

In TCP even if you do not have a Source group in place it is going to head back straight to the clients bypassing CSS by all means. I am wondering what is different in UDP.

"For udp, this is different. The CSS only creates the inbound flow. So, for the outbound flow, by default the CSS simply route the server traffic. A group is always required for udp traffic."

thanks

[Syed Iftekhar Ahmed]

A CSS uses data structures called flow control blocks (FCBs) to set up and keep track of ingress flows. FCBs contain all the information the CSS needs to process

and manage flows.

UDP flows are typically unidirectional . A UDP flow has no definitive beginning or end and is considered completed only after a period of time has elapsed during which the destination device receives no packets.

The CSS sets up a Flow Control Block (FCB) in one direction only when a UDP packet is processed. The FCB for the return path will only be set up if the response packet arrives. Because of the uni-directional nature of UDP source A UDP content rule must have a corresponding source group to handle the return UDP traffic and to provide the mapping between the two sides of the UDP flow. In the case of DNS this is the DNS response

to the initial DNS request.

Syed Iftekhar Ahmed

[Gilles Dufour]

if your network is such that the server traffic bypassed the CSS, yes you indeed also need a group for TCP traffic to nat the client ip address.

What I was saying is that for UDP, even if the traffic from the server is sent correctly to the CSS [without client nat], a group is required to nat the server ip into the virtual ip.

This is not required for TCP and is done automatically.

Gilles.