> On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <m...@mattreath.com> wrote: > >> > One of my customers has a list like that. They can't understand why >> > one in every hundred or so TCP connections on port 443 fails. >> > >> > Hint: you forgot "access-list 102 permit tcp any any established" >> > after "access-list 102 deny ip host 255.255.255.255 any". The >> > destination port in one direction is the source port in the other and >> > many of those are dynamic source ports picked by Windows. Unless you >> > restrict that filter to just packets attempting to initiate a new >> > connection, you're shooting yourself in the foot. >> >> Yeah agreed. The only place this gets applied is inbound on the >> interface >> facing an upstream provider. ACLs ingress from end customers are much >> different. In theory this could cause issues with externally initiated >> traffic that use lets say 8888 as its random source port. >> > > If you apply the ACL you showed as an inbound ACL on your provider facing > interfaces, you will be breaking any connections that exit your network > with source ports from your list of bad ports. For example, you connect > out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back > into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be > dropped by your ACL. > > This seems to be a common mistake, and is often missed because it > manifests > as one-in-thousands failures of TCP connections. People tend to just try > a > second time and it works and never investigate why they had one random > failure. >
Good point. Adding in an established entry, although may open you up for TCP/SYN sort of packets is a better trade off than affecting customer traffic. -Matt
