I found this message below and I'm having the same problem when converting from conduits to access-lists on the PIX. My config is the same: dmz hosts need to access hosts on the inside via a static translation on the dmz. The access-list forced me to use deny specific hosts and permit any any at the end. Now everytime I make changes, I have to create a new access-list with the new inserted commands, shutdown the DMZ interface, and finally apply the new access-list list like routers. With conduits I can dynamically change things without shutting down the interface.
This "improvement" seems more trouble some than conduits and it can't really "replace" conduits function for function in this case. However all Cisco material says this is the way to go and so does their support center.
let me try. It seems you are more comfortable with conduits than ACL, we'll its a choice anyway, that is why uptil now, Cisco has both 'conduits' and 'ACL' support on the newer versions too.
Let me give you some example and comparison.
With conduits, the are flexible in the way you specified, but they open holes on the entire PIX, with ACL they are interface specific i.e. an ACL protects on an interface basis, whereas, conduits open a blanket hole on the box, as you can see, this could cause issues sometimes, and you do not have a better control, with ACL you have a better control on who can access what and from where.
Another thing is that ACL is top down lookup, just like the router, as soon as there is a match; action will be taken, no further lookup. With conduits, they are most specific, it will match the most specific line.
one more thing, if you want to remove an ACL, you do not need to do a 'no' statement for every line in your ACL, just once
no access-list 101 <--- will remove entire ACL 101
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...