Firewalls in service provider environments

Tue Feb 7 22:59:35 UTC 2012

On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt at 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.