cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
795
Views
0
Helpful
4
Replies

Extended ACL TCP port control

frenzeus
Level 4
Level 4

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.

4 Replies 4

dgahm
Level 8
Level 8

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.

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.

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: