Routing and bandwidth problem

[Rodolfo J. Paiz]

Hey...

I have no idea of which FM to R here, so I will happily accept pointers to
good documentation and HOWTO documents. Any other help is also welcome, as
I will need to solve this problem very soon. The problem is this:

My small business is one of four tenants in a small building. The other
three have agreed to allow me to buy one big connection and then resell
service to them, such that they get a better price and I get to subsidize
my own Internet service. However, while I *could* set this up quickly
without any controls, they each want different service levels and amounts
of bandwidth and will be paying different prices, so I want to do this
properly.

The firewall/gateway will run Fedora Core 1. I think I need *five* Ethernet
adapters in the server (eth0 to the ISP, and eth1-eth4 to the four tenants)
so that each client is properly isolated into their own network and cannot
access the other clients' computers. If there is a way to do this securely
and safely without a gaggle of Ethernet cards, please do tell! I can think
of doing this with 801.2q VLAN tagging, but that requires a managed switch
which is far more expensive. It seems to me that multiple Ethernet cards
are the simplest *and* cheapest way to do it.

I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP, and
other services. What I don't know how to do is the following:

1. Required: Limit the total bandwidth a client can use to either
128 Kbps or 256 Kbps.

2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all other
offices are gone for the night, or someone who gets lucky that no one else
is using the Net at that particular moment, could get access to the entire
Internet connection (say, 512 Kbps). But if everyone is using the bandwidth
simultaneously, then each would get their fair share (what they paid for
and I provide, proportionately).

3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be ideal
for traffic *to* the server (client connecting to the firewall) to have
full 100 Mbps link speed. This would allow me to download the FC2 ISO
images to the server at night, for example, and then let clients grab them
at 100 Mbps over the internal network instead of having that internal
download also throttled to 256 Kbps.

4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.

Can someone offer some hints, pointers, suggestions, or magic beans?

Thanks in advance!

[Ron Goulard]

Post by Rodolfo J. Paiz
Hey...
I have no idea of which FM to R here, so I will happily accept pointers to
good documentation and HOWTO documents. Any other help is also welcome, as
My small business is one of four tenants in a small building. The other
three have agreed to allow me to buy one big connection and then resell
service to them, such that they get a better price and I get to subsidize
my own Internet service. However, while I *could* set this up quickly
without any controls, they each want different service levels and amounts
of bandwidth and will be paying different prices, so I want to do this
properly.
The firewall/gateway will run Fedora Core 1. I think I need *five* Ethernet
adapters in the server (eth0 to the ISP, and eth1-eth4 to the four tenants)
so that each client is properly isolated into their own network and cannot
access the other clients' computers. If there is a way to do this securely
and safely without a gaggle of Ethernet cards, please do tell! I can think
of doing this with 801.2q VLAN tagging, but that requires a managed switch
which is far more expensive. It seems to me that multiple Ethernet cards
are the simplest *and* cheapest way to do it.
I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP, and
1. Required: Limit the total bandwidth a client can use to either
128 Kbps or 256 Kbps.
2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all other
offices are gone for the night, or someone who gets lucky that no one else
is using the Net at that particular moment, could get access to the entire
Internet connection (say, 512 Kbps). But if everyone is using the bandwidth
simultaneously, then each would get their fair share (what they paid for
and I provide, proportionately).
3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be ideal
for traffic *to* the server (client connecting to the firewall) to have
full 100 Mbps link speed. This would allow me to download the FC2 ISO
images to the server at night, for example, and then let clients grab them
at 100 Mbps over the internal network instead of having that internal
download also throttled to 256 Kbps.
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.
Can someone offer some hints, pointers, suggestions, or magic beans?
Thanks in advance!

Something that I've found in FC1 is cbq, part of the shapecfg package
(and needs iproute I believe). Basically it uses tc to control
traffic. It may help out with much of this without having to grab/find
other software, allowing you to keep it updated with existing fc1
repositories.

I've begun playing with it myself in my spare time and suggest you read
/sbin/cbq (large, fairly well documented bash script). Can't provide
any help yet though.

Ron

[Markku Kolkka]

Rodolfo J. Paiz kirjoitti viestiss??n (l?hetysaika keskiviikko,

Post by Rodolfo J. Paiz
The firewall/gateway will run Fedora Core 1. I think I need
*five* Ethernet adapters in the server (eth0 to the ISP, and
eth1-eth4 to the four tenants) so that each client is properly
isolated into their own network and cannot access the other
clients' computers. If there is a way to do this securely and
safely without a gaggle of Ethernet cards, please do tell!

If running out of PCI slots is the problem, there are dual and
quad port Ethernet adapters, e.g from Intel:
http://www.intel.com/network/connectivity/products/pro100dport_adapter.htm
http://www.intel.com/network/connectivity/products/pro1000mt_quad_server_adapter.htm

However, five regular adapters will be cheaper.

[Jeff Vian]

Post by Rodolfo J. Paiz
Hey...
I have no idea of which FM to R here, so I will happily accept
pointers to good documentation and HOWTO documents. Any other help is
also welcome, as I will need to solve this problem very soon. The
My small business is one of four tenants in a small building. The
other three have agreed to allow me to buy one big connection and then
resell service to them, such that they get a better price and I get to
subsidize my own Internet service. However, while I *could* set this
up quickly without any controls, they each want different service
levels and amounts of bandwidth and will be paying different prices,
so I want to do this properly.
The firewall/gateway will run Fedora Core 1. I think I need *five*
Ethernet adapters in the server (eth0 to the ISP, and eth1-eth4 to the
four tenants) so that each client is properly isolated into their own
network and cannot access the other clients' computers. If there is a
way to do this securely and safely without a gaggle of Ethernet cards,
please do tell! I can think of doing this with 801.2q VLAN tagging,
but that requires a managed switch which is far more expensive. It
seems to me that multiple Ethernet cards are the simplest *and*
cheapest way to do it.

Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.

Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

You could thus use 192.168.2.X for one, 192.168.3.X for another, etc.
The command to set up an alias (virtual interface) on a nic is simple.
Use the same ifconfig command you would otherwise use but the interface
is listed as eth0:1, eth0:2, etc.
The files in /etc/sysconfig/network-scripts can be configured for each
virtual interface you use, or it can be put in /etc/rc.local if you want.

Then the firewall with iptables can be used to handle NAT, forwarding,
and with the options for specifying the mac address of a connection you
can even make sure you do not yourself allow them to communicate
directly and you would know if they tried to add additional machines..

Post by Rodolfo J. Paiz
I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP,
1. Required: Limit the total bandwidth a client can use to
either 128 Kbps or 256 Kbps.
2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all
other offices are gone for the night, or someone who gets lucky that
no one else is using the Net at that particular moment, could get
access to the entire Internet connection (say, 512 Kbps). But if
everyone is using the bandwidth simultaneously, then each would get
their fair share (what they paid for and I provide, proportionately).

The traffic shaper tools can do this AFAIK.

Post by Rodolfo J. Paiz
3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be
ideal for traffic *to* the server (client connecting to the firewall)
to have full 100 Mbps link speed. This would allow me to download the
FC2 ISO images to the server at night, for example, and then let
clients grab them at 100 Mbps over the internal network instead of
having that internal download also throttled to 256 Kbps.

Someone else will have to answer this

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory
on the server which can *only* be accessed from their network. So if
they pull down the confidential something or their wife's nude
pictures, other tenants cannot get at that information.

provide each user/client with an ftp directory they can log into as a
user. by default vsftp provides a chroot jail for them.

Post by Rodolfo J. Paiz
Can someone offer some hints, pointers, suggestions, or magic beans?
Thanks in advance!

[Benjamin J. Weiss]

From: "Jeff Vian" <jvian10 at charter.net>
<snip>

Post by Jeff Vian
Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

Ben

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign the
192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to Tenant #2,
etc. via DHCP on a single server if all of them are coming in via a switch.

Once everyone has an IP address, this is great. But how to assign them?

Thanks,

[neil]

Post by Rodolfo J. Paiz

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some
other way of handing out IP addresses. I do not see how to use DHCP to
assign the 192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block
to Tenant #2, etc. via DHCP on a single server if all of them are
coming in via a switch.
Once everyone has an IP address, this is great. But how to assign them?
Thanks,

You could make it a condition that each of them supply you the MAC
address of their machines and use DHCP to assign addresses based on them
- or you assign each of them a block of ranges they can use and
configure them themselves.

neil

[duncan brown]

Post by Rodolfo J. Paiz
It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign
the 192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to
Tenant #2, etc. via DHCP on a single server if all of them are coming
in via a switch.
Once everyone has an IP address, this is great. But how to assign them?

you can set dhcpd to assign specific ips and hostnames to specific
hardware addresses (mac/ethernet address).

personally, (this is just me), you should act as an isp, not as someone
providing everyone with internal networking. give them a single ethernet
drop, have them buy a simple firewall/router box from staples (they're
like $50) and let them take care of everything on their end.

that way you could limit what connects to your system by mac address of
the routers, preventing them from abusing your system.

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Rodolfo J. Paiz]

