Re: bind() udp behavior 2.6.8.1

[Willy Tarreau <willy@w.ods.org>]

Hi,

On Tue, Dec 14, 2004 at 12:38:02PM -0500, Adam Denenberg wrote:
 
> My issue is that linux is not randomizing or incrementing the ports it
> uses for udp connections to prevent this sort of issue since udp is
> connectionless.  We dont have sequence numbers or the sorts like TCP to
> sort this out, we only have source ip and port.

Most UDP services use the server socket to access remote servers. For
example, bind will only use its source port 53 to emit requests, ntpd
will only use source port 123, this *is* how they have been working for
ages. PIX is totally buggy and does not respect standards, it respects
what seems to be "common practices" (remember TCP ECN ?). If the
developpers have observed that freebsd wastes lots of source ports for
DNS requests, they will decide that using the same one is probably an
attack. I even remember that it does not support NTP correctly. When
an NTP server on your LAN "connects" to another one outside, it
translates the source port 123 to another source port < 1024, which
most servers and/or firewalls drop (they only let 123 or >=1024 in).

> Other OS's seem  to do this and thus apps are not getting broken when
> connections are made thru the firewall, which is why i originally posted
> the question.

Perhaps the other OS you have seen simply close the socket as soon as they
get their response, and have to create a new one for each new request...
How does any DNS server forward to outside through your PIX ?

> I was hoping that maybe there is some workaround or that
> hopefully someone else encountered this issue.  I am not saying the
> firewall is not totally to blame, but i can see why it is behaving the
> way it is when seeing tons of connections from the same udp ip/port come
> in.

I doubt you can reliably use any UDP-based application through this
firewall then... It seems more buggy than other pixes I have encountered,
and I think you can configure it to be less silly, but I don't know how.
You agree that a session is defined by these 5 numbers :
  - proto (udp, tcp, icmp, ...)
  - source ip, source port
  - destination ip, destination port

If these 5 parameters are the same within a certain time frame, the packet
belongs to a known session. If the combination is different, then it is a
new session, and there is no reason for the firewall to drop a new session
only based on the fact that 3 parameters out of 5 are the same as other ones.
It is as stupid as saying that you refuse to establish a new TCP connection
on some dest:80 because you just did it 30ms ago.

I you want to work around this buggy behaviour without reconfiguring the PIX,
you can also play with iptables on the linux machine to use a random source
port range :
  iptables -t nat -A OUTPUT -p udp --dport 53 -j SNAT --to-source <your ip>:1024-65534

But this is a dirty hack...

Regards,
Willy