[unisog] Lifting backbone port 1434/udp blocks

Glenn Forbes Fleming Larratt glratt at rice.edu
Wed Jan 29 01:12:08 GMT 2003

On Tue, 28 Jan 2003, Michael Sinatra wrote:

> On Tue, 28 Jan 2003, Glenn Forbes Fleming Larratt (I) wrote:
> > How does 'forever' grab you?
> How are you dealing with the fact that 1433 and 1434 are unprivileged
> ports?  We've aready seen legitimate DNS traffic blocked by our udp/1434
> filter on the outbound side...

 Point well made, and taken.

> I would guess that you're using the 'established' keyword in a cisco ACL
> or some similar stateful mechanism...

 Er, actually, no.

> Our problem is that we have a lot of asymmetric traffic across our border,
> as we have two sets of border connections.  And I don't see any reasonable
> way that a cisco ACL can deal with the UDP side.  I know IPFILTER can
> maintain "state" on UDP, but that's usually deployed on a much smaller
> scale, with symmetry of traffic.

 Since we're currently using static filters, asymmetry is not
 yet an issue we need to solve per se.

> The udp problem gets ugly with BIND 9, which settles on a source port on
> startup and sticks with that same port for all recursive queries.  I had a
> case where a university was blocking some unprivileged UDP port in both
> directions and one of our entire nameservers couldn't see anything within
> that university and our users complained.  Once I contacted that
> university, they understood the problem and modified the ACL.  But even if
> your ACL is inbound only (as ours is), you can still block legitimate
> traffic (as ours has) and that could create the kinds of intermittent
> problems that drive helpdesks crazy.

 Weird. Good to know about that issue with BIND 9 before we upgrade :)

 The short answer - our results don't match yours, in that the extent of
 problems with an ephemeral port getting blocked has been negligible here,
 with one notable exception that involved a RedHat 2.4 RPM push (or
 something). Maybe we're just lucky - I don't know why.

 The longer answer - stateful firewalling just as soon as we can, or
 sooner, with a design that includes crosstalking fw's or some other
 reasonable solution to the asymmetry problem.


				Glenn Forbes Fleming Larratt
				Rice University Network Management
				glratt at rice.edu

More information about the unisog mailing list