You have certainly come to the right place. Could you describe in more detail what you are trying to do and your topology? I know the thought of, "why can't you just answer my question???"
VLANs are a layer-2 construct and thus are not directional in nature. Additionally, VLANs are not truly intended for security in the same sense as that of a firewall zone. Sure, you can create two or more VLANs, and by virtue of doing this alone you have certainly divided the switch up logically into different broadcast domains, MAC address forwarding tables, and per-vlan-spanning-tree instances; essentially, you have made multiple logical switches. You can surely divvy up and carve the physical switch interface however you like etc. - great, but...
As you have stated, you are running Router code, so we know you also have a virtual router inside making this a multi-layer device. Simply put you assign each VLAN a software-virtual-interface (SVI) by using a statement like "router-interface ve 123" under the VLAN configuration. From here you assign the IP addresses and masks to these SVIs (VEs) and by virtue of doing this, you ultimately, automatically create directly-connected routes on the router with the next-hop for that subset being its associated VE.
At any rate, the frames and broadcasts will stay contained within the VLAN, but anything destined to the VE (as its default-gateway) will hit the routing process, where all the Layer-2 information will be stripped and the packet(s) routed. Ultimately, they get shoved into new Layer-2 frames within the next-hop VLAN, so there is no real security.
Right now, from this reading above, I have a mental image of three (3) VLANS. One is a WAN VLAN (or similar), which presumably contains one physical interface and has an assigned /30 on its VE. This one either connects to a provider or perhaps an Internet-connected firewall... because surely you are not connecting a multi-layer switch directly to the Internet...
Then I mentally picture two other VLANs... One of these two can get to the outside world or resources within the other, and the the final VLAN can presumably get nowhere except within itself (otherwise it would be useless)
If this is correct, you would not want to use a VRF (separate routing table) because the isolation would prevent you getting into the one isolated vlan.
I doubt you are interested in mapping community to primary VLANs as this is typically deployed only with isolated VLANS. Might be a good read though: http://docs.ruckuswireless.com/fastiron/08.0.60/fastiron-08060-l2guide/GUID-6A7FE111-9F4A-4AC6-957F-...
Personally, I would probably deal with security with a firewall connected to your switch and put the items into separate zones, but I see no reason why a rudimentary Layer-3 access-list would not suffice for basic security.
Honestly, I think you may merely be having problems with your access lists.
You would apply them to the layer-3 interfaces (the VEs), which presumably you got or it wouldn't have dropped your traffic.
If you could include your configuration, it may help.
At any rate, you need to determine where you are going to place your controls. If you want to block connections out, that screams of an extended access-list with the source being the same subset as your SVI and the destination being whatever you don't want it to get to.
I recognize the problem is that you create an extended ACL to block the traffic going out. Then traffic is allowed in, but a reply is dropped not making it back out.
You will probably need to refine your access lists a bit more using a TCP list and the established
key word, which matches everything but the first packet. The first packet goes from a client to a server to initiate the conversation and doesn't have the ACK bit set.
Basically, this would allow a TCP three-way hand-shake to take place. It is certainly not spoof-proof, but it would allow someone from the outside to initiate a session in while you could still have a line under it to drop IP traffic going out.
Hope that helps.
Not certain if the Brocade does it, but you may want to read into Reflexive Access-Lists, too.