> I was wondering how y'all handle UDP servers bound to INADDR_ANY
> on hosts multihomed to the same network. It's completely conceivable
> for reply datagrams to be sent from an address/port not matching
> the client's original destination, thus failing tests in that NAT
> and/or state code.
>
> Assume the following:
> I don't control the servers and can't force them to use a socket
> on each address. (I wouldn't want to waste sockets like that,
> either.) The client program doesn't care about the reply's source
> address and port.
>
> Knowing the service port ahead of time, I could hack IPF, adding a
> "wild" flag, and write a rule specific to this port that'd cause the
> state and NAT code to make use of wildcard flags. Thoughts?
>
> e.g.,
> pass out quick on xl0 proto udp from any to \
> 192.168.0.16/28 port = 1723 keep state keep frags wild_daddr
>
> I don't want to go so far as permitting all traffic from the
> server subnet + port to all of my clients.
>
> Is there an elegant and seemingly obvious solution that I'm
> (prone to) overlooking?
Make sure the servers Do It Right in the first place.
Seriously.
There's a big problem: you'd need to make sure the information
about the set of IP addresses that were to be considered as the
same machine was available to *all* such stateful filters in the
Internet between the client and server(s). Good luck finding
them.
And another: let's suppose (for the sake of argument) that your
client has initiated *two* (or more) such interactions at the
same time; unless the *client* "knows" the information about
the multihomed addresses it, too, can't sort out which set of
returning data is which.
If, on the other hand, you really have two different UDP "flows"
of information where data about the second "flow" is specified
in the data portion of one or more packets in the first "flow",
then that's a job for an IPFilter "proxy" module just like the
FTP proxy (which does a similar thing with TCP port numbers).
--
David Pick
