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.

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

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.

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.