I do not see how to use DHCP to assign the 192.168.1.0/24 block to
Tenant #1, the 192.168.2.0/24 block to Tenant #2, etc. via DHCP on
a single server if all of them are coming in via a switch.

As a follow-up, I have discovered that the ISC dhcp server package included
in Fedora and Red Hat Linux releases will identify and assign an address
based on the active subnet of the interface on which the request came in,
and it will do so automatically without any configuration. So if you have
these interfaces...

eth0: 192.168.0.1/24
eth1: 192.168.1.1/24

...and you have this in /etc/dhcpd.conf...

subnet 192.168.0.0 netmask 255.255.255.0 {
options routers 192.168.0.1;
options domain-name "domain.com";
options domain-name-servers 192.168.0.1;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
options routers 192.168.1.1;
options domain-name "domain2.com";
options domain-name-servers 192.168.1.1;
}

...then any host on the network connected to eth0 will be dynamically
assigned a 192.168.0.x address and any host coming in on eth1 will be
assigned a 192.168.1.y address. Perfect.

This is not clear from "man dhcpd.conf" and confused me for a while.
Hopefully this post will help someone on these lists, and I'll work with
the ISC folks to add a few comments to the documentation.

Cheers,

[Rodolfo J. Paiz]

I do not see how to use DHCP to assign the 192.168.1.0/24 block to
Tenant #1, the 192.168.2.0/24 block to Tenant #2, etc. via DHCP on
a single server if all of them are coming in via a switch.

As a follow-up, I have discovered that the ISC dhcp server package included
in Fedora and Red Hat Linux releases will identify and assign an address
based on the active subnet of the interface on which the request came in,
and it will do so automatically without any configuration. So if you have
these interfaces...

eth0: 192.168.0.1/24
eth1: 192.168.1.1/24

...and you have this in /etc/dhcpd.conf...

subnet 192.168.0.0 netmask 255.255.255.0 {
options routers 192.168.0.1;
options domain-name "domain.com";
options domain-name-servers 192.168.0.1;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
options routers 192.168.1.1;
options domain-name "domain2.com";
options domain-name-servers 192.168.1.1;
}

...then any host on the network connected to eth0 will be dynamically
assigned a 192.168.0.x address and any host coming in on eth1 will be
assigned a 192.168.1.y address. Perfect.

This is not clear from "man dhcpd.conf" and confused me for a while.
Hopefully this post will help someone on these lists, and I'll work with
the ISC folks to add a few comments to the documentation.

Cheers,

[Benjamin J. Weiss]

From: "Rodolfo J. Paiz" <rpaiz at simpaticus.com>

Post by Rodolfo J. Paiz

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign the
192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to Tenant #2,
etc. via DHCP on a single server if all of them are coming in via a switch.
Once everyone has an IP address, this is great. But how to assign them?

I think you're right. To do what you're needing to do, you need the five
NICs. However, I was able to do something like this with an old 486 Dell
and a bunch of ISA NICs about five years ago, using LRP (the linux routing
project). I don't have the liink, but it worked pretty well with only 32
meg of ram.

Ben

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
I think you're right. To do what you're needing to do, you need the five
NICs.

Hey, maybe not! Going on duncan brown's comment about spending $75 per
tenant on a small Netgear router, those do masquerading, right? So if I
went that route, then they each have their individual subnet but *I* get
all traffic coming from a single IP address! At that point I *can* simply
plug all tenants into the switch, and do traffic shaping/limiting based on
the IP address, and only use two NIC's in the central server. Eliminates
the DHCP requirement, and I can also filter by MAC address for additional
security.

I'm starting to like that idea more and more.

[duncan brown]

Post by Rodolfo J. Paiz
Hey, maybe not! Going on duncan brown's comment about spending $75 per
tenant on a small Netgear router, those do masquerading, right? So if I
went that route, then they each have their individual subnet but *I* get
all traffic coming from a single IP address! At that point I *can*
simply plug all tenants into the switch, and do traffic
shaping/limiting based on the IP address, and only use two NIC's in the
central server. Eliminates the DHCP requirement, and I can also filter
by MAC address for additional security.
I'm starting to like that idea more and more.

yeah, i had a computer in my home office room that was doing routing
(basically an ethernet bridge), dhcpd, bind and all kinds of stuff.
really expensive on the power, too... and then i just said 'fuck it', went
out and got an ethernet bridge and a hub.

just because you can do it and make it complicated under linux doesn't
mean that you need to. =] some things that don't require microsoft also
don't require linux =]

though, why wouldn't you need dhcpd? you'll still have to serve out ips
to your ''customers''...

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[duncan brown]

Post by Rodolfo J. Paiz
Hey, maybe not! Going on duncan brown's comment about spending $75 per
tenant on a small Netgear router, those do masquerading, right? So if I
went that route, then they each have their individual subnet but *I* get
all traffic coming from a single IP address! At that point I *can*
simply plug all tenants into the switch, and do traffic
shaping/limiting based on the IP address, and only use two NIC's in the
central server. Eliminates the DHCP requirement, and I can also filter
by MAC address for additional security.
I'm starting to like that idea more and more.

yeah, i had a computer in my home office room that was doing routing
(basically an ethernet bridge), dhcpd, bind and all kinds of stuff.
really expensive on the power, too... and then i just said 'fuck it', went
out and got an ethernet bridge and a hub.

just because you can do it and make it complicated under linux doesn't
mean that you need to. =] some things that don't require microsoft also
don't require linux =]

though, why wouldn't you need dhcpd? you'll still have to serve out ips
to your ''customers''...

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
I think you're right. To do what you're needing to do, you need the five
NICs.

Hey, maybe not! Going on duncan brown's comment about spending $75 per
tenant on a small Netgear router, those do masquerading, right? So if I
went that route, then they each have their individual subnet but *I* get
all traffic coming from a single IP address! At that point I *can* simply
plug all tenants into the switch, and do traffic shaping/limiting based on
the IP address, and only use two NIC's in the central server. Eliminates
the DHCP requirement, and I can also filter by MAC address for additional
security.

I'm starting to like that idea more and more.

[neil]

Post by Rodolfo J. Paiz

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some
other way of handing out IP addresses. I do not see how to use DHCP to
assign the 192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block
to Tenant #2, etc. via DHCP on a single server if all of them are
coming in via a switch.
Once everyone has an IP address, this is great. But how to assign them?
Thanks,

You could make it a condition that each of them supply you the MAC
address of their machines and use DHCP to assign addresses based on them
- or you assign each of them a block of ranges they can use and
configure them themselves.

neil

[duncan brown]

Post by Rodolfo J. Paiz
It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign
the 192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to
Tenant #2, etc. via DHCP on a single server if all of them are coming
in via a switch.
Once everyone has an IP address, this is great. But how to assign them?

you can set dhcpd to assign specific ips and hostnames to specific
hardware addresses (mac/ethernet address).

personally, (this is just me), you should act as an isp, not as someone
providing everyone with internal networking. give them a single ethernet
drop, have them buy a simple firewall/router box from staples (they're
like $50) and let them take care of everything on their end.

that way you could limit what connects to your system by mac address of
the routers, preventing them from abusing your system.

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Benjamin J. Weiss]

From: "Rodolfo J. Paiz" <rpaiz at simpaticus.com>

Post by Rodolfo J. Paiz

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign the
192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to Tenant #2,
etc. via DHCP on a single server if all of them are coming in via a switch.
Once everyone has an IP address, this is great. But how to assign them?

I think you're right. To do what you're needing to do, you need the five
NICs. However, I was able to do something like this with an old 486 Dell
and a bunch of ISA NICs about five years ago, using LRP (the linux routing
project). I don't have the liink, but it worked pretty well with only 32
meg of ram.

