Hi Peter, have a meeting to run to, i'll hit your questions in point form, sorry..
- 8.2(2)5 - i am not aware of any ssl licensing issues, i should look into that and see if we are affected. thanks. - i was never one for GUI's, but after 17 years of cli i'm starting to warm up to them.. i'll give it a look, while no one is around. - I have in/out ACLs on most interfaces, including the outside interface. within the outside_in policy there was an ACL: access-list outside_in extended deny tcp any object-group OEB_NETWORK (OEB_NETWORK is the 'new dmz zone' I'm referencing.) on the OEB dmz interface there is another policy applied to traffic leaving the OEB interface into the OEB dmz, into_oeb. I added to this policy: access-list into_oeb permit tcp any object-group OEB_NETWORK eq 80. I expected this to allow traffic to pass. it wasn't until later when I removed the above ACL from the outside_in policy that things started to work. i think that answers your question.(?) Typically I add policy as close to the zone as possible, but because this project was put on hold, I added a "deny-any-to-oeb" within the outside_in policy because at that time the into_oeb policy did not exist nor was defined.. it wasn't until i got the requirements yesterday that I started to define the policy. hosts in this DMZ are not permitted outbound comms, if i (which i did during debugging) permitted it, it would work properly. k gotta run, thanks for your reply, greg On Jan 25, 2011, at 12:14 PM, Max Pierson wrote: Hi Greg, That does look quite strange indeed. As Peter said, it would be much more helpful if you could send what code you're working on. We we're on 8.2.(1 i believe) and never had any issues similar to what you described. Had to move to 8.3 due to the SSL licensing issue, and now on 8.3.2 (still have not had any issues after I fixed Cisco's wonderful mess it made of my tunnels on the config conversion) but that's another story .... I hear ya about having alot of config to look through. Management wanted to do the "pay as we grow" and went with a 5540 to start. We're now on our second .... so you could imagine the amount of config we had (almost 100 or so tunnels and to many to remember DMZ's with hundreds of lines of ACL's). Needless to say, I love the cli, but when you have to scale like that, it's just easier on the eyes (and mind lol) to just use the ASDM. As far as your issue, I see that you mention "initially had deny any any" on the "outside -> DMZ" , then towards the bottom of your post, you say that you removed "outside_in". Do you mean "outside -> said DMZ" was remove at the bottom and all started working?? Or did you remove an ACL in that zone set "outside to inside" and it fixed the issue?? Can the host in this DMZ get packets out and if so, what are you seeing when they attempt to come back in the outside interface?? Max On Tue, Jan 25, 2011 at 10:27 AM, Peter Rathlev <[email protected]<mailto:[email protected]>> wrote: On Tue, 2011-01-25 at 10:48 -0500, Greg Whynott wrote: [...] > capture cap1 access-list capacl1 interface newdmz real-time [...] > I see packets egressing the dmz interface into the dmz zone… In my > mind this is not a firewall issue as the packets are being forwarded > into the zone, as expected. > > the reality is there was a "deny ip any any into newzone" applied to > the outside interface. I should not of seen these packets when > running a capture on the dmz interface, correct? this caused me to > spin my wheels on this for 1/2 a day till I noticed the acl in the > outside_in section… > > soon as I removed the acl element from the outside_in, things > worked.. That does sound strange. Just tried something similar on an ASA 5550 8.2(4) with no problems; the capture shows/doesn't show the expected packets fine. You didn't mention platform and version, which is always a good thing if you want people to test it on something similar. Can you recreate this on another pair of interfaces on the same box, i.e. not towards the "dmz" interface mentioned here? And can you recreate it on the same interface? -- Peter _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ________________________________ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
