that makes a lot more sense now.. the box i'm running nmap from is from a remote location. i am able to telnet into port 1720 and the connection is established (as per netstat -na)
i also added deny tcp any any eq 1720 at the top of the acl but that still didn't help. i'm still able to connect to that port using telnet... i even tried removing the established rule but that didn't change anything as well. --- On Wed, 12/23/09, Steve Bertrand <[email protected]> wrote: From: Steve Bertrand <[email protected]> Subject: Re: [c-nsp] Port 1720 & 1863 To: "abs" <[email protected]> Cc: "Adam Strawson" <[email protected]>, [email protected] Date: Wednesday, December 23, 2009, 2:20 PM abs wrote: > that is what i was thinking as well so i removed that line but that caused > all responses to internal traffic to be blocked. What do you exactly mean by > specific? Wouldn't I have to put a rule for each type of traffic? On an inbound ACL, allowing established TCP sessions means that a TCP connection must be made from the 'internal' side of the interface, and only inbound TCP traffic that is associated with that session can ingress the interface. Your 'deny ip any any' at the end would block ALL inbound TCP, other than SSH and pre-established (by an internal device) sessions. Reviewing your other email (that hasn't hit the list yet), do you happen to have an H.323 session established to your nmap box when you see the port as open? What do you see when you (while on your nmap box): % telnet <ip addr> 1720 % netstat -na | grep 1720 % netstat -na | grep <ip of remote> If you want, provide me with the IP of the box off-list, and I'll scan it from one of my hosts. Steve _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
