NAT confusion

shathaway · ‎03-24-2005

Hello,

I apologize if this is a newbie question that has been asked a thousand times, but...

I have inherited a one-armed setup (11501) with this unit out on a DMZ.

It will be accessed both from the internet, and the inside network. (10.x.x.x)

I have two servers, app1 (192.168.1.10) and app2 (192.168.1.12) running Oracle IAS, and I want them to

appear as APP (192.168.1.4). I have tried several configurations from the documentation, and from here and they either don't work at all (no content), or eventually the real server's address gets exposed.

(if I start out at APP.my.domain, at some point I am told I am talking to app1.my.domain)

I would really rather not change the topology if possible, as it would mean all night in a data center 2hrs away...

Has anyone been able to do this? What am I missing?

Thanks in Advance. Below is the relevant part of my current config (which does not work) I have tried "add service app1" and "add destination service app1", ACL or no ACL, etc.

!************************** SERVICE **************************

service app1

ip address 192.168.1.10

string cookieapp1

active

!*************************** GROUP ***************************

group servers

vip address 192.168.1.4

add destination service app1

active

!**************************** ACL ****************************

acl 1

clause 10 permit any 192.168.1.8 255.255.255.248 destination any sourcegroup servers

apply circuit-(VLAN1)

skumar1969 · ‎03-24-2005

!************************** SERVICE **************************

service app1

ip address 192.168.1.10

string cookieapp1

active

service app2

ip address 192.168.1.12

string cookieapp1

active

service app1-out

ip address 192.168.1.10

active

service app2-out

ip address 192.168.1.12

active

!*************************** GROUP ***************************

group servers

vip address 192.168.1.4

add service app1-out

add service app2-out

active

The above config pretty simple and straightforward not using the ACL. It would permit all the outgoing traffic intiated by the servers and will have the src ip as 192.168.1.4.

If you are using VRRP config at the client side add this ip address under the Virtual-Router as ip redundant-vip xx 192.168.1.4 on both pri and backup CSS.

thanks

Gilles Dufour · ‎03-25-2005

where is your content rule ?

You need to configure a content rule.

owner MyCompany

content APP

vip add 192.168.1.4

add service app1

add service app2

active

!

The group config is to nat traffic initiated by the server or to nat the client ip when traffic hits a content rule.

If your CSS is in a one-armed mode [that is the server can bypass the CSS to talk to the client], you will need the gorup you have configured with 'add destination service ...'.

If your application is udp based, you need a group with 'add service ...' [remove the keyword destination] in order to nat the udp response from server to client.

Regards,

Gilles.

shathaway · ‎03-25-2005

Well, I tried these, and the app1-out solution doesn't seem to work at all.

To be clearer about what I am trying to do, as I said, I am trying to get from an internal client at 10.x.y.z to APP at 192.168.1.4.

APP is the VIP on the CSS, and should be hiding 192.168.1.10 and 11 "behind" it.

This is a one-arm configurations, so my understanding

is that when the request comes in to the CSS, some part of the config should translate the destination address from 192.168.1.4 to one of the actual server addresses, and the source address to itself (192.168.1.4? or should it be the address of the VLAN?) so the server's reply goes back to the CSS.

When it gets back to the CSS, the destination address should be translated back to the real client's address (10.x.y.z), and the source address to 192.168.1.4, so the client thinks it is talking to APP, and not one of the actual servers.

