Hello,

I had once tried to use the NAT controls on the interfaces on a PIX and I was dissappointed because things didn't work as expected, but I don't remember the exact details. What I remember is that if you want to be safe, you must put access-list everywhere. So I use now "no nat-control" and try to have correct ACLs in place.

At least now you have the option to use outbound ACLs....

You can create object-groups etc to simplify the ACLs needed.

Regards,
John



On Wed, 22 Jul 2009, Jeff Kell wrote:

I had hoped that using the FWSM NAT controls on the interfaces would
provide the first level of granularity with respect to access controls,
defining "which user VRFs" could see "which server VRFs" without
providing a full head-on mesh of everything together.

All vlans should have access to vlan1000 (inbound)
red and yellow users should have access to orange services.
yellow and blue users should have access to green services.
red and blue users should have access to purple services.

There is no IP address overlap, so there is really no "NAT" required;
but you have to have some definition to allow connections to take place.

If I use "NAT exemption" it seems to let everybody see everyone else,
regardless of the security level assigned to the interface.

This "can" be accomplished by some very complicated ACLs on each
interface, but I would end up with a "long" list of permitted source
networks for each service to permit (and there are many such services
and destination servers).

I would like to restrict access to just the desired subnets (first) with
the appropriate NAT controls, if that is possible, so that the ACLs
would be concerned primarily with just the service/port details.

The documentation implies this is possible (defining NAT rules for
specific source/destination interface pairs) but I can't quite seem to
get the right configuration to work, or properly orient this diagram to
fit the traditional "inside/outside" paradigm the FWSM dialogue expects.

Anyone been there / done that / can offer any suggestions?

Many thanks in advance,

Jeff
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to