cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
648
Views
0
Helpful
2
Replies

Web server accessing a load-balanced VIP

mromer
Level 1
Level 1

I have a test environment consisting of a single CSS 11052 with several servers behind it. The two web servers have their web sites defined in the CSS, and the CSS is providing a load-balanced VIP. For example, the CSS provides a VIP of 10.149.162.211 in VLAN5 for two web sites with IP addresses of 172.17.1.20 and 172.17.1.21 in VLAN4. Hosts outside this environment can reach the load-balanced site perfectly well.

I've had a request to allow the web servers themselves to browse to the load-balanced VIP. They currently aren't able to do this, and I can't figure out why. Is this a characteristic of the CSS, or is there something I can do to allow the servers being load-balanced to access the balanced load IP?

-Mark

1 Accepted Solution

Accepted Solutions

peucale
Level 1
Level 1

Hi,

the problem is that the SYN packets are sent from the server to the CSS and are NATed there. Then the NATed packets get sent back to the servers. A new TCP connection is established and after that ACK packets are sent back to the source which is on the same local net. So these ACK packets are not sent to the CSS to be 'reNATed', but directly to the initiator. But that initiator does not have a TCP state for this SRC/DST pair as they only have one for the NATed address, so the packets are discarded -> no TCP connection possible.

The only possibility is to add source groups to the CSS and ACLs to also NAT the source addresses for connection attempts from the servers to themselves which is quite complicated.

-alex

View solution in original post

2 Replies 2

peucale
Level 1
Level 1

Hi,

the problem is that the SYN packets are sent from the server to the CSS and are NATed there. Then the NATed packets get sent back to the servers. A new TCP connection is established and after that ACK packets are sent back to the source which is on the same local net. So these ACK packets are not sent to the CSS to be 'reNATed', but directly to the initiator. But that initiator does not have a TCP state for this SRC/DST pair as they only have one for the NATed address, so the packets are discarded -> no TCP connection possible.

The only possibility is to add source groups to the CSS and ACLs to also NAT the source addresses for connection attempts from the servers to themselves which is quite complicated.

-alex

Thank you, Alex. That is exactly what I needed to know.

-Mark

Review Cisco Networking for a $25 gift card