[c-nsp] FWSM access permissions confusion between interfaces

Tony Varriale tvarriale at comcast.net
Wed Jul 22 15:18:37 EDT 2009


Have you tried policy static NATs?  Aka if source and destination match ACL 
perform static for specified interfaces.

tv
----- Original Message ----- 
From: "Jeff Kell" <jeff-kell at utc.edu>
To: "cisco-nsp" <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 22, 2009 1:31 PM
Subject: [c-nsp] FWSM access permissions confusion between interfaces


> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 



More information about the cisco-nsp mailing list