CSS outbound NAT

[mbell]

I've seen several posts in this forum relating to outbound (source) NAT'ing on a CSS but am still confused as to what I need to accomplish this. I've got four servers behind a CSS that need to be PAT'd to a single public address for outbound access. I've read through this page:

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_tech_note09186a0080093dfc.shtml

but still have some questions since this page does not discuss topology. First, which circuit should the "apply circuit-" command be used for? Is that for the public side or private side? Second, is this all the configuration I need to enable outbound NAT? Third, what (if any) impact does this have on the inbound configuration for these servers?

If anybody has a config showing how to do this, that would be great!

[Gilles Dufour]

I guess this one would be more explicit

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a008009470e.shtml

Gilles.

[mbell]

That is a very helpful link. Out of the 20 or so hosts on the inside segment, I only want to NAT four of them to a public IP address. To prevent NAT'ing the other hosts, would I use something like:

clause 5 permit any 192.168.1.10 255.255.255.255 destination any sourcegroup outbound

clause 10 bypass any 192.168.1.0 255.255.255.0 destination any

The thing I'm confused about is that in the original link I saw, the ACL had permit statements for internal networks _to_ the internal networks, i.e. permit any 192.168.1.0 255.255.255.0 destination 192.168.1.0 255.255.255.0.

What is the purpose of these statements and why would they not be shown in the second link?

Also, I'm assuming that if I only want to NAT outbound traffic and not permit inbound connections, I don't have to apply a "permit any any" ACL to the outside interface, correct?

[Gilles Dufour]

we often nat when a server itself open a connection with a vip. This is because the CSS will forward the request to a server [could even be the same one that opened the connection] that resides in the same subnet as the source and to guarantee that the response goes back to the CSS client is necessary.

In your case, you want to nat outbound traffic.

So simply make an acl that matches your source/destination and you should be ok.

Gilles.

[mbell]

So if I want to NAT these four servers to the Internet but not the other servers behind the CSS, then what entries in the ACL do I need for the servers that I do not want to NAT? Would I use "deny" or "bypass"? I thought CSS ACLs have implicit "denies" like IOS ACLs and I need something to allow the other traffic through.

I'm assuming I'll need four ACL entries that permit traffic from the four hosts I want to NAT to the source-group plus some other entries that allow non-NAT'd traffic to "any". I'm just trying to figure out what the entries should look like for the inside hosts that will not be NAT'd.

[Gilles Dufour]

you need a permit for the rest of the traffic if you simply want the traffic to be processed by the CSS. A Deny if you want to drop it or a bypass if you want the css to only route the traffic [no match possible on any content rule].

so you should end up with something like this.

acl 1

clause 10 permit any X destination Y sourcegroup Z

...

clause 99 permit any any destination any

apply all

Gilles.

[frankamankwah]

clause 5 permit any 192.168.1.10 255.255.255.255 destination any sourcegroup outbound

clause 10 bypass any 192.168.1.0 255.255.255.0 destination any

The above would definitely fix your issue as stated earlier by a contributor. You would need to bypass the content rules

[mbell]

Once again, great information. Something else that I just want to double-check... If I already have these four servers configured to provide inbound services _from_ the Internet, i.e.:

content manager

add service manager5

add service manager6

protocol tcp

port 8080

add service manager3

add service manager4

advanced-balance arrowpoint-cookie

vip address 60.1.1.1

active

will the new outbound NAT configuration have any impact on the inbound services and the replies for those services? In the link you provided originally, I found "The CSS 11000/11500 does not apply ACLs to response traffic because you already have a flow established." so I am assuming that this new ACL/NAT configuration would not have any impact on the services or content rules that are already configured for these hosts, correct?

[Gilles Dufour · Accepted solution]

you are correct, the ACL will only apply to new connections opened from the servers.

This could have an impact on UDP connection, if you have udp content rules.

Gilles.