Ben

[Jeff Vian]

Post by Benjamin J. Weiss
From: "Jeff Vian" <jvian10 at charter.net>
<snip>

Post by Jeff Vian
Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

Right, but if they know they were on the same physical network they
might snoop/play with configs/change IPs, etc. That was my only reason
for making this comment.

However with careful setup of iptables the MAC address would have to
match IP so that would not likely be an issue.

Post by Benjamin J. Weiss
Ben

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss

Post by Jeff Vian
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

It seems to me that this would work perfectly *if* each tenant either
configures all their machines with static IP addresses or has some other
way of handing out IP addresses. I do not see how to use DHCP to assign the
192.168.1.0/24 block to Tenant #1, the 192.168.2.0/24 block to Tenant #2,
etc. via DHCP on a single server if all of them are coming in via a switch.

Once everyone has an IP address, this is great. But how to assign them?

Thanks,

[Jeff Vian]

Post by Benjamin J. Weiss
From: "Jeff Vian" <jvian10 at charter.net>
<snip>

Post by Jeff Vian
Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

Right, but if they know they were on the same physical network they
might snoop/play with configs/change IPs, etc. That was my only reason
for making this comment.

However with careful setup of iptables the MAC address would have to
match IP so that would not likely be an issue.

Post by Benjamin J. Weiss
Ben

[Rodolfo J. Paiz]

Not necessary to use that many adapters, It can easily be done on 2, one
for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth for
each.
The only real problem will come in if they decide to snoop and since with
this method they would all be on the same physical network they might find
the other machines.
You could thus use 192.168.2.X for one, 192.168.3.X for another, etc.

Snooping is not really a problem. Two of the four tenants are companies
owned by my family, the third is my own company, and the fourth is owned by
three of my friends. And no one really has any technical talent. :-) The
issue really is that a 512 Kbps Internet connection is going to cost
upwards of $600 per month and people are going to be paying for a service
level, so they should get their fair share. Besides, as Ben pointed out,
snooping is mostly eliminated at the switch anyway.

My lack of understanding here is in the assignation of the IP addresses for
the client. It sounds to me like four virtual adapters on one real Ethernet
card will look the same to the DHCP server, so one cannot assign different
subnets to different tenants unless they really are on separate interfaces.
But now that I think about it (and after checking out the dhcpd.conf man
page briefly) I cannot see how to specifically assign the 192.168.1.0/24
subnet to eth1 (or eth0:1) anyway... maybe I'd actually have to run four
dhcpd processes, each listening on a single interface?

There must be a simpler way... I'm sure I'm missing something here.

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they
pull down the confidential something or their wife's nude pictures,
other tenants cannot get at that information.

provide each user/client with an ftp directory they can log into as a
user. by default vsftp provides a chroot jail for them.

Excellent. Thanks!

[Jeff Lasman]

Post by Rodolfo J. Paiz
Snooping is not really a problem. Two of the four tenants are
companies owned by my family, the third is my own company, and the
fourth is owned by three of my friends. And no one really has any
technical talent. :-)

Rodolfo,

While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list

Jeff

[duncan brown]

Post by Jeff Lasman
While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

also, you may want to check out www.smoothwall.org

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Ed Jones]

Just a word of warning (I was looking at smoothwall some time ago) - there
are some people who have had bad experiences with smoothwall.

Have a nose at
http://groups.google.com/groups?q=g:thl2357725747d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=87n0uknjte.fsf%40amaterasu.srvr.nix

(forgive the long link) for a discussion about one 'security fix' they
released.

Also, look at http://slashdot.org/comments.pl?sid=29598&cid=3180564 for a
bit of insight into wrangling between smoothwall and ipcop developers. Not
nice.

Obviously, neither of the URLs above necessarily affect the usefulness of
the product.

You could consider astaro security linux (www.astaro.com), which is free for
home users. Don't know how much it would cost in your situation, though.

Ed
----- Original Message -----
From: "duncan brown" <duncanbrown at linuxadvocate.net>
To: <fedora-list at redhat.com>
Sent: Wednesday, May 05, 2004 5:31 PM
Subject: Re: Routing and bandwidth problem

Post by duncan brown

Post by Jeff Lasman
While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

also, you may want to check out www.smoothwall.org
+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+
--------------------------------------------------
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------
--
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

[Ed Jones]

Just a word of warning (I was looking at smoothwall some time ago) - there
are some people who have had bad experiences with smoothwall.

Have a nose at
http://groups.google.com/groups?q=g:thl2357725747d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=87n0uknjte.fsf%40amaterasu.srvr.nix

(forgive the long link) for a discussion about one 'security fix' they
released.

Also, look at http://slashdot.org/comments.pl?sid=29598&cid=3180564 for a
bit of insight into wrangling between smoothwall and ipcop developers. Not
nice.

Obviously, neither of the URLs above necessarily affect the usefulness of
the product.

You could consider astaro security linux (www.astaro.com), which is free for
home users. Don't know how much it would cost in your situation, though.

Ed
----- Original Message -----
From: "duncan brown" <duncanbrown at linuxadvocate.net>
To: <fedora-list at redhat.com>
Sent: Wednesday, May 05, 2004 5:31 PM
Subject: Re: Routing and bandwidth problem

Post by duncan brown

Post by Jeff Lasman
While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

also, you may want to check out www.smoothwall.org
+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+
--------------------------------------------------
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------
--
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

[duncan brown]

Post by Jeff Lasman
While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

also, you may want to check out www.smoothwall.org

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Jeff Lasman]

Post by Rodolfo J. Paiz
Snooping is not really a problem. Two of the four tenants are
companies owned by my family, the third is my own company, and the
fourth is owned by three of my friends. And no one really has any
technical talent. :-)

Rodolfo,

While I'd probably do this with LRP (Linux Router Project) instead of an
out-of-the-"box" Fedora install, the best place to ask this question
would probably be on the inet-access list.

See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list

Jeff

[Benjamin J. Weiss]

From: "Jeff Vian" <jvian10 at charter.net>
<snip>

Post by Jeff Vian
Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

Actually, if he hooks the four tennents and the router to a five port
switch, the tennents won't be able to sniff anything but the broadcast
packets.

Ben

[Rodolfo J. Paiz]

Not necessary to use that many adapters, It can easily be done on 2, one
for the internet and one for the LAN.
Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth for
each.
The only real problem will come in if they decide to snoop and since with
this method they would all be on the same physical network they might find
the other machines.
You could thus use 192.168.2.X for one, 192.168.3.X for another, etc.

Snooping is not really a problem. Two of the four tenants are companies
owned by my family, the third is my own company, and the fourth is owned by
three of my friends. And no one really has any technical talent. :-) The
issue really is that a 512 Kbps Internet connection is going to cost
upwards of $600 per month and people are going to be paying for a service
level, so they should get their fair share. Besides, as Ben pointed out,
snooping is mostly eliminated at the switch anyway.

My lack of understanding here is in the assignation of the IP addresses for
the client. It sounds to me like four virtual adapters on one real Ethernet
card will look the same to the DHCP server, so one cannot assign different
subnets to different tenants unless they really are on separate interfaces.
But now that I think about it (and after checking out the dhcpd.conf man
page briefly) I cannot see how to specifically assign the 192.168.1.0/24
subnet to eth1 (or eth0:1) anyway... maybe I'd actually have to run four
dhcpd processes, each listening on a single interface?

There must be a simpler way... I'm sure I'm missing something here.

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they
pull down the confidential something or their wife's nude pictures,
other tenants cannot get at that information.

provide each user/client with an ftp directory they can log into as a
user. by default vsftp provides a chroot jail for them.

Excellent. Thanks!

[Jay Scherrer]

Why not just use a router / switch?
Thus it reduces the nic's down to two: one for the wan and one for the lan.
Jay

Message: 15

Rodolfo J. Paiz kirjoitti viestiss??n (l?hetysaika keskiviikko,

The firewall/gateway will run Fedora Core 1. I think I need
*five* Ethernet adapters in the server (eth0 to the ISP, and
eth1-eth4 to the four tenants) so that each client is properly
isolated into their own network and cannot access the other
clients' computers. If there is a way to do this securely and
safely without a gaggle of Ethernet cards, please do tell!
If running out of PCI slots is the problem, there are dual and

[Rodolfo J. Paiz]

Post by Jay Scherrer
Why not just use a router / switch?
Thus it reduces the nic's down to two: one for the wan and one for the lan.

A) There are four LAN's.

