Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following: permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail. I had always thought that these ACLs were processed in order, so that the explicit permit statement, though limited to a specific protocol but for all hosts, gets considered before the explicit deny statement for all IP to a particular host. What did I forget to consider? TIA,
On Thu, Apr 21, 2011 at 3:13 PM, <up@3.am> wrote:
Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following:
permit tcp any eq 443 any
Don't you want: permit tcp any any eq 443 Since you want the incoming traffic to have 443 as the destination port, not the source?
permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any
This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail.
I had always thought that these ACLs were processed in order, so that the explicit permit statement, though limited to a specific protocol but for all hosts, gets considered before the explicit deny statement for all IP to a particular host. What did I forget to consider?
TIA,
On Thu, 21 Apr 2011, up@3.am wrote:
permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any
This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail.
Your ACL is apply the 80 & 443 as source ports, not destination ports. You probably want: permit tcp any any eq 443 permit tcp any any eq 80 deny ip any host 2.2.3.4 permit ip any any ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
Thanks everyone, of course this is what I wanted. Like I said, a stupid ACL question...I'm blaming heavy medication, sorry for the noise!
On Thu, 21 Apr 2011, up@3.am wrote:
permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any
This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail.
Your ACL is apply the 80 & 443 as source ports, not destination ports.
You probably want: permit tcp any any eq 443 permit tcp any any eq 80 deny ip any host 2.2.3.4 permit ip any any
________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
If this is applied inbound from the Internet, then the first two permits are permitting reply traffic from the far-end Web server's ports 80 or 443 back toward your surfing workstations or servers. You should think of those as permit - just TCP -- where the SOURCE is any IP address, but source PORT of 80 -- and where the DESTINATION is any IP, any port This is more applicable as a "poor man's firewall" where you're trying to permit inside workstations to get to certain services on the outside, and permit return traffic, but not have anyone outside reach services inside. But without a real stateful firewall it doesn't work too well. Probably what you want is for the outside public to be able to reach just ports 80 and 443 on host 2.2.3.4, but no other services on that host, and other than those special cases, to be unrestricted through this interface. In that case, as Dorn Hetzel just chimed in, you probably want (spaced out to be clearer than the syntax naturally prints out) permit tcp any host 2.2.3.4 eq 80 permit tcp any host 2.2.3.4 eq 443 deny ip any host 2.2.3.4 permit ip any any -- Jeff Saxe ________________________________________ From: up@3.am [up@3.am] Sent: Thursday, April 21, 2011 3:13 PM To: nanog@nanog.org Subject: Stupid Cisco ACL question Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following: permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail. I had always thought that these ACLs were processed in order, so that the explicit permit statement, though limited to a specific protocol but for all hosts, gets considered before the explicit deny statement for all IP to a particular host. What did I forget to consider? TIA,
On Thu, Apr 21, 2011 at 3:13 PM, <up@3.am> wrote:
Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following:
permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any
This is applied to an inbound interface(s).
Many many problems with this ACL. 1. In the inbound (from the Internet) interface you want the destination port, not the source port. I.e. permit tcp any any eq 443. The above would only make sense if your web server was 2.2.3.4 and the ACL was applied to outbound traffic entering the interior router interface (facing the web server). That's a back-assward way to do things since you probably want to limit packets from reaching the web server, not limit the web server's packets from exiting. 2. TCP packets go both ways and the ones you initiate tend to do so on random ports. Implication: the destination port on this packet is the source port on the reply. Your probably meant to block only the connection establishment packet. I.e. permit tcp any any eq 443; permit tcp any any established 3. ICMP destination unreachable messages are MANDATORY for TCP PMTUD function. You didn't disable PMTUD on your server (it's on by default) and we'd beat you up if you did. Your ACL breaks the protocol by blocking those ICMP messages. Add "permit icmp any any unreachable" prior to "deny ip any host 2.2.3.4" 4. Several other ICMP messages help you and your customers figure out what's wrong when things don't work. This includes echo-request and echo-reply. Strongly advise you to enable them. 5. Is your DNS resolver inside your network? If not, you'll need to enable UDP *and* TCP packets to and from the DNS resolver. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (5)
-
Dorn Hetzel
-
Jay Ford
-
Jeff Saxe
-
up@3.am
-
William Herrin