Source Groups & IP Logging

[stevanp]

Our server administrators would like to start logging connections to the web servers and tried to do so but keep seeing the IP addresses of the load balancers in their logs.

We are using source groups on the CSSes since they are sitting behind a set of firewalls; and, we found that the servers would be blocked when removing the source groupings. I have attached a rough diagram of how we are configured.

How do we transmit the remote clients' IP address to the web servers?

[Gilles Dufour]

if you use sourcegroup there is no way to retain the client ip.

You have to find a way to get rid of the sourcegroup.

It should be possible in your case since you are not using one-armed mode but instead an inline solution where the server, CSS, and gateway are inline.

Gilles.

[stevanp]

We actually are using a one-armed configuration and the default gateway is our firewall, reason for the sourcegroup.

However, I realized something last night that I am going to test this morning. I could change the default gateway of the servers to point to the load balancers and disable the sourcegroups.

One issue I could see myself running into is the fact the client machines would be pointed to one of two CSSes. Is there a type of redundancy similar to HSRP that the CSS uses?

[Gilles Dufour]

there is a vrrp/hsrp like feature on the CSS.

This is called redundant interface.

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_tech_note09186a008009432f.shtml

Be aware that the CSS wants to see both side of a connection.

So, if you have connections going directly to the server, you will have asymetric traffic as the firewall will not send the traffic to the CSS when the destination is the server.

You should maybe consider a bridge mode solution.

connect the servers on one side of the CSS and the firewall on the other side and have the CSS bridge both side.

No need to change the gateway and you can guarantee that the traffic always goes through the CSS.

Gilles.

[stevanp]

We were able to successfully connect to the VIP from the Internet with the removal of source groups and pointing the servers to the CSS as the def gateway.

We ran into an issue where the clients on the LAN would connect to the VIP and then get no response back. I believe this to be due to the fact we are crossing the firewall on a higher security interface and trying to come back over on a lower security interface. The source of the IP from the LAN is NATed to an address that is on the local network for the CSS, therefore the servers respond back directly to our NAT address instead of going to the CSS and back out, as in the case of the Internet connection.

Keep in mind that we are one-arming this configuration and using a firewall sandwich, as indicated in the diagram. The firewalls have their higher security interfaces point back toward the LAN.

Would I still need to bridge? Do you have an example I may look at to verify it would work? (We would like to be able to track IP addresses on the servers.)

[mbaylis]

Hi Giles,

I am in a similar situation to this guy. We also want to retrieve real client IP addresses from the servers, but because of us also using source group configuration we are unable to see real client addresses instead the loadbalancer addresses.

Unlike this guy we don't have a firewall in front of the loadbalancers, so if I turn off source group and create a redundant interface for the server default gateway, will I run into any problems you can think off?

At this moment the servers & loadbalancers are pointing to a firewall (which contains various aliases).

please see the basic quick topology i did to help you visualise what i am working with.

your help is very important to me.

Thanks