CSS 11050 NAT problem

[bjones]

Hi, I have a problem with the NAT group intercepting connections to a PIX on the local VLAN. VLAN1 on the LB is the outside internet connection, VLAN2 is internal, at 10.0.10.0/24. The PIX IP is 10.0.10.254. If a webserver at 10.0.10.5 tries to connect to a server behind the PIX, the PIX logs a connection not from 10.0.10.5, but from the NAT group, which has an external IP address. Not only does this slow things down, but confuses the ACL config on the PIX. Any way to force devices to directly connect on the local VLAN, as one would normally expect? Thanks!

[pknoops]

Hi,

On the CSS you have 2 options in using source groups (or NAT).

The first way is to just have the source group and simply add services to it for natting as you are probably doing now.

The other way to do it is to actually use ACLs to apply the NAT given source and destination.

You can have an ACL as basic as this:

acl 2

clause 10 permit any any destination any sourcegroup TEST

apply circuit-(VLAN1)

In this case, any source/dest combo will have source group TEST applied to it. You can get very specific on how you want to apply NAT when using this ACL approach. Maybe this will give you what you want ?

Regards

Pete..

[bjones]

Thanks for the quick response!

Hmm, that seems more granular than I'd like. In essence, I'd like it to look to the local LAN first before being NAT'd, but there are many times when it will need to go out to the internet and be NAT'd. For instance, we do some preliminary stress testing on the local LAN against http/80 which shouldn't hit the Load Balancer at all. Then we might use http/80 to go to the internet and download some patch or new software.

Would applying group TEST to the acl keep it from hitting the internet and only lock it down to using the local LAN, or am I misunderstanding its use?

[pknoops]

What happens is the traffic that will use the group will need to match the source/dest configured in the ACL, but more importantly, the VLAN you apply to the ACL itself will determine what traffic is even looked at in the ACL itself. So if you apply vlan1 to the ACL, then only traffic coming into the CSS via VLAN1 will use the acl (assuming it matches the clause criteria configured).

By using the ACL approach, you could put those ip addresses you want to NAT in the first clauses, and then leave out the ones you do not want to NAT. If there is no ACL match, then there will be no NAT.

Instead of specifying all the ip addreses in separate ACLs, you can use the subnet mask to create a range of addresses.

Hope this help. I do agree that this can be a bit of a maint challenge having to do this, but I'm not sure any other option exists unless there is something different about the way you have your source groups configured.

Regards

Pete..