mailing list archives
Re: Firewalls in service provider environments
From: Matt Buford <matt () overloaded net>
Date: Tue, 7 Feb 2012 16:59:35 -0600
On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt () 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
Re: Firewalls in service provider environments Christopher Morrow (Feb 07)