[c-nsp] FWSM access permissions confusion between interfaces

[Jeff Kell]

Greetings.  I have an unusual (perhaps) FWSM application that is not
quite working out as expected, and after several variations from
different angles, still not producing quite the desired result.

I have a 6509 doing VRFs for different campus communities, and since
many of our services / applications are shared, have separate VRFs for
groups of end-users as well as groups of applications /servers.

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.

To try to simplify the setup, here are three user groups and three
service groups, along with a "common" body of services shared by all:

   red -- vlan100        vlan700 -- orange
yellow -- vlan200        vlan800 -- green
  blue -- vlan300        vlan900 -- purple

              white -- vlan1000

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