This is a discussion on Re: UDP server on multihomed host; client behind packet filter within the IPFilter forums, part of the System Security and Security Related category; > I was wondering how y'all handle UDP servers bound to INADDR_ANY > on hosts multihomed to the same ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
> 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 |
![]() |
| Thread Tools | |
| Display Modes | |
|
|