B) Money. I'm building the router/firewall on Fedora to save some.

However, as someone (?) commented earlier, buying small/simple Netgear
routers for each tenant *would* make things very simple. Anyone have
*really* good experiences with any of those (not Linksys, I'm rather sick
of them)?

[duncan brown]

Post by Rodolfo J. Paiz
However, as someone (?) commented earlier, buying small/simple Netgear
routers for each tenant *would* make things very simple. Anyone have
*really* good experiences with any of those (not Linksys, I'm rather
sick of them)?

that would be me who made the comment =].

netgear routers are really nice... i run a fr114p at work. i also run an
asante at home, but it's old (4+years) and not very configurable,
meanwhile the netgear does syslog, emails you alerts, is a print server,
logging, distributed computing (requests to a specific port go to a
specific machine), block sites (i've blocked doubleclick and several
others). tons more, i've just been peeking.

Send E-Mail alerts immediately
If a DoS attack is detected.
If a Port Scan is detected.
If someone attempts to access a blocked site.

so, there you go.

alot of the newer ones also have really nice dns/dhcp services, naming
your systems based upon mac address.

hell, you may be able to find one that does traffic shaping too (for them
all to connect to), that'll make things even easier for you.

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[duncan brown]

Post by Rodolfo J. Paiz
However, as someone (?) commented earlier, buying small/simple Netgear
routers for each tenant *would* make things very simple. Anyone have
*really* good experiences with any of those (not Linksys, I'm rather
sick of them)?

that would be me who made the comment =].

netgear routers are really nice... i run a fr114p at work. i also run an
asante at home, but it's old (4+years) and not very configurable,
meanwhile the netgear does syslog, emails you alerts, is a print server,
logging, distributed computing (requests to a specific port go to a
specific machine), block sites (i've blocked doubleclick and several
others). tons more, i've just been peeking.

Send E-Mail alerts immediately
If a DoS attack is detected.
If a Port Scan is detected.
If someone attempts to access a blocked site.

so, there you go.

alot of the newer ones also have really nice dns/dhcp services, naming
your systems based upon mac address.

hell, you may be able to find one that does traffic shaping too (for them
all to connect to), that'll make things even easier for you.

-d

+( duncan brown : duncanbrown at linuxadvocate.net )+
+( linux "just works" : www.linuxadvocate.net )+

--------------------------------------------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing
a (free) operating system (just a hobby, won't be
big and professional like gnu) for 386(486) AT
clones"
- Linus Torvalds, August 1991
--------------------------------------------------

[Kent Borg]

Post by Jay Scherrer
Thus it reduces the nic's down to two: one for the wan and one for the lan.

Why two? Can't one handle both? The server routes between different
networks, but one wire can handle multiple networks.


-kb, the Kent who is late to the thread because he gets behind in his
e-mail--but at least he rad the whole thread before posting.

[Rodolfo J. Paiz]

Post by Kent Borg

Post by Jay Scherrer
Thus it reduces the nic's down to two: one for the wan and one for the lan.

Why two? Can't one handle both? The server routes between different
networks, but one wire can handle multiple networks.

It is extremely unwise to firewall using only one interface, for several
reasons. I will admit that I do not fully understand all of them, but on
the common sense level: if you want to protect your network from the BBI
(Big Bad Internet [tm]), you certainly don't want "outside" and "inside" to
be on the same wire. Just too high a probability of errors and an increased
probability of snooping, sniffing, or other nasty behavior.

Cheers,

[Rodolfo J. Paiz]

Post by Kent Borg

Post by Jay Scherrer
Thus it reduces the nic's down to two: one for the wan and one for the lan.

Why two? Can't one handle both? The server routes between different
networks, but one wire can handle multiple networks.

It is extremely unwise to firewall using only one interface, for several
reasons. I will admit that I do not fully understand all of them, but on
the common sense level: if you want to protect your network from the BBI
(Big Bad Internet [tm]), you certainly don't want "outside" and "inside" to
be on the same wire. Just too high a probability of errors and an increased
probability of snooping, sniffing, or other nasty behavior.

Cheers,

[Rodolfo J. Paiz]

Post by Jay Scherrer
Why not just use a router / switch?
Thus it reduces the nic's down to two: one for the wan and one for the lan.

A) There are four LAN's.

B) Money. I'm building the router/firewall on Fedora to save some.

However, as someone (?) commented earlier, buying small/simple Netgear
routers for each tenant *would* make things very simple. Anyone have
*really* good experiences with any of those (not Linksys, I'm rather sick
of them)?

[Kent Borg]

Post by Jay Scherrer
Thus it reduces the nic's down to two: one for the wan and one for the lan.

Why two? Can't one handle both? The server routes between different
networks, but one wire can handle multiple networks.


-kb, the Kent who is late to the thread because he gets behind in his
e-mail--but at least he rad the whole thread before posting.

[Tim Alberts]

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.

