ACE and NAT

Unanswered Question
Nov 5th, 2007

I'm a newbie to configuring an ACE module so bear with me.

I'm trying to create a VIP that answers to port 80 that NAT's and loadshares that to a serverfarm on port 7778.

My relevant config statements:

probe http v01_http_probe

port 7778

interval 30

passdetect interval 10

request method head url /index.html

expect status 200 202

rserver host hcpappl01

ip address 10.144.20.175

inservice

rserver host hcpappl02

ip address 10.144.20.176

inservice

serverfarm host hcpappv01

probe v01_http_probe

rserver hcpappl01 7778

inservice

rserver hcpappl02 7778

inservice

class-map match-all v01_vip_http

2 match virtual-address 10.148.1.77 tcp eq www

policy-map type loadbalance first-match v01_policy

class class-default

serverfarm hcpappv01

policy-map multi-match v01_http_policy

class v01_vip_http

loadbalance vip inservice

loadbalance policy v01_policy

loadbalance vip icmp-reply active

loadbalance vip advertise active

interface vlan 116

description SERVER SIDE

ip address 10.144.16.6 255.255.240.0

service-policy input everyone

no shutdown

interface vlan 148

description CLIENT SIDE

ip address 10.148.1.10 255.255.255.0

service-policy input v01_http_policy

no shutdown

ip route 0.0.0.0 0.0.0.0 10.144.16.1

ip route 0.0.0.0 0.0.0.0 10.148.1.1

All appears to work, except it doesn't.. when I do a show connections I can see the problem as follows:

switch/Admin# sh conn

total current connections : 4

conn-id np dir proto vlan source destination state

----------+--+---+-----+----+---------------------+---------------------+------+

2 2 in TCP 148 10.148.1.100:1710 10.148.1.77:80 SYNSEEN

8 2 out TCP 116 10.144.20.175:7778 10.148.1.100:1036 INIT

Which shows the "return" connection from the real server as coming back from the realserver's address, not the NAT'd address.

The forward connection goes from my machine, 10.148.1.100, to the VIP 10.148.1.77 port 80. Correctly gets translated into 10.144.20.175:7778 and sent on to the server. However, when the server replies, it doesn't get translated back to 10.148.1.77:80

Obviously it's doing destination NAT, but not source NAT. Any idea as to how I have to make it do the source side as well?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
cajalat Mon, 11/05/2007 - 16:06

You have 2 default routes which the first one listed will take precedence. I think you need to remove the first default route and that will fix your problem. Your config looks correct and will do 1/2 NAT where the server will see the real IP of the client but the client will only see the responses from the VIP.

Casey

cajalat Mon, 11/05/2007 - 16:12

Actually looking at this further I see that the servers are not in the same subnet as the server net interface. So you'll need to add a route to reach the servers through the server net. Your response from the servers needs to go through the load balancer so you need to ensure that happens.

gbowling1 Tue, 11/06/2007 - 05:20

Well, I got it working. I'm not sure it's the optimum design, but it works..

The two default routes looks weird to me as well, but that's the way the book says to do it. In this case, either of those routes will work, so it's not a problem. I'm not worried about the routes right now.

What I needed to do was to do a source NAT so that the return packets worked correctly. I solved that by adding the following to the config.. It's hard for me to get my head around how this box works, the commands are not very intuitive.

At any rate, I created a class map that matches everything. A policy map that creates a dynamic NAT for that class. A nat-pool with pat for the server side interface. And assigned the service policy to the client interface..

It all works, but as I said maybe there is an easier way to do this.

Could they make a simple NAT arrangement seem more complicated and confusing if they tried??????

class-map match-all nat

2 match source-address 0.0.0.0 0.0.0.0

policy-map multi-match nat

class nat

nat dynamic 1 vlan 116

interface vlan 116

description SERVER SIDE

ip address 10.144.16.6 255.255.240.0

nat-pool 1 10.144.16.8 10.144.16.8 netmask 255.255.255.255 pat

service-policy input everyone

no shutdown

interface vlan 148

description CLIENT SIDE

ip address 10.148.1.10 255.255.255.0

service-policy input v01_http_policy

service-policy input v01_https_policy

service-policy input nat

no shutdown

cajalat Tue, 11/06/2007 - 07:12

Too funny. I had the same thoughts when I first started with the ACE. Now I'm getting the hang of it and realize the benefits of what seems convoluted.

Your config will work. The only recommendation I would make is to match on destinations to the VIP only.

It sounds like in your case your ACE is in the middle of your network. In this case I would recommend that you add specific routes to your server nets via the server interface vs. adding a 2nd default route. Normally server networks are literally behind the ACE/LoadBalancer where the LB is the default gateway for the server. Yours will work but it is more complex and requires ensuring symmetric paths in/out of your ACE. Otherwise you'll need to apply your service-policy to all of your interfaces depending on which way the traffic enters.

Good luck.

blade_ace Tue, 11/06/2007 - 09:24

The manuals suck. Almost all the examples in the Security Guide in the NAT section have errors. I muddled through getting NAT to work last night so here is what it doesn't tell you in the NAT guide that you might run into an issue with. I had a default gateway pointing to my msfc management VLAN and a client side vlan that I wanted to NAT on. Do a "sh conn" and make sure that the IN vlan is 116 and the OUT vlan is 148. In my case my default route was sending the packet to the msfc on the management vlan and not natting the packet. As soon as I change the management route to a more specific route and changed my default route to the outside msfc interface, the packet was getting properly natted on the outside vlan. Also, I notice that after change the router and the NAT settings and saving the settings, they didn't actually seem to take for 30-60 seconds.

Actions

This Discussion