ACLs don’t have a built-in mechanism to keep track of UDP return traffic. The established keyword is used only for TCP, as the ACL actually checks the flags within the TCP header. Specifically, the ACK and the RST flags are checked. If either of those is set to 1, then the segment is confirmed to be part of an established session.
Because UDP doesn’t have any information in its header that can be used for this purpose, there is no counterpart to the established keyword for UDP. So if you’re only using ACLs, you can use Reflexive ACLs to account for UDP return traffic. However, as you correctly state, if you want a more complete and secure solution, you would move to other more advanced options rather than ACLs.
So to answer your question, beyond reflexive ACLs, there is no other ACL solution for UDP traffic…
This is an excellent question! The reasoning behind this behavior has to do with how a router sees transient traffic and locally generated traffic. The distinction between these two types of traffic aligns almost completely with the distinction between data plane and control plane traffic.
From a router’s perspective, locally generated traffic is virtually always control plane traffic, while the transient traffic it serves can only be considered data plane traffic. By design, ACLs applied on interfaces act only on transient (i.e. data plane) traffic. Locally generated (i.e. control plane) traffic is not acted upon because that means that every time you create a ACL, you will need to provision for exceptions in the ACL for OSPF, EIGRP, and BGP message exchanges, as well as other protocols, including SNMP, Syslog, NTP, TFTP, DNS, HSRP, DHCP relay, and many others.
So you see, it would be a nightmare to ensure that all of these control plane protocols would not be blocked if outbound ACLs also blocked locally generated traffic. As you can see, by design, it is also a convenience.
If you set the protocol to tcp as in your example, you can optionally specify the port number of the source and/or destination that you want to match. In this particular case, this statement matches:
The TCP protocol
The source IP address of 192.168.1.1
a source TCP port of 25
A destination IP address of 10.0.0.1
Since no destination port is specified, it matches all destination ports. So in this particular case, the eq 25 is applied to the source. Port 25 for TCP is used by SMTP which is an email protocol.
Practically speaking, if a packet is sent from 192.168.1.1 to 10.0.0.1 and encapsulates a TCP segment with a source port of 25, this access list will match that packet. And it will permit it, since that’s the statement at the beginning.
Filtering using TCP ports is very useful because you can isolate specific applications that you may want to allow or deny. For example, you can place an access list on the outbound interface of your edge router that only allows destination ports of either 80 or 443. That way, only web traffic will be allowed, and all other traffic will be denied.
So, using ports to filter traffic aids in filtering specific types of traffic used by particular applications. Just a note, however, that this is not a foolproof way to filter traffic. It is relatively simple to modify the ports being used by applications to bypass any such restrictions, but filtering TCP ports is still a powerful way to employ security and traffic management in any network.
For more information about the syntax of extended access lists for use with various protocols (TCP and others), take a look at this Cisco documentation: