Solved: Source NAT for specific servers in a rule

pfillips11 · ‎11-16-2009

Hello,

I am trying to achieve source NATing on the CSS and want to confirm if below configuration is good.

VIP address: 61.61.61.61

Services: 10.1.1.1, 10.1.1.2, 20.1.1.1 and 20.1.1.2

Front-end circuit IP: 61.61.61.1 (Same subnet as 61.61.61.61)

Back-end circuit: 10.1.1.10 (Same subnet as 10.1.1.1 or .2)

service AAAA

ip address 10.1.1.1

active

service BBBB

ip address 10.1.1.2

active

service XXXX

ip address 20.1.1.1

active

service YYYY

ip address 20.1.1.2

active

owner Gateway

content Gateway1

vip address 61.61.61.61

add service 10.1.1.1

add service 10.1.1.2

add service 20.1.1.2

add service 20.1.1.1

active

As the two servers 20.1.1.1 and 20.1.1.2 are not in the same subnet, we configured the below to source NAT specifically to these two servers.

group Gateway

vip address 61.61.61.61

add destination service 20.1.1.1

add destination service 20.1.1.2

active

In the past this configuration didn't work. We are going to try it again. Is there anything missing and what else should we check to get it to work.

Appreciate any help.

busterswt · ‎12-02-2009

Using 'add destination service' in the group rule NATs the original client IP as the VIP (in your case), and ensures that return traffic from the remote 20.x.x.x servers flows back to the CSS and then to the client instead of directly to the client (which would reject the traffic). There's no need to worry about any kind of load balancing loop being created. The downside to implementing this is that your servers will see all traffic as originating from the VIP and not the unique client IPs, and since the CSS doesn't support the x-forwarded-for header you're kinda stuck with that side effect.

Also, it's my understanding that the group rule must match the content rule in terms of VIP address and services within it to be effective. You would need to change your group rule to the following for it to work:

FROM:

group Gateway

vip address 61.61.61.61

add destination service 20.1.1.1

add destination service 20.1.1.2

active

TO:

group Gateway

vip address 61.61.61.61

add destination service 10.1.1.1

add destination service 10.1.1.2

add destination service 20.1.1.1

add destination service 20.1.1.2

active

Good luck!

James

View solution in original post

pfillips11 · ‎11-16-2009

I forgot to mention that route on 20.x.x.x servers is set to point back to CSS.

Now I understand that CSS uses translates the source IP of client to VIP address. If that is correct then is it that 20.x.x.x servers sends the return traffic to CSS VIP, which inturn gets load balanced and go into a loop??

Thank you.

busterswt · ‎12-02-2009

Using 'add destination service' in the group rule NATs the original client IP as the VIP (in your case), and ensures that return traffic from the remote 20.x.x.x servers flows back to the CSS and then to the client instead of directly to the client (which would reject the traffic). There's no need to worry about any kind of load balancing loop being created. The downside to implementing this is that your servers will see all traffic as originating from the VIP and not the unique client IPs, and since the CSS doesn't support the x-forwarded-for header you're kinda stuck with that side effect.

Also, it's my understanding that the group rule must match the content rule in terms of VIP address and services within it to be effective. You would need to change your group rule to the following for it to work:

FROM:

group Gateway

vip address 61.61.61.61

add destination service 20.1.1.1

add destination service 20.1.1.2

active

TO:

group Gateway

vip address 61.61.61.61

add destination service 10.1.1.1

add destination service 10.1.1.2

add destination service 20.1.1.1

add destination service 20.1.1.2

active

Good luck!

James

pfillips11 · ‎12-04-2009

Thank you. The solution has been implemented and it works as good.

Note: Under source NAT group its not necessary to have the NATed IP same as that of VIP.