You should try ProFTPd (http://www.proftpd.org/). There configuration is
similar to apache where you can create virtual FTP servers for each IP
address. I've been using this program for years on my office network and it
is always running perfect.

[Rodolfo J. Paiz]

Hey...

I have no idea of which FM to R here, so I will happily accept pointers to
good documentation and HOWTO documents. Any other help is also welcome, as
I will need to solve this problem very soon. The problem is this:

My small business is one of four tenants in a small building. The other
three have agreed to allow me to buy one big connection and then resell
service to them, such that they get a better price and I get to subsidize
my own Internet service. However, while I *could* set this up quickly
without any controls, they each want different service levels and amounts
of bandwidth and will be paying different prices, so I want to do this
properly.

The firewall/gateway will run Fedora Core 1. I think I need *five* Ethernet
adapters in the server (eth0 to the ISP, and eth1-eth4 to the four tenants)
so that each client is properly isolated into their own network and cannot
access the other clients' computers. If there is a way to do this securely
and safely without a gaggle of Ethernet cards, please do tell! I can think
of doing this with 801.2q VLAN tagging, but that requires a managed switch
which is far more expensive. It seems to me that multiple Ethernet cards
are the simplest *and* cheapest way to do it.

I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP, and
other services. What I don't know how to do is the following:

1. Required: Limit the total bandwidth a client can use to either
128 Kbps or 256 Kbps.

2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all other
offices are gone for the night, or someone who gets lucky that no one else
is using the Net at that particular moment, could get access to the entire
Internet connection (say, 512 Kbps). But if everyone is using the bandwidth
simultaneously, then each would get their fair share (what they paid for
and I provide, proportionately).

3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be ideal
for traffic *to* the server (client connecting to the firewall) to have
full 100 Mbps link speed. This would allow me to download the FC2 ISO
images to the server at night, for example, and then let clients grab them
at 100 Mbps over the internal network instead of having that internal
download also throttled to 256 Kbps.

4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.

Can someone offer some hints, pointers, suggestions, or magic beans?

Thanks in advance!

[Ron Goulard]

Post by Rodolfo J. Paiz
Hey...
I have no idea of which FM to R here, so I will happily accept pointers to
good documentation and HOWTO documents. Any other help is also welcome, as
My small business is one of four tenants in a small building. The other
three have agreed to allow me to buy one big connection and then resell
service to them, such that they get a better price and I get to subsidize
my own Internet service. However, while I *could* set this up quickly
without any controls, they each want different service levels and amounts
of bandwidth and will be paying different prices, so I want to do this
properly.
The firewall/gateway will run Fedora Core 1. I think I need *five* Ethernet
adapters in the server (eth0 to the ISP, and eth1-eth4 to the four tenants)
so that each client is properly isolated into their own network and cannot
access the other clients' computers. If there is a way to do this securely
and safely without a gaggle of Ethernet cards, please do tell! I can think
of doing this with 801.2q VLAN tagging, but that requires a managed switch
which is far more expensive. It seems to me that multiple Ethernet cards
are the simplest *and* cheapest way to do it.
I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP, and
1. Required: Limit the total bandwidth a client can use to either
128 Kbps or 256 Kbps.
2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all other
offices are gone for the night, or someone who gets lucky that no one else
is using the Net at that particular moment, could get access to the entire
Internet connection (say, 512 Kbps). But if everyone is using the bandwidth
simultaneously, then each would get their fair share (what they paid for
and I provide, proportionately).
3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be ideal
for traffic *to* the server (client connecting to the firewall) to have
full 100 Mbps link speed. This would allow me to download the FC2 ISO
images to the server at night, for example, and then let clients grab them
at 100 Mbps over the internal network instead of having that internal
download also throttled to 256 Kbps.
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.
Can someone offer some hints, pointers, suggestions, or magic beans?
Thanks in advance!

Something that I've found in FC1 is cbq, part of the shapecfg package
(and needs iproute I believe). Basically it uses tc to control
traffic. It may help out with much of this without having to grab/find
other software, allowing you to keep it updated with existing fc1
repositories.

I've begun playing with it myself in my spare time and suggest you read
/sbin/cbq (large, fairly well documented bash script). Can't provide
any help yet though.

Ron

[Markku Kolkka]

Rodolfo J. Paiz kirjoitti viestiss??n (l?hetysaika keskiviikko,

Post by Rodolfo J. Paiz
The firewall/gateway will run Fedora Core 1. I think I need
*five* Ethernet adapters in the server (eth0 to the ISP, and
eth1-eth4 to the four tenants) so that each client is properly
isolated into their own network and cannot access the other
clients' computers. If there is a way to do this securely and
safely without a gaggle of Ethernet cards, please do tell!

If running out of PCI slots is the problem, there are dual and
quad port Ethernet adapters, e.g from Intel:
http://www.intel.com/network/connectivity/products/pro100dport_adapter.htm
http://www.intel.com/network/connectivity/products/pro1000mt_quad_server_adapter.htm

However, five regular adapters will be cheaper.

[Jeff Vian]

Post by Rodolfo J. Paiz
Hey...
I have no idea of which FM to R here, so I will happily accept
pointers to good documentation and HOWTO documents. Any other help is
also welcome, as I will need to solve this problem very soon. The
My small business is one of four tenants in a small building. The
other three have agreed to allow me to buy one big connection and then
resell service to them, such that they get a better price and I get to
subsidize my own Internet service. However, while I *could* set this
up quickly without any controls, they each want different service
levels and amounts of bandwidth and will be paying different prices,
so I want to do this properly.
The firewall/gateway will run Fedora Core 1. I think I need *five*
Ethernet adapters in the server (eth0 to the ISP, and eth1-eth4 to the
four tenants) so that each client is properly isolated into their own
network and cannot access the other clients' computers. If there is a
way to do this securely and safely without a gaggle of Ethernet cards,
please do tell! I can think of doing this with 801.2q VLAN tagging,
but that requires a managed switch which is far more expensive. It
seems to me that multiple Ethernet cards are the simplest *and*
cheapest way to do it.

Not necessary to use that many adapters, It can easily be done on 2,
one for the internet and one for the LAN.

Linux can run multiple IPs on a single adapter by using aliases in the
config, and then using the traffic shaper utils you can set bandwidth
for each.
The only real problem will come in if they decide to snoop and since
with this method they would all be on the same physical network they
might find the other machines.

You could thus use 192.168.2.X for one, 192.168.3.X for another, etc.
The command to set up an alias (virtual interface) on a nic is simple.
Use the same ifconfig command you would otherwise use but the interface
is listed as eth0:1, eth0:2, etc.
The files in /etc/sysconfig/network-scripts can be configured for each
virtual interface you use, or it can be put in /etc/rc.local if you want.

Then the firewall with iptables can be used to handle NAT, forwarding,
and with the options for specifying the mac address of a connection you
can even make sure you do not yourself allow them to communicate
directly and you would know if they tried to add additional machines..

Post by Rodolfo J. Paiz
I know how to provide masquerading, firewall, gateway, DNS, DHCP, NTP,
1. Required: Limit the total bandwidth a client can use to
either 128 Kbps or 256 Kbps.
2. Optional: Allow each client to exceed their limit if no one
else is using the space. That is, a customer who stays late when all
other offices are gone for the night, or someone who gets lucky that
no one else is using the Net at that particular moment, could get
access to the entire Internet connection (say, 512 Kbps). But if
everyone is using the bandwidth simultaneously, then each would get
their fair share (what they paid for and I provide, proportionately).

The traffic shaper tools can do this AFAIK.

Post by Rodolfo J. Paiz
3. Optional: Even though traffic *through* the server (client
connecting to Internet) should be throttled and limited, it would be
ideal for traffic *to* the server (client connecting to the firewall)
to have full 100 Mbps link speed. This would allow me to download the
FC2 ISO images to the server at night, for example, and then let
clients grab them at 100 Mbps over the internal network instead of
having that internal download also throttled to 256 Kbps.

Someone else will have to answer this

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory
on the server which can *only* be accessed from their network. So if
they pull down the confidential something or their wife's nude
pictures, other tenants cannot get at that information.

provide each user/client with an ftp directory they can log into as a
user. by default vsftp provides a chroot jail for them.

Post by Rodolfo J. Paiz
Can someone offer some hints, pointers, suggestions, or magic beans?
Thanks in advance!

[Jay Scherrer]

Why not just use a router / switch?
Thus it reduces the nic's down to two: one for the wan and one for the lan.
Jay

Message: 15

Rodolfo J. Paiz kirjoitti viestiss??n (l?hetysaika keskiviikko,

The firewall/gateway will run Fedora Core 1. I think I need
*five* Ethernet adapters in the server (eth0 to the ISP, and
eth1-eth4 to the four tenants) so that each client is properly
isolated into their own network and cannot access the other
clients' computers. If there is a way to do this securely and
safely without a gaggle of Ethernet cards, please do tell!
If running out of PCI slots is the problem, there are dual and

[Tim Alberts]

Post by Rodolfo J. Paiz
4. Optional: Provide each tenant with an FTP-served directory on
the server which can *only* be accessed from their network. So if they pull
down the confidential something or their wife's nude pictures, other
tenants cannot get at that information.

You should try ProFTPd (http://www.proftpd.org/). There configuration is
similar to apache where you can create virtual FTP servers for each IP
address. I've been using this program for years on my office network and it
is always running perfect.

[Matt .]

I didn't see the start of this thread, but here's my $0.02 ...

The DHCP server shouldn't care what interface the request came in on, rather
it looks at the source network of the request.

So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

regards,
Matt.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2

[Rodolfo J. Paiz]

Post by Matt .
The DHCP server shouldn't care what interface the request came in on,
rather it looks at the source network of the request.

I'm no expert on DHCP, but I continued this thread since no one around here
was able to help me solve this problem earlier. Hence, having found a
solution I'm posting it.

Having said the "not an expert" bit, how the heck is a computer who does
not know what network it's on going to provide a source network for the
DHCP server? It wakes up, yells out a broadcast request for a DHCP server,
and the server has to answer that. The *only* way I see to do that is via
the network interface on which the request arrived at the router.

Post by Matt .
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

But that's precisely the point! We were seeking a way for *one* machine to
act as a router/firewall/gateway/dhcpd for four subnets that are directly
connected to it. No other routers exist in this scenario. Of *course* if
another router existed, it'd be a piece of cake. But the question was: if
this is the only router providing Internet access for four separate
networks who are currently not connected to anything and don't have
routers, how do you manage to assign them separate subnets via DHCP?

Only two solutions appear to exist and be functional: buying $75 Netgear
blue boxes to do DHCP for the subnets and masquerading so that all traffic
to my server comes from a single IP address, and setting up separate
interfaces on my router box. The "blue box" route was discarded due to the
expense (why spend $300 if not necessary), the additional points of failure
(despite being highly reliable), the additional configuration and
maintenance required, and the slightly lower functionality (if one user on
those subnets were abusing bandwidth, it'd be hell to find them).

Having chosen to do it all on one box, the challenge appeared to be for
DHCPd to issue different addresses based on the interface on which the
request arrived. The documentation appeared to offer no easy way to do
this, and I interpreted that to mean that it would be a difficult
challenge. Turns out, it's automatic!

1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been told to
assign addresses on that subnet via a range statement. Nothing more to be done.

Too simple. <grin>

Cheers,

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
on in /etc/sysconfig/dhcpd:
DHCPDARGS="eth1 eth2"

Regards,
Luciano Rocha

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
DHCPDARGS="eth1 eth2"

Entirely separate and different topics, even though you are correct. In my
case I have eth0 to the Internet and eth1-eth4 to the local networks. I
*do* have dhcpd set to listen on every interface *except* eth0. Wouldn't
want to attempt to serve DHCP to my Internet Service Provider.

However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

Cheers,

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz

Post by Rodolfo J. Paiz

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not

assign

Post by Rodolfo J. Paiz
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
DHCPDARGS="eth1 eth2"

Entirely separate and different topics, even though you are correct. In my
case I have eth0 to the Internet and eth1-eth4 to the local networks. I
*do* have dhcpd set to listen on every interface *except* eth0. Wouldn't
want to attempt to serve DHCP to my Internet Service Provider.
However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.

It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

Regards,
Luciano Rocha

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.
It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

I'll try to be a little more specific: if you want dhcpd to accurately
assign addresses to requests coming in on any or nearly any interface, what
I was told by some of its maintainers just a few days ago is that the
correct procedure is to let dhcpd know about any and all
statically-configured subnets on that box. For example, even if I don't
assign IP addresses on my Internet link with a static IP address, dhcpd
would like me to let it know about that subnet anyway to avoid confusion
(subnet without range).

Better for you that way?

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
However, what I said above refers to the fact that dhcpd *must* know

about

Post by Rodolfo J. Paiz
every subnet configured on the box even if it does not assign addresses

on

Post by Rodolfo J. Paiz
that subnet or listen on that interface. Why? Apparently (according to

its

Post by Rodolfo J. Paiz
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.
It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

I'll try to be a little more specific: if you want dhcpd to accurately
assign addresses to requests coming in on any or nearly any interface, what
I was told by some of its maintainers just a few days ago is that the
correct procedure is to let dhcpd know about any and all
statically-configured subnets on that box. For example, even if I don't
assign IP addresses on my Internet link with a static IP address, dhcpd
would like me to let it know about that subnet anyway to avoid confusion
(subnet without range).
Better for you that way?

Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

Regards,
Luciano Rocha

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha
Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

BTW, although it's not much of an excuse I was very short on sleep and got
a little cranky with you. My bad... sorry.

All my life I've configured dhcpd *only* for the one subnet on which I was
assigning addresses and limited the interfaces to which the server process
listened via the DHCPDARGS variable in /etc/sysconfig/dhcpd. Just like you.
Now, when investigating dhcpd for multiple interfaces and subnets, I was
told that the ideal procedure is to document all configured static subnets
to avoid some possible confusion on dhcpd's part... that is, not strictly
necessary but better.

Since in this case the suggestion is also neater and seems to me more
thorough, I'm happy to take it and make it part of my standard operating
procedures. Besides, I'm happy to avoid "some possible confusion" that
might eventually happen in any of my systems! <smile>

Cheers,

[Craig White]

Post by Rodolfo J. Paiz

Post by Luciano Miguel Ferreira Rocha
Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

BTW, although it's not much of an excuse I was very short on sleep and got
a little cranky with you. My bad... sorry.
All my life I've configured dhcpd *only* for the one subnet on which I was
assigning addresses and limited the interfaces to which the server process
listened via the DHCPDARGS variable in /etc/sysconfig/dhcpd. Just like you.
Now, when investigating dhcpd for multiple interfaces and subnets, I was
told that the ideal procedure is to document all configured static subnets
to avoid some possible confusion on dhcpd's part... that is, not strictly
necessary but better.
Since in this case the suggestion is also neater and seems to me more
thorough, I'm happy to take it and make it part of my standard operating
procedures. Besides, I'm happy to avoid "some possible confusion" that
might eventually happen in any of my systems! <smile>

----
I think that the maintainers have required a configuration section for
all interfaces 'seen' by dhcpd whereas Red Hat, has allowed options in
/etc/sysconfig/dhcpd, which are applied as arguments to the launch of
the dhcpd daemon by the init.d script which allow you to designate which
interfaces are 'seen'. Thus, if you configure only specific interfaces
in /etc/sysconfig/dhcpd, then you only need refer to those interfaces in
/etc/dhcpd.conf

Craig

[Rodolfo J. Paiz]

Post by Craig White
I think that the maintainers have required a configuration section for
all interfaces 'seen' by dhcpd whereas Red Hat, has allowed options in
/etc/sysconfig/dhcpd, which are applied as arguments to the launch of
the dhcpd daemon by the init.d script which allow you to designate which
interfaces are 'seen'. Thus, if you configure only specific interfaces
in /etc/sysconfig/dhcpd, then you only need refer to those interfaces in
/etc/dhcpd.conf

Seems like an excellent explanation. Now that I know that having all
subnets mentioned in dhcpd.conf *could* be a good thing, and *can't* be a
bad thing, I'm going to stick with putting my interfaces in
/etc/sysconfig/dhcpd.conf and *also* specifying all subnets in dhcpd.conf.
Less chance of a mistake or misconfiguration that way.

Cheers,

[Rodolfo J. Paiz]

Post by Craig White
I think that the maintainers have required a configuration section for
all interfaces 'seen' by dhcpd whereas Red Hat, has allowed options in
/etc/sysconfig/dhcpd, which are applied as arguments to the launch of
the dhcpd daemon by the init.d script which allow you to designate which
interfaces are 'seen'. Thus, if you configure only specific interfaces
in /etc/sysconfig/dhcpd, then you only need refer to those interfaces in
/etc/dhcpd.conf

Seems like an excellent explanation. Now that I know that having all
subnets mentioned in dhcpd.conf *could* be a good thing, and *can't* be a
bad thing, I'm going to stick with putting my interfaces in
/etc/sysconfig/dhcpd.conf and *also* specifying all subnets in dhcpd.conf.
Less chance of a mistake or misconfiguration that way.

Cheers,

[Craig White]

Post by Rodolfo J. Paiz

Post by Luciano Miguel Ferreira Rocha
Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

BTW, although it's not much of an excuse I was very short on sleep and got
a little cranky with you. My bad... sorry.
All my life I've configured dhcpd *only* for the one subnet on which I was
assigning addresses and limited the interfaces to which the server process
listened via the DHCPDARGS variable in /etc/sysconfig/dhcpd. Just like you.
Now, when investigating dhcpd for multiple interfaces and subnets, I was
told that the ideal procedure is to document all configured static subnets
to avoid some possible confusion on dhcpd's part... that is, not strictly
necessary but better.
Since in this case the suggestion is also neater and seems to me more
thorough, I'm happy to take it and make it part of my standard operating
procedures. Besides, I'm happy to avoid "some possible confusion" that
might eventually happen in any of my systems! <smile>

----
I think that the maintainers have required a configuration section for
all interfaces 'seen' by dhcpd whereas Red Hat, has allowed options in
/etc/sysconfig/dhcpd, which are applied as arguments to the launch of
the dhcpd daemon by the init.d script which allow you to designate which
interfaces are 'seen'. Thus, if you configure only specific interfaces
in /etc/sysconfig/dhcpd, then you only need refer to those interfaces in
/etc/dhcpd.conf

Craig

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha
Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

BTW, although it's not much of an excuse I was very short on sleep and got
a little cranky with you. My bad... sorry.

All my life I've configured dhcpd *only* for the one subnet on which I was
assigning addresses and limited the interfaces to which the server process
listened via the DHCPDARGS variable in /etc/sysconfig/dhcpd. Just like you.
Now, when investigating dhcpd for multiple interfaces and subnets, I was
told that the ideal procedure is to document all configured static subnets
to avoid some possible confusion on dhcpd's part... that is, not strictly
necessary but better.

Since in this case the suggestion is also neater and seems to me more
thorough, I'm happy to take it and make it part of my standard operating
procedures. Besides, I'm happy to avoid "some possible confusion" that
might eventually happen in any of my systems! <smile>

Cheers,

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
However, what I said above refers to the fact that dhcpd *must* know

about

Post by Rodolfo J. Paiz
every subnet configured on the box even if it does not assign addresses

on

Post by Rodolfo J. Paiz
that subnet or listen on that interface. Why? Apparently (according to

its

Post by Rodolfo J. Paiz
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.
It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

I'll try to be a little more specific: if you want dhcpd to accurately
assign addresses to requests coming in on any or nearly any interface, what
I was told by some of its maintainers just a few days ago is that the
correct procedure is to let dhcpd know about any and all
statically-configured subnets on that box. For example, even if I don't
assign IP addresses on my Internet link with a static IP address, dhcpd
would like me to let it know about that subnet anyway to avoid confusion
(subnet without range).
Better for you that way?

Well, I won't argue with the maintainers, though I can't figure out what
confusion could be caused by an interface the daemon never sees.

Regards,
Luciano Rocha

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.
It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

I'll try to be a little more specific: if you want dhcpd to accurately
assign addresses to requests coming in on any or nearly any interface, what
I was told by some of its maintainers just a few days ago is that the
correct procedure is to let dhcpd know about any and all
statically-configured subnets on that box. For example, even if I don't
assign IP addresses on my Internet link with a static IP address, dhcpd
would like me to let it know about that subnet anyway to avoid confusion
(subnet without range).

Better for you that way?

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz

Post by Rodolfo J. Paiz

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not

assign

Post by Rodolfo J. Paiz
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
DHCPDARGS="eth1 eth2"

Entirely separate and different topics, even though you are correct. In my
case I have eth0 to the Internet and eth1-eth4 to the local networks. I
*do* have dhcpd set to listen on every interface *except* eth0. Wouldn't
want to attempt to serve DHCP to my Internet Service Provider.
However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

No, there's no need to have a subnet configured for an interface that
the server isn't listening on.

It would be a nightmare otherwise, in my case, as the eth2 interface is
connected to the internet with a dynamic ip, and it often changes
networks.

Regards,
Luciano Rocha

[Rodolfo J. Paiz]

Post by Luciano Miguel Ferreira Rocha

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
DHCPDARGS="eth1 eth2"

Entirely separate and different topics, even though you are correct. In my
case I have eth0 to the Internet and eth1-eth4 to the local networks. I
*do* have dhcpd set to listen on every interface *except* eth0. Wouldn't
want to attempt to serve DHCP to my Internet Service Provider.

However, what I said above refers to the fact that dhcpd *must* know about
every subnet configured on the box even if it does not assign addresses on
that subnet or listen on that interface. Why? Apparently (according to its
maintainers) matching the subnet with the interface is how it determines
with certainty which address to assign.

Cheers,

[Jeff Vian]

Post by Rodolfo J. Paiz

Post by Matt .
The DHCP server shouldn't care what interface the request came in on,
rather it looks at the source network of the request.

I'm no expert on DHCP, but I continued this thread since no one around
here was able to help me solve this problem earlier. Hence, having
found a solution I'm posting it.
Having said the "not an expert" bit, how the heck is a computer who
does not know what network it's on going to provide a source network
for the DHCP server? It wakes up, yells out a broadcast request for a
DHCP server, and the server has to answer that. The *only* way I see
to do that is via the network interface on which the request arrived
at the router.

Post by Matt .
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

But that's precisely the point! We were seeking a way for *one*
machine to act as a router/firewall/gateway/dhcpd for four subnets
that are directly connected to it. No other routers exist in this
scenario. Of *course* if another router existed, it'd be a piece of
cake. But the question was: if this is the only router providing
Internet access for four separate networks who are currently not
connected to anything and don't have routers, how do you manage to
assign them separate subnets via DHCP?
Only two solutions appear to exist and be functional: buying $75
Netgear blue boxes to do DHCP for the subnets and masquerading so that
all traffic to my server comes from a single IP address, and setting
up separate interfaces on my router box. The "blue box" route was
discarded due to the expense (why spend $300 if not necessary), the
additional points of failure (despite being highly reliable), the
additional configuration and maintenance required, and the slightly
lower functionality (if one user on those subnets were abusing
bandwidth, it'd be hell to find them).
Having chosen to do it all on one box, the challenge appeared to be
for DHCPd to issue different addresses based on the interface on which
the request arrived. The documentation appeared to offer no easy way
to do this, and I interpreted that to mean that it would be a
difficult challenge. Turns out, it's automatic!
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not
assign addresses (i.e. the subnet block does not include a range
statement).
2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been
told to assign addresses on that subnet via a range statement. Nothing
more to be done.
Too simple. <grin>
Cheers,

Your approach works, and if you have multipl;e hosts on the same subnet
being served it may be best, as well as providing the routing for them.

You also should consider the technique of assigning IP address based on
the MAC address of the requester. This technique is used to DHCP assign
static ip addresses to servers on lots of networks. There is no need to
be tied to one interface per subnet, but rather since the DHCP request
broadcast includes the MAC address of the requester (as well as the
originating network IP if routed), it can be set in the configuration
tables to specify the address to be assigned.

[Luciano Miguel Ferreira Rocha]

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

No need, you can specify the interfaces that the dhcp server will listen
on in /etc/sysconfig/dhcpd:
DHCPDARGS="eth1 eth2"

Regards,
Luciano Rocha

[Jeff Vian]

Post by Rodolfo J. Paiz

Post by Matt .
The DHCP server shouldn't care what interface the request came in on,
rather it looks at the source network of the request.

I'm no expert on DHCP, but I continued this thread since no one around
here was able to help me solve this problem earlier. Hence, having
found a solution I'm posting it.
Having said the "not an expert" bit, how the heck is a computer who
does not know what network it's on going to provide a source network
for the DHCP server? It wakes up, yells out a broadcast request for a
DHCP server, and the server has to answer that. The *only* way I see
to do that is via the network interface on which the request arrived
at the router.

Post by Matt .
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

But that's precisely the point! We were seeking a way for *one*
machine to act as a router/firewall/gateway/dhcpd for four subnets
that are directly connected to it. No other routers exist in this
scenario. Of *course* if another router existed, it'd be a piece of
cake. But the question was: if this is the only router providing
Internet access for four separate networks who are currently not
connected to anything and don't have routers, how do you manage to
assign them separate subnets via DHCP?
Only two solutions appear to exist and be functional: buying $75
Netgear blue boxes to do DHCP for the subnets and masquerading so that
all traffic to my server comes from a single IP address, and setting
up separate interfaces on my router box. The "blue box" route was
discarded due to the expense (why spend $300 if not necessary), the
additional points of failure (despite being highly reliable), the
additional configuration and maintenance required, and the slightly
lower functionality (if one user on those subnets were abusing
bandwidth, it'd be hell to find them).
Having chosen to do it all on one box, the challenge appeared to be
for DHCPd to issue different addresses based on the interface on which
the request arrived. The documentation appeared to offer no easy way
to do this, and I interpreted that to mean that it would be a
difficult challenge. Turns out, it's automatic!
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not
assign addresses (i.e. the subnet block does not include a range
statement).
2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been
told to assign addresses on that subnet via a range statement. Nothing
more to be done.
Too simple. <grin>
Cheers,

Your approach works, and if you have multipl;e hosts on the same subnet
being served it may be best, as well as providing the routing for them.

You also should consider the technique of assigning IP address based on
the MAC address of the requester. This technique is used to DHCP assign
static ip addresses to servers on lots of networks. There is no need to
be tied to one interface per subnet, but rather since the DHCP request
broadcast includes the MAC address of the requester (as well as the
originating network IP if routed), it can be set in the configuration
tables to specify the address to be assigned.

[Rodolfo J. Paiz]

Post by Matt .
The DHCP server shouldn't care what interface the request came in on,
rather it looks at the source network of the request.

I'm no expert on DHCP, but I continued this thread since no one around here
was able to help me solve this problem earlier. Hence, having found a
solution I'm posting it.

Having said the "not an expert" bit, how the heck is a computer who does
not know what network it's on going to provide a source network for the
DHCP server? It wakes up, yells out a broadcast request for a DHCP server,
and the server has to answer that. The *only* way I see to do that is via
the network interface on which the request arrived at the router.

Post by Matt .
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

But that's precisely the point! We were seeking a way for *one* machine to
act as a router/firewall/gateway/dhcpd for four subnets that are directly
connected to it. No other routers exist in this scenario. Of *course* if
another router existed, it'd be a piece of cake. But the question was: if
this is the only router providing Internet access for four separate
networks who are currently not connected to anything and don't have
routers, how do you manage to assign them separate subnets via DHCP?

Only two solutions appear to exist and be functional: buying $75 Netgear
blue boxes to do DHCP for the subnets and masquerading so that all traffic
to my server comes from a single IP address, and setting up separate
interfaces on my router box. The "blue box" route was discarded due to the
expense (why spend $300 if not necessary), the additional points of failure
(despite being highly reliable), the additional configuration and
maintenance required, and the slightly lower functionality (if one user on
those subnets were abusing bandwidth, it'd be hell to find them).

Having chosen to do it all on one box, the challenge appeared to be for
DHCPd to issue different addresses based on the interface on which the
request arrived. The documentation appeared to offer no easy way to do
this, and I interpreted that to mean that it would be a difficult
challenge. Turns out, it's automatic!

1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not assign
addresses (i.e. the subnet block does not include a range statement).

2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been told to
assign addresses on that subnet via a range statement. Nothing more to be done.

Too simple. <grin>

Cheers,

[Benjamin J. Weiss]

Post by Matt .
I didn't see the start of this thread, but here's my $0.02 ...
The DHCP server shouldn't care what interface the request came in on, rather
it looks at the source network of the request.
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.
In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route. I believe that we had to
set up our central router (a Cisco Catalyst 3550 set up to route instead
of switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

Ben

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route.

You are entirely correct, they do not.

Post by Benjamin J. Weiss
I believe that we had to
set up our central router (a Cisco Catalyst 3550 set up to route instead
of switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

You have three options: (a) a separate DHCP server on each subnet; (b)
setting up each subnet's router to forward those packets as you did; or (c)
using the dhcrelay program included in ISC's dhcpd on each subnet.

Cheers,

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route.

You are entirely correct, they do not.

Post by Benjamin J. Weiss
I believe that we had to
set up our central router (a Cisco Catalyst 3550 set up to route instead
of switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

You have three options: (a) a separate DHCP server on each subnet; (b)
setting up each subnet's router to forward those packets as you did; or (c)
using the dhcrelay program included in ISC's dhcpd on each subnet.

Cheers,

[Matt .]

Post by Matt .
I didn't see the start of this thread, but here's my $0.02 ...
The DHCP server shouldn't care what interface the request came in on,
rather

Post by Matt .
it looks at the source network of the request.
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.
In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route. I believe that we had to set
up our central router (a Cisco Catalyst 3550 set up to route instead of
switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

Correct. DHCP is a broadcast. Routers don't normally forward broadcasts.
Configuring the router (with "ip helper-address") causes it to send a
unicast to the chosen DHCP server. Source address in the packet allows the
server to respond with an address for the correct subnet.

Just wanted to point out that it's not necessary to have more than one NIC
in the server to support multiple subnets. Of course, if the server is
routing for those subnets then there's nothing wrong with that either.

Regards,
Matt.

_________________________________________________________________
Get a Credit Card - 60 sec online response:
http://ad.au.doubleclick.net/clk;8097459;9106288;b?http://www.anz.com/aus/promo/qantas5000ninemsn
[AU only]

[Benjamin J. Weiss]

Post by Jeff Vian

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not
assign addresses (i.e. the subnet block does not include a range
statement).
2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been
told to assign addresses on that subnet via a range statement. Nothing
more to be done.
Too simple. <grin>
Cheers,

Your approach works, and if you have multipl;e hosts on the same subnet
being served it may be best, as well as providing the routing for them.
You also should consider the technique of assigning IP address based on
the MAC address of the requester. This technique is used to DHCP assign
static ip addresses to servers on lots of networks. There is no need to
be tied to one interface per subnet, but rather since the DHCP request
broadcast includes the MAC address of the requester (as well as the
originating network IP if routed), it can be set in the configuration
tables to specify the address to be assigned.

If I recall correctly, (and mind, I haven't seen all of this thread),
Rodolfo started his quest in another thread. He was trying to act as a
quasi-ISP for others in his building, so that they could all share the
costs of a high-speed internet line. IIRC, he wanted to be hands-off,
such that his "clients" could just plug in and deal with their own IT
issues. If he had gone with MAC-based DHCP, he'd have become their
de-facto IT/SA shop. I don't think that he wants the additional burden.
:)

Ben

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
If I recall correctly, (and mind, I haven't seen all of this thread),
Rodolfo started his quest in another thread. He was trying to act as a
quasi-ISP for others in his building, so that they could all share the
costs of a high-speed internet line. IIRC, he wanted to be hands-off,
such that his "clients" could just plug in and deal with their own IT
issues. If he had gone with MAC-based DHCP, he'd have become their
de-facto IT/SA shop. I don't think that he wants the additional burden.
:)

Spot on. <smile>

By the way, the system has been up for a week now with three subnets
(clients) connected and is working like a charm. Thanks to everyone who
either helped or tried to help!

Cheers,

[Rodolfo J. Paiz]

Post by Benjamin J. Weiss
If I recall correctly, (and mind, I haven't seen all of this thread),
Rodolfo started his quest in another thread. He was trying to act as a
quasi-ISP for others in his building, so that they could all share the
costs of a high-speed internet line. IIRC, he wanted to be hands-off,
such that his "clients" could just plug in and deal with their own IT
issues. If he had gone with MAC-based DHCP, he'd have become their
de-facto IT/SA shop. I don't think that he wants the additional burden.
:)

Spot on. <smile>

By the way, the system has been up for a week now with three subnets
(clients) connected and is working like a charm. Thanks to everyone who
either helped or tried to help!

Cheers,

[Matt .]

I didn't see the start of this thread, but here's my $0.02 ...

The DHCP server shouldn't care what interface the request came in on, rather
it looks at the source network of the request.

So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.

In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

regards,
Matt.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2

[Benjamin J. Weiss]

Post by Matt .
I didn't see the start of this thread, but here's my $0.02 ...
The DHCP server shouldn't care what interface the request came in on, rather
it looks at the source network of the request.
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.
In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route. I believe that we had to
set up our central router (a Cisco Catalyst 3550 set up to route instead
of switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

Ben

[Matt .]

Post by Matt .
I didn't see the start of this thread, but here's my $0.02 ...
The DHCP server shouldn't care what interface the request came in on,
rather

Post by Matt .
it looks at the source network of the request.
So you server could support many different ranges, provided there was
suitable separation (i.e. a router) between the subnets and the server.
In your case, the server is acting as the router, but having separate
interfaces on the server itself is not a requirement (of any DHCP server I
know of)

Okay, it's been awhile since I set up our dhcp at work, but if I remember
correctly, dhcp requests don't usually route. I believe that we had to set
up our central router (a Cisco Catalyst 3550 set up to route instead of
switch) to forward the dhcp requests to the dhcp server on our server
subnet. Otherwise we'd have had to have had a dhcp server on each subnet.

Correct. DHCP is a broadcast. Routers don't normally forward broadcasts.
Configuring the router (with "ip helper-address") causes it to send a
unicast to the chosen DHCP server. Source address in the packet allows the
server to respond with an address for the correct subnet.

Just wanted to point out that it's not necessary to have more than one NIC
in the server to support multiple subnets. Of course, if the server is
routing for those subnets then there's nothing wrong with that either.

Regards,
Matt.

_________________________________________________________________
Get a Credit Card - 60 sec online response:
http://ad.au.doubleclick.net/clk;8097459;9106288;b?http://www.anz.com/aus/promo/qantas5000ninemsn
[AU only]

[Benjamin J. Weiss]

Post by Jeff Vian

Post by Rodolfo J. Paiz
1. You *should* configure your dhcpd.conf for every subnet on
which your server has an interface even if the DHCP server does not
assign addresses (i.e. the subnet block does not include a range
statement).
2. The server will then automatically assign an address in the
correct subnet for every incoming request, assuming that it's been
told to assign addresses on that subnet via a range statement. Nothing
more to be done.
Too simple. <grin>
Cheers,

Your approach works, and if you have multipl;e hosts on the same subnet
being served it may be best, as well as providing the routing for them.
You also should consider the technique of assigning IP address based on
the MAC address of the requester. This technique is used to DHCP assign
static ip addresses to servers on lots of networks. There is no need to
be tied to one interface per subnet, but rather since the DHCP request
broadcast includes the MAC address of the requester (as well as the
originating network IP if routed), it can be set in the configuration
tables to specify the address to be assigned.

If I recall correctly, (and mind, I haven't seen all of this thread),
Rodolfo started his quest in another thread. He was trying to act as a
quasi-ISP for others in his building, so that they could all share the
costs of a high-speed internet line. IIRC, he wanted to be hands-off,
such that his "clients" could just plug in and deal with their own IT
issues. If he had gone with MAC-based DHCP, he'd have become their
de-facto IT/SA shop. I don't think that he wants the additional burden.
:)

Ben