Firewalls in service provider environments

[matt at mattreath.com (Matthew Reath)]

> 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.
>

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