12-26-2005 09:03 PM - edited 03-03-2019 01:14 AM
Hi all,
I have configured an acl to control traffic going in/out of an interface via tcp ports. However, after applying the acl to the interface, i find that eventhough ports are allowed, traffic is blocked by the acl.
I suspected that it could be the initial tcp handshake (SYN, SYNACK, ACK etc) is not being allowed (due to the implicit deny). When i included that in the acl, it worked. Is this a necessary step in an acl that controls by tcp port?
Reason is, some of the acl configured with tcp port control has not been configured to allow SYN, ACK etc but it works when some of these ACLs are applied to other interface.
12-27-2005 04:16 PM
The ACL will treat a handshake packet the same as any other TCP packet if you just use the port. You might have your well known port on the wrong side of the statement. That is the one of the most common places people run into trouble. The other is in vs out when applying the list.
In this example the source port is 80, so this would match http packets from server 1.1.1.1 to client 2.2.2.2, including SYN ACKs, or ACKs.
access-list 101 permit tcp host 1.1.1.1 eq 80 host 2.2.2.2
This would match http packets from the client to the server, including SYNs.
access-list 102 permit tcp host 2.2.2.2 host 1.1.1.1 eq 80
If applied to an ethernet interface on the server subnet you want ip access-group 101 in and ip access-group 102 out
If this doesn't help perhaps you could post your config. Using an explicit deny ip any any log as the last line in your list will help in troubleshooting. All denied packets will then be logged.
12-27-2005 06:26 PM
Hi,
Thanks for the response. As far as the config of the ACL, it's quite straight forward with the thing i'm trying to achieve. 1.1.1.190 & 1.1.1.192 are Mail servers. The objective is to control both .190 & .192. The config is as below:
!
interface Vlan2
description For Mail
ip address 1.1.1.129 255.255.255.0
ip access-group 2002 in
end
C6500#sh access-li 2002
Extended IP access list 2002
10 permit icmp any any (272 matches)
20 permit tcp host 1.1.1.0 any syn (10467 matches)
30 permit tcp host 1.1.1.0 any ack (781 matches)
40 permit tcp host 1.1.1.190 eq smtp any
50 permit tcp host 1.1.1.190 eq pop3 any
60 permit tcp host 1.1.1.192 eq smtp any
70 permit tcp host 1.1.1.192 eq pop3 any (4 matches)
80 permit ip host 1.1.1.183 2.2.0.0 0.0.255.255 (19 matches)
When I first created this ACL, without the SYN & ACK configured, users failed to connect to the servers. I personally believe users could connect, but it's the return packets from the servers that might have gotten blocked by the ACL. However, after I added in the SYN & ACK, all went well. I could see counters incrementing for the SYN & ACK as well.
Whereas, some other applications that use some custom ports, ie. 10000, 10001, didn't seem to need the explicit configuration of the SYN/ACKs & the ACL worked well.
12-27-2005 08:08 PM
Could it be that .190 and .192 are initiating the SMTP connections to another mail server, and are therefore the client rather than the server?
Logging denies would let you see if this is the case.
Try adding:
permit tcp host 1.1.1.190 any eq smtp
With your list you are allowing any TCP port.
12-27-2005 10:17 PM
Thanks again for getting back so soon.
Those are the only 2 mail servers. But i guess i could try to configure a deny any any log to see what gets denied.
The weirdest part is once i've put in the SYN/ACK, it's working. Thanks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide