Home page logo
/

nanog logo nanog mailing list archives

Re: Firewalls in service provider environments
From: "Matthew Reath" <matt () mattreath com>
Date: Wed, 8 Feb 2012 08:25:18 -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
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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]