Does this make sense? Is this possible? I included most of the current config (which doesn't work) in case I am missing something, or something else is wrong.

Thanks again for your help.

!************************** CIRCUIT **************************

circuit VLAN1

redundancy

ip address 192.168.1.21 255.255.255.0

no redirects

!************************** SERVICE **************************

service app1

ip address 192.168.1.10

string cookieapp1

active

service app1-out

ip address 192.168.1.10

active

service app2

string cookieapp2

ip address 192.168.1.12

active

service app2-out

ip address 192.168.1.12

active

!*************************** OWNER ***************************

owner myapp

content webapp

vip address 192.168.1.4

arrowpoint-cookie expiration 00:03:00:00

balance aca

protocol tcp

port 80

url "/*"

advanced-balance sticky-srcip-dstport

add service app1

add service app2

active

!*************************** GROUP ***************************

group servers

vip address 192.168.1.4

add service app1-out

add service app2-out

active

skumar1969 · ‎03-25-2005

My apologies Shathaway.

The config I gave previously suits good for a 'Routed Config' on the CSS where you got more than one interface on the CSS to connect the client side as well as the real servers. I was ignorant of the fact that you had a single-armed topology. I given a modified version of the config below.

I modified the config to include "add destination service" under the source group. Many of us think that source-group is only meant for outgoing traffic. Its half true because this command is also used for incoming traffic in a single-armed environment.

The trick here is that on the incoming traffic destined to the VIPs, CSS then spoofs the client ip address by re-writing only the destination ip address/port (aka. destination NAT-ing) leaving the src ip address untouched when it talks to the servers on its behind. In otherworlds CSS uses client ip address as the source ip address on the packets it is pumping to the servers behind. This is admissible in a 'Routing topology' since the traffic is going to be on 2 different interfaces/VLAN and the client won't know/care that CSS is actually spoofing its ip address when it talks to the servers. It hurts when it comes to single-armed config for reasons briefed below. So, when it comes to single-armed, you must not only NAT the destination address of the packet but the source addresses as well.

Assuming a situation wherein you haven't used this command in a single-armed config, the response/reply-traffic would have simply passed through the L2 switch reach the router gateway and finally on to the clients because the servers are pointing their default-gateway to the router. Now the client will actually be surprised to see the packets hitting them because it never initiated one. We know that the culprit here is the CSS who spoofed their IP address. We do not want this to happen. We need to force it to go through the CSS otherwise concept of load balancing would be lost here as you successfully bypassed the CSS from the picture. When an incoming traffic is meant for a service, NAT the source IP address to show that it is coming from the CSS. This way, the reply-traffic goes back to the CSS through the switch instead of bypassing it.

Make sure that each of your server is configured with the default-gateway being the IP address of the upstream gateway router and NOT the circuit VLAN1 of CSS which is 192.168.1.21 in your case. This is done because if you have server initiated traffic, the server initiated traffic does not have to go through the CSS and goes through the gateway router.

!************************** CIRCUIT **************************

circuit VLAN1

redundancy

ip address 192.168.1.21 255.255.255.0

no redirects

!************************** SERVICE **************************

service app1

ip address 192.168.1.10

string cookieapp1

active

service app1-out

ip address 192.168.1.10

active

service app2

string cookieapp2

ip address 192.168.1.12

active

service app2-out

ip address 192.168.1.12

active

!*************************** OWNER ***************************

owner myapp

content webapp

vip address 192.168.1.4

arrowpoint-cookie expiration 00:03:00:00

balance aca

protocol tcp

port 80

url "/*"

advanced-balance sticky-srcip-dstport

add service app1

add service app2

active

!*************************** GROUP ***************************

group servers

vip address 192.168.1.4

add destination service app1-out

add destination service app2-out

active

skumar1969 · ‎03-25-2005

Hi,

If you do NOT want the server-initiated-traffic to go straight and need it through the CSS so that you can stop the server communication with the clients, we got an option to do this. Try the following config, can't gurantee if this will work. I have given the source group config alone.

You need to have additional VIP for the outgoing traffic as there is a limitation that CSS permits you to assign the same VIP address to multiple source groups, but only one of the source groups can be active at any point of time.

Make sure that each of your server is configured with the default-gateway being the IP address of the circuit VLAN1 of CSS which is 192.168.1.21 in your case. This is done because if you have server initiated traffic, the server initiated traffic does have to go through the CSS.

!*************************** GROUP ***************************

group servers-in

vip address 192.168.1.4

add destination service app1

add destination service app2

active

group servers-out

vip address 192.168.1.5 ------>New VIP for outgoing.

add service app1-out

add service app2-out

active

!

thanks

skumar1969 · ‎03-26-2005

I just referred Cisco pages. The above config group servers-out will work only when the source group is active and the same service is hit through a content rule, ACL preferred service, or sorry service, then only the source group is used to NAT (Network Address Translation) the source address.

thanks

Gilles Dufour · ‎03-26-2005

As indicated in my previous answer, if you have one-armed and need client-nat you need 'add service DESTINATION '.

Inside the group, the vip can be any ip address not being used in your network currently or a vip address used by this CSS.[not the circuit vlan ip address].

This must work or you have a different issue.

If your server is using redirect, it may redirect the traffic to its own ip.

Another possibility is absolute url like http://192.168.1.10/.../... contain in some of your webpages.

Capture a sniffer trace on the client to see when it switches to a real.

Gilles.

skumar1969 · ‎03-26-2005

Gilles,

the config I porposed do you thing it would work. I came out with 2 different source groups. Theoratically it is okay to me but need to get an expert's evaluation like you....just out of curiosity...

thanks