So, you have two sets of interfaces, "inside" and "outside".  And you
have two sets of daemons, some which should listen only on "inside"
interfaces and some which should only on "outside" interfaces.  (And
maybe a third set, which should listen to all interfaces.)  And maybe
you even have one daemon where you need to run two separate instances,
one on each set of interfaces.  (Named comes to mind here.)

How would restricting INADDR_ANY provide the required segregation of
interfaces into two groups, except in the simple case where one group
(probably "outside") has only one member?

On Wed, 2 Jan 2002, Jim Wise wrote:

> Let me provide a clear example of a situation where I would like to have
> this capability, BTW:
>
> For a number of shops, I have set up NAT routers with one or more
> outside interfaces, and one or more inside interfaces.  In a small
> office situation, such a system will want to have named, sshd, and
> sendmail listening on the outside interface(s), and a wider range of
> services listening on the inside interface(s) (lpd, samba,
> netatalk-over-ip, nfs, to pick some examples).  Many of these services
> _cannot_ be configured to listen on anything but INADDR_ANY, even if
> they can be configured not to authorize connections on certain
> interfaces.
>
> To date, ipf is the only available solution for this, and as mentioned,
> configuring ipf to block all services invisibly on the outside
> interface(s) is both error-prone and subject to both race conditions and
> user error.
>
> I would _like_ to be able to mark the external interface(s) as excluded
> from INADDR_ANY, allowing INADDR_ANY to be used normally over the set of
> internal interfaces...
>
> On Wed, 2 Jan 2002, Paul Goyette wrote:
>
> >Then, what would you do if you _did_ want some daemons to listen on
> >all interfaces, but had other daemons which should listen only on a
> >subset?
> >
> >Perhaps INADDR_MOST_BUT_NOT_ALL would be useful here?   :)
> >
> >On Wed, 2 Jan 2002, Jim Wise wrote:
> >
> >> Please note:  this is *not* a strong-vs-weak host model post.  I
> >> strongly believe a sysctl to choose strong or weak host model is in
> >> order, but this is a separate question, specifically:
> >>
> >> What do people think of the idea of adding a per-interface flag,
> >> settable with ifconfig, to indicate that an interface should not be
> >> included in INADDR_ANY?
> >>
> >> Such a flag would be especially useful in a strong host model of course,
> >> but even in the current model, there are many instances of hosts which
> >> have one or more interfaces on which it is not desirable to have daemons
> >> listening (think a management-lan interface, or the outside interface
> >> of a NAT or proxy gateway).
> >>
> >> As many daemons, (in particular all current RPC services) provide no way
> >> to limit the daemon to listening on a particular subset of interfaces on
> >> the system, it seems to me valuable to have the ability to indicate that
> >> an interface is _not_ intended to be listened on by general services.
> >>
> >> (And yes, of course this can be done with ipf, but let's face it, having
> >> a daemon actually listening on the undesired port and then blocking
> >> access with ipf in a way designed not to be picked up by port scanners
> >> is error-prone at best, and worse, subject to race conditions, such as
> >> connections in the brief interval between ipf stopping and starting when
> >> invoking /etc/rc.d/ipfilter reload).
> >>
> >> --
> >> 				Jim Wise
> >> 				jwise@draga.comSignature by unknown keyid: 0xC398730E
> >>
> >
> >----------------------------------------------------------------------
> >|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
> >| Network Engineer | BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com   |
> >|  & World Cruiser | 91EB ADB1 A280 3B79 9221 | pgoyette@juniper.net |
> >----------------------------------------------------------------------
> >
>
> --
> 				Jim Wise
> 				jwise@draga.comSignature by unknown keyid: 0xC398730E
>

----------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
| Network Engineer | BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com   |
|  & World Cruiser | 91EB ADB1 A280 3B79 9221 | pgoyette@juniper.net |
----------------------------------------------------------------------