Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: SamK on April 28, 2009, 09:28:53 am
-
Having trouble getting a working configuration for DHCP in eBox and am hoping to to get some advice. The LAN workstation does not recieve an ip address from the eBox Machine.
Router
ip address=192.168.2.1
DHCP Status=Disabled
eBox Machine
Single NIC installed=eth0
Module Status
Dashboard
Networking-->Interfaces
- eth0=Static
- 192.168.2.3
- 255.255.255.0
DHCP
- Custom Gateway=192.168.2.1
- Domain=Blank
- Custom Nameserver=192.168.2.1
- IP Address=192.168.2.3
- Subnet=192.168.2.0/24
- Available Range=192.168.2.1-192.168.2.254
All changes saved without errors
From the eBox Machine
ifconfig=192.168.2.3
ping 192.168.2.1=Successful
nslookup www.bbc.co.uk=Successful
From the LAN Workstation (Dynamic IP DHCP)
ifconfig=ip address not allocated
From the LAN Workstation (Static IP Locally Set)
ifconfig=192.168.2.108
ping 192.168.2.1=Successful
ping 192.168.2.3=Successful
nslookup www.bbc.co.uk=Successful
I've gone 'snow-blind' on this and simply cannot see the answer.
-
Please post the contents of /etc/dhcp3/dhcpd.conf
-
Please post the contents of /etc/dhcp3/dhcpd.conf
As Requested:
# extra options
# RFC3442 routes
option rfc3442-classless-static-routes code 121 = array of integer 8;
# MS routes
option ms-classless-static-routes code 249 = array of integer 8;
ddns-update-style none;
option domain-name-servers 192.168.2.1;
default-lease-time 1800;
max-lease-time 7200;
shared-network eth0 {
subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.1;
option domain-name-servers 192.168.2.1;
default-lease-time 1800;
max-lease-time 7200;
}
}
-
Hi SamK,
You just forgot to add a range or a fixed IP address mapping to your DHCP configuration. If you don't do so, the DHCP will not serve any lease.
Best,
-
You just forgot to add a range or a fixed IP address mapping to your DHCP configuration. If you don't do so, the DHCP will not serve any lease.
Hi sixstone,
I assumed that web-gui-->DHCP Available Range=192.168.2.1 - 192.168.2.254 indicated that these addresses were ready to lease out.
Having defined a range the client now obtains an address.
I wish to define two ranges and would welcome some advice on how this is best done in eBox.
Range 1
Fixed address allocated against MAC address
192.168.2.2 - 192.168.2.49
Reserved whether or not a name and MAC address is known to eBox and only issued when a name and MAC address is declared within eBox.
Is it possible to reserve a range without entering each name and address?
Range 2
Dynamic address
192.168.2.50 - 198.168.2.250
Unreserved and allocated upon request.
-
It is not necessary to set Range 1. You will need to set up the fixed addresses mapping in the table in order to let the dhcp clients in those machines get the same IP address always.
Best,
-
To help explain, what sixstone means is that when you are statically assigning addresses in the DHCP server, you don't want to have those also dynamically assigned. Since eBox is your DHCP server, it'll know that 192.168.2.2 = some machine you statically assigned an address to so it won't assign it anything else. Which means you don't have to setup a range of IPs which includes 192.168.2.2 because it'll be in your fixed-address list.
-
Hi Saturn2888
Thanks for your input
To help explain, what sixstone means is that when you are statically assigning addresses in the DHCP server, you don't want to have those also dynamically assigned.
Fully agreed.
...Which means you don't have to setup a range of IPs which includes 192.168.2.2 because it'll be in your fixed-address list.
What I wish to achieve is to reserve a block of successive fixed ip addresses. Initially the list of reserved addresses will exceed the number of leases required. From this block I can then maually allocate a name and MAC address within eBox to a device I wish to add to the network as and when the need arises.
...You will need to set up the fixed addresses mapping in the table...
I have attempted to do this but all fields require populating before they can be saved. Providing dummy information of Address=192.168.2.x Name=Unallocated and MAC=xx:xx:xx:xx:xx:xx is not allowed as the MAC address is seen by eBox as invalid.
-
My recommendation is just let it assign IPs in the 192.169.2.50+ range and then go to your dashboard and start picking out MAC addresses that show up there. Or you can do ifconfig -a or ipconfig /all on the machines which works too for finding MAC addresses. I just did it slowly over time. Anytime I get a new wireless card or wired one, I just hook it up, pull the IP, put it in the table, and it'll statically assign the IP when the lease is gone in 3600 seconds or so.
-
As an experiment the following ranges have beed added within the available range created by eBox:
Web-GUI-->DHCP
Add Range
- Name=Reserved
- From=192.168.2.4
- To=192.168.2.99
Add Range
- Name=Unreserved
- From=192.168.2.100
- To=192.168.2.250
On LAN Workstation
- ip address allocated via DHCP=192.168.2.100
QUESTIONS
01 How does eBox decide which of the ranges to allocate a lease from?
02 What is the purpose of eBox being able to create multiple ranges within a larger available range?
-
In my network, I have statically assigned (by the DHCP module) 1.1.0.0/16 network addresses. The guest IP subnet is 2.2.2.0/24. When someone connects, if their MAC address isn't already in the 1.1.0.0/16 DHCP table, then it assigns a 2.2.2.0/24 address. From my knowledge, it doesn't assign these sequentially, it does them randomly within the subnet. And also from my experience, it assigns a high-numbered address like 2.2.2.234 or 2.2.2.247 for example.
If a friend connects in, and I trust his computer, his MAC address will show up on the dashboard, I copy/paste that into the 1.1.0.0/16 network (fixed), and then I save changes. After that I can disconnect the ethernet cable or the wireless connection and reconnect it to the friend's PC/laptop, and they're in.
-
QUESTIONS
01 How does eBox decide which of the ranges to allocate a lease from?
02 What is the purpose of eBox being able to create multiple ranges within a larger available range?
I think there's some confusion here. When eBox's DHCP module is first enabled, the entire address range is "unallocated." You could assign static IPs from the entire range. The purpose of DHCP is to allow at least some client devices to have a dynamic addresses allocated as needed. So out of the entire range of available addresses a DHCP range or dynamically available range of addresses is set aside. Any address outside the DHCP/dynamic range may still be assigned statically.
So with that, the questions, but in reverse order:
02 I'm not sure what the purpose is, unless it's meant as a flexibility feature (perhaps a single eBox can allocate addresses from different subnets?). Having two or more DHCP ranges seems to me to be unnecessary in most cases. A single block of addresses big enough to accommodate the number of possible devices works well.
01 Again, I don't know how this might work, because I'm not sure what purpose the capability serves. But for the task of replacing a single router, you need to assign only one DHCP/dynamic address range. All addresses outside that range are by definition unallocated and can be assigned statically as needed.
EDIT: A case where you might want to have some addresses available for static assignment: A wireless access point. Assigning the access point a static address means you always know where to find it. Another might be a network device you want to give special treatment, like an Xbox. So while it's possible to put an entire subnet into a DHCP range, if it's not necessary to do so, it's better to have some unallocated (from the DHCP server's point of view) addresses available for these types of purposes.
-
Hi Sam Graf,
...you need to assign only one DHCP/dynamic address range. All addresses outside that range are by definition unallocated and can be assigned statically as needed.
I understand and fully agree with this point. It is likely to be the method I adopt.
In general I attempt to remember as little as necessary, hence the naming of the ranges in the experiment previously mentioned. The address allocated to the LAN workstation was from the 2nd group (addresses 100 upwards). I am attempting to establish if this was a coincidence, or by design on the part of eBox.
Does having 2 ranges within a single larger range allow eBox to only dynamically allocate addresses from this second group, effectively ignoring the 1st range? If this is the case (either by accident or design), creating the two groups assists in my desire to remember as little as needed and provides an aid to quickly identifying the nature of the address. It might be that a member of the eBox staff is able to provide the confirmation of its behviour.
Ultimately it is not strictly needed but is something I have used in the past and find very useful.
Many thanks for your input.
-
SamK, the reason you can assign multiple address blocks is because you can DHCP 10.10.5.1- to .15 and then have static addresses from .16 to .20, then have dynamic addresses from .21 on up. See?
And I think sixstone is sleeping so you'll have to wait on your answer for how DHCP works.
-
Hi
In general I attempt to remember as little as necessary, hence the naming of the ranges in the experiment previously mentioned. The address allocated to the LAN workstation was from the 2nd group (addresses 100 upwards). I am attempting to establish if this was a coincidence, or by design on the part of eBox.
ISC DHCP daemon has no specification about which range to take if there are more than one. So this behaviour may be a coincidence or not.
SamK, the reason you can assign multiple address blocks is because you can DHCP 10.10.5.1- to .15 and then have static addresses from .16 to .20, then have dynamic addresses from .21 on up. See?
And I think sixstone is sleeping so you'll have to wait on your answer for how DHCP works.
SamK, Saturn2888 got the point to add more than one range. Only applicable if you want more flexibility about your ranges.
And Saturn2888, I was offline which does not mean I was sleeping like a log :D
Best,
-
A final point related to this...
At the of the first post in this thread, reaching the eBox web-GUI from a remote machine was problematical. To address this a lightweight GUI was locally installed.
Window Manager=Openbox
Various components of LXDE
Web Browser=Firefox
When the static ip address is allocated from the router the web can be browsed from the eBox machine in the usual manner. When the same static ip address is allocated from eBox the web cannot be browsed. A page load error is generated and Firefox is unable to establish a connection.
Is eBox preventing this in some way? The eBox firewall is currently disabled. nslookup of an external address is successful.
-
If this is the case (either by accident or design), creating the two groups assists in my desire to remember as little as needed and provides an aid to quickly identifying the nature of the address.
The range naming convention doesn't make it out to the client end, of course, so out there, you have to remember where the address came from.
During my Linksys "blue box" years I developed that habit of leaving the DHCP range in the "middle" of the address space, following the lead of the default range. Then I would use the unallocated addresses below the DHCP for one purpose and the addresses above for another, effectively slicing my address pie into three pieces. Since the router was x.x.x.1, I just adopted the procedure of keeping all network hardware below the DHCP range (e.g., access points). Above the DHCP range I'd stick stuff like NAS devices. The only thing I had to remember was the DHCP range, and there I just extended the Linksys default DHCP range in one direction when necessary by the size of the original default range -- 50 addresses. It all made sense to me. :)
This all happened to work well when we first deployed Linksys VPN routers and it became impractical to rely on NetBIOS names. It was (or at least seemed) easier to remember where things were since it was almost certain that the only interesting piece of the pie to a road warrior was the piece above the DHCP range. A critical user device such as a fileserver would get the first address above the DHCP range.
I tell all this just to illustrate how even a single DHCP block can still leave the subnet's address space "organized" into three "easy-to-remember" blocks of usable addresses.
eBox changes things a little in that you can set up a static address at the server/router end rather than at the client end. I love that feature!
-
Short version:
You need to assign a Gateway address for your eBox. Make it whatever the eBox IP is 192.168.2.1 I'm guessing. Don't forget to make a local DNS server too if you want.
-
When the static ip address is allocated from the router the web can be browsed from the eBox machine in the usual manner. When the same static ip address is allocated from eBox the web cannot be browsed.
A couple of things: You're using just one DHCP server at a time, correct? Either the router or the eBox, but not both. (EDIT and note: eBox will pick up the gateway address if the external NIC is getting it's address via DHCP.)
The second thing is from memory, and from my first fuzzy days with eBox at that. As I recall, if you've ever enabled the firewall module, you must have opened port 80 even if the firewall module is subsequently disabled. In other words, if port 80 wasn't open at the time the firewall module was disabled, HTTP traffic will still be blocked. The firewall rules in effect when the module was disabled still apply. That's my recollection.
-
You're thinking the wrong gateway. There's one inside and one outside. The inside gateway is what let's the people behind the eBox connect to the outside. If the eBox address is 192.168.2.1, the gateway address is the same. That's the only reason the inside people can't get out.
-
...leaving the DHCP range in the "middle" of the address space, following the lead of the default range. Then I would use the unallocated addresses below the DHCP for one purpose and the addresses above for another, effectively slicing my address pie into three pieces.
This is a very neat extention of what I wanted to achieve, but is only available as a product of the imaginative use of the unallocated address space. I wonder if it might be improved further?
Currently eBox allows the specification of a block of addresses that can be dynamically allocated via DHCP where the block exceeds the number of addresses presently required. It does not allow a static address to be created within a pre-specified block where the block is greater than the number of addresses currently required. If eBox allowed the specification of different types of blocks that incorporated unallocated addresses, (both dynamic and static), the eBox interface would become more 'self-documenting' and thereby more user friendly. Using your example it would be possible for the eBox DHCP interface to show the following:
RANGES
Name From To
Actives - Fixed x.x.x.2 x.x.x.30
Dynamically Allocated x.x.x.50 x.x.x.150
Servers - Fixed x.x.x.230 x.x.x.250
I have no idea what might be involved in making a change such a this but am in favour of 'self-documenting' and therefore see this as a desireble development. I am considering suggesting it via the Feature Request system and would like to refer to your post describing the way in which it was previously used. Is this OK with you?
Apr 29 - Edited by SAMK in an attempt to clarify ambiguities.
-
This functionality already exists. Now I'm really confused.
-
This functionality already exists. Now I'm really confused.
Can you show how to specify a range of static ip addresses where the range exceeds the number of addresses to be allocated at the moment? Some of the specified range will remain unallocated currently and some of the range will be allocated.
e.g.
range=x.x.x.2 - x.x.x.30
number of leases required=17
-
Here's what mine looks like. You can see, I have no guests connected as of right now.
-
This functionality already exists. Now I'm really confused.
On reading the post again I can see where it was ambiguously worded and edited it in an attempt to clarify it. Due to cross posting I have not studieed your screen shots yet.
-
In my image dhcp-page1.png, there is no range specified, only fixed addresses.
-
Well, those are shots from my working eBox. Aren't you the one that wanted to see them?
-
Your idea to use screenshots is a good one. I am having trouble getting mine to display. I place the path and filename (jpg) between the image tags but they do not show. What am I missing? Any suggestions?
-
I don't use IMG tags. If you click the "Additional Options" dropdown, it let's you attach them.
-
Do these help? The idea is to pre-define the groups for both static and dynamic addresses. Dummy data has been used to create the screen shots and then edited to show where the difficulty lies.
-
If it's fixed, you don't have to put it under the "Ranges" section, you're supposed to leave it blanked like in my photos. Look at dhcp-page1. Notice how there is nothing in the Range, but there are fixed addresses. Does that help?
-
If it's fixed, you don't have to put it under the "Ranges" section...
I understand this point, and as I mentioned in a previous post in the thread my idea is not neccessary to use eBox. I find it a more intuitive way of working and therefore am more comfortable with it.
I have used a variation of the idea in the past. In an earlier post Sam Graf described the way in which he has used the idea previously, all of which which leads me to conclude that it might be used by a sufficient number of people to suggest it to the eBox staff for consideration.
From my non-programmers perspective all that is required is for eBox not to assume (as is does currently) that a pre-defined block of addresses is only for dynamic allocation. I have no idea how much work this represents but I do recognise how desirable the feature might be.
-
Ah. I dunno how that would work but okay.
-
Ah. I dunno how that would work but okay.
I will wait for a while before I do anything further about this idea. This will give Sam Graf the opportunity to comment as he has contributed to the thread. If anyone at eBox has been following this they might advise whether there is/is no need to raise it in the Feature Requests Section.
Now to re-read the posts about using a web browser from the eBox machine.
-
To summarize the earlier posts
At the time of the first post in this thread, reaching the eBox web-GUI from a remote machine was problematical. To address this a lightweight GUI was locally installed.
Window Manager=Openbox
Various components of LXDE
Web Browser=Firefox
When the static ip address is allocated from the router the web can be browsed from the eBox machine in the usual manner. When the same static ip address is allocated from eBox the web cannot be browsed. A page load error is generated and Firefox is unable to establish a connection.
Is eBox preventing this in some way? The eBox firewall is currently disabled. nslookup of an external address is successful.
You're using just one DHCP server at a time, correct?
Correct the router DHCP is disabled, eBox DHCP is enabled.
As I recall, if you've ever enabled the firewall module...
This module has not been enabled on this installation.
Short version:
You need to assign a Gateway address for your eBox. Make it whatever the eBox IP is 192.168.2.1 I'm guessing. Don't forget to make a local DNS server too if you want.
Was this not done when setting up DHCP as shown in the attached screenshot? A Primary Nameserver was specified with the ip address of the router and resolving of names on the WAN works OK using nslookup. A Default Gateway Custom IP Address was also specified as the router ip address. If the nameserver element works why not the gateway element?
-
Where to start...
In the case of the DHCP server, the default gateway to the external world should be "eBox." The correct entry for the name server is more complicated. If you have the DNS module enabled (even if you have no domain names), I believe DNS caching happens (I think I read that somewhere) and "local eBox DNS" would be the correct choice. If not, then the name server(s) assigned by the ISP should be used, not eBox's address.
It's not clear to me at the moment why a DNS lookup is working but not Web access. I'll have to think about this more.
On the DHCP address ranges: We have to look at this from the DHCP server's point of view, not the point of view of the address space or our use of it. When the DHCP module is first enabled, the DHCP server has no addresses to allocate (allocate dynamically -- the only way a DHCP server can allocate addresses). Devices attached to an eBox in this state will get no address assigned, and this is the way it should work.
We have to give the DHCP server permission, in effect, to use some portion (or portions) of the address space by assigning one or more address ranges to it. The size of the range(s) and the start and end points are arbitrary (with the exception that we should not use x.x.x.0 or x.x.x.255 for any purpose, dynamic or fixed). Any address outside the DHCP range(s) is still a valid address, except that we have to assign it manually and "permanently," making it a static assignment rather than a dynamic -- DHCP -- assignment.
From the DHCP server's point of view, there is no such thing as a statically assigned address in any address range it has been given permission to use. If my DHCP range is 192.168.1.100-149, I cannot statically assign 192.168.1.100 to my Xbox. That address has been granted to the DHCP server for dynamic use. So correctly speaking, there can be no "fixed" address ranges under the DHCP's server's control. By definition, all DHCP (Dynamic Host Configuration Protocol) address ranges are not static or fixed assignments. The assignments come and go as needed.
That's the purpose of DHCP in fact, to allow people to attach to a TCP/IP network without having to assign their equipment an address manually. Imagine what it would be like at WiFi hotspots if there were no such thing as DHCP: every device would have to be assigned an address manually, and that assignment would have to be removed manually at the end of a session. The idea of fixed addresses in a DHCP range really is foreign to the intent of DHCP.
At this point eBox potentially creates some confusion, IMHO, by including the fixed address assignments functionality within the DHCP context. The fixed addresses may be being handled on Ubuntu server's technical level by its DHCP component (I don't know), but they are entirely separate ideas. It is convenient to have the DHCP address range(s) in front of you as you assign fixed addresses, but it could still be confusing.
Strictly speaking, we need to think of the DHCP server as seeing only addresses we've given it permission to use as it sees fit. If we want some portion of the address space to be available for static/fixed assignment, that address space should not be thought of as a DHCP range. So in that sense, eBox works exactly as I would expect it to work as a DHCP server. Any change would break it, I think.
Since it's not clear to me, practically speaking, why I would ever want to have multiple DHCP ranges in a single subnet, I can't say how eBox's ability to do so would aid in keeping the use of the address space tidy and easy to remember. To me, without a compelling reason to fragment the DHCP server's address space it would only be confusing to do so.
-
Was this not done when setting up DHCP as shown in the attached screenshot? A Primary Nameserver was specified with the ip address of the router and resolving of names on the WAN works OK using nslookup. A Default Gateway Custom IP Address was also specified as the router ip address. If the nameserver element works why not the gateway element?
Yeah whoops. My bad. I used to have it setup like that, but for whatever reason I changed it. If you type it in manually that is just another way to check if that is the issue.
A good way to check if things are working is to ping your ISP from SSH in your eBox. If your eBox has no Internet, well nothing else will. Please show me how you have your network setup.
-
On the DHCP address ranges: We have to look at this from the DHCP server's point of view, not the point of view of the address space or our use of it. ...
...
...without a compelling reason to fragment the DHCP server's address space it would only be confusing to do so.
Sam Graf
Many thanks for a comprehensive, cogent analysis, presented in a most understandable manner.
In view of the advice received from all contributors, I am persuaded that the simplest approach is the best to take. I am grateful to everyone who has taken the time to share their expertise.
-
No problem. Enjoy.
-
A good way to check if things are working is to ping your ISP from SSH in your eBox.
From a LAN Workstation
IP Address=allocated by eBox DHCP
Ping Router LAN address=Successful
Ping Router WAN address=Successful
Ping ISP=Successful
nslookup=Successful
Web Browsing=Successful
From eBox Machine
IP Address=static
DHCP=setup as per attached screenshot
Firewall=Disabled
DNS=Disabled
Ping Router LAN address=Successful
Ping Router WAN address=Fail
Ping ISP=Fail
nslookup=Successful
Web Browsing=Fail
Please show me how you have your network setup.
What information are you looking for?
-
You can change both the default gateway and the primary nameserver to the "eBox" option.
-
You can change both the default gateway and the primary nameserver to the "eBox" option.
Default Gateway=eBox Result=No Change in symptoms
Primary Nameserver=None Result=No Change in symptoms
Primary Nameserver=eBox Result=Unable to save changes Error='Must enable eBox DNS'
Settings returned to screenshot values.
Checked the router and MAC Address Filtering=Disabled
Is eBox creating a DNS cache of addresses resolved via the router?
What is the command line to flush the DNS?
-
There should be no router between eBox and the modem if this is to work correctly, so I'm a little confused as to where we're at. We want one DHCP server on the LAN (eBox), we want the modem (via another DHCP mechanism outside eBox on the WAN side) to assign an address to the "external" NIC in the eBox. And if we can get it, we want one NAT between the LAN and the outside world (again, eBox).
-
I think SamK's eBox only has one NIC.
-
Ah, that makes sense. I don't think eBox (or any other router for that matter) can route Internet connection traffic without at least two interfaces, one on the WAN side and one on the LAN side.
-
But the box itself should be able to access the Internet. I'm really curious how this setup looks. I'd love a visual.
For me it's:
Internet > ISP > Modem > Switch > eBox WAN (redundant links) > eBox LAN > Switch > Home Network which includes a BUNCH of stuff.
-
Except that we're complicating things unnecessarily, I think, by trying to get a single NIC eBox to route external traffic via DHCP. It's a little confusing to me exactly what we're trying to accomplish. I misread the effort to move DHCP to the eBox as an attempt to replace the router (which would be my purpose), and that hasn't helped.
I'd do the ISP > Modem > Switch > thing only in cases where I had multiple LAN segments using a common Internet connection, or maybe in the case of multiple static public IPs. In all my eBox configurations I'm doing ISP > Modem > eBox > LAN. I've got the modem passing its public address to eBox, to avoid multiple NATs between the LAN and the world. At work that's not critical to my eBox trial, but at home it matters because of Xbox Live :) .
-
The reason I do that w/ the switch is because I can pull multiple IPs so if a NIC goes down I don't lose connection bc I have another pullin' another public IP. It's exactly the same as what you have.
-
But the box itself should be able to access the Internet. I'm really curious how this setup looks. I'd love a visual.
For me it's:
Internet > ISP > Modem > Switch > eBox WAN (redundant links) > eBox LAN > Switch > Home Network which includes a BUNCH of stuff.
Representative diagram attached. This is a working LAN and while I am willing to experiment it must be capable of quickly being returned to a working condition.
@Sam Graf
My original idea was to leave the combined router/switch in situ and use the inbuilt firewall to protect the LAN. The router/switch feeds multiple LAN devices, switches, printers, pcs and servers. I was looking to place eBoxes inside the router/switch-firewall to conduct DHCP, PDC Authentication, Shares, LAN DNS etc. If possible this is the model I would like eBox to work within.
I've been caught by cross-posting and need to catch up with recent posts.
-
Wherever it sits, if eBox is going to serve as a gateway for a LAN, I think it will have to have two NICs, an "external" interface (which need not be hooked directly to the modem) and an "internal" interface, which will serve the LAN "below" it. The external interface handles all traffic between the Internet and eBox itself and the LAN. All local, LAN traffic will be handled on the internal interface, including DHCP address management.
-
I know you can't change it right now, but ideally, this is what you want:
If you want eBox to connect to the Internet as you have it right now (not in my image), set the gateway address as the address of that gigabit switch. See what happens.
-
I know you can't change it right now, but ideally, this is what you want:
If you want eBox to connect to the Internet as you have it right now (not in my image), set the gateway address as the address of that gigabit switch. See what happens.
This is what I have been attempting to do earlier today (see most recent DHCP setup screenshot) using the LAN address of the router/switch 192.168.2.1. This is not yet successful but seems an attractive course at this stage.
It was never one of my aims to use eBox as a gateway for the LAN, although I can see the benefits of doing so. It seems to have assumed an increasing priority as our discussions have progressed. If a working setup can be established which does not use eBox as a gateway (as per your diagram) I will be quite happy with that.
-
Yeah? Well I'm sure we can make that work. What's the eBox IP and what's the router's IP?
-
I'm confused.
Any device that attempts to use an eBox-assigned address to connect with the Internet is going to try to use eBox as a gateway. That's what a gateway (http://en.wikipedia.org/wiki/Residential_gateway) is and does, connecting an internal address with the public address so the device can reach the outside world without an outside address statically assigned. If we don't first set up the eBox as a gateway, I don't see in the diagram what device we're expecting to provide NAT between eBox-assigned addresses and the public IP.
Consider the typical router, where there are at least two interfaces, a WAN interface (where a modem is often plugged in) and a LAN interface (where all the stuff in the building gets plugged in). NATs and firewalls use the physical distinction between these interfaces to do their work. I'm suggesting (among other things) that until an eBox is set up like a router, it can't function as a gateway -- that is, no devices managed by eBox DHCP will be able to reach the outside world, since there is no way for the "real" gateway to know that a device at address x.x.x.x even exists, let alone that it's requesting access to the outside world, and there is no way for eBox (including its firewall) to distinguish between the inside and the outside world on a single interface.
So that's the gist of my confusion. I'm going to just watch for a bit and maybe I'll learn something. :)
-
All that has to be done is set the router, not the eBox, as the gateway in the DHCP server, done. Some places just have a DHCP server as a separate box. This is how things work.
-
Off Topic
The router/switch is a multi-function device which provides many of the functions offered by eBox (DHCP, NTP, QoS, NAT, Access Control, URL Blocking, DoS, DDNS, Port Forwarding, DMZ, etc.) It is the intention at this stage to use some of these functions via the router/switch and some via eBox.
At the present time eBox is not to be the central control mechanism for the network, rather it is to be part of it, using whatever portions of its functionality are required.
The appeal to me is the opportunity to standardize the build of server boxes that eBox presents, its integration, unified management, and the ability to switch on/off the functionality which is installed, as standard, in all deployed eBoxes. This may change in the future as demands on the system change; eBox may grow to become the central mechanism through which the network is managed and controlled.
The enjoyment of exploring how eBox might be used towards this end may have allowed wanderering from the shortest path to the objective, and thereby led to some confusion. Is exploration meant to be an exercise in finding the shortest path?
On Topic
#1
The initial experiment showed that resolution of WAN names/addresses can remain a function of the router/switch while eBox conducts resolution of LAN based names/addresses. It was not the intention to set up an externally registered domain name.
#2
The second experiment was to explore transferring DHCP from the router/switch to an eBox. This initially proved problematical and as part of the trouble shooting a lightweight GUI and a web browser were installed on the test eBox machine. When it was determined how DHCP could be transferred successfully (i.e the experiment successfully concluded) it left an interesting, unanswered question which was not one of the original goals of the experiment. It is this non-essential element that is now being explored (experiment three)
#3
Establish why the GUI/web browser installed on a test eBox (created in #2) is unable to browse the web successfully when DHCP is enabled on the eBox machine. How is this rectified? When the LAN workstations are allocated an ip address via DHCP on the router/switch browsing the web from the eBox is successful.
-
#3
Establish why the GUI/web browser installed on a test eBox (created in #2) is unable to browse the web successfully when DHCP is enabled on the eBox machine. How is this rectified? When the LAN workstations are allocated an ip address via DHCP on the router/switch browsing the web from the eBox is successful.
All that has to be done is set the router, not the eBox, as the gateway in the DHCP server, done. Some places just have a DHCP server as a separate box. This is how things work.
This is why I have been attempting to set the eBox DHCP default gateway as the ip address of the router/switch.
eBox DHCP provides provides various configuration options:
- eBox
- Custom (together with a field to specify the address)
- None
- Configured Ones
Each was tried in turn without success.
- None as a choice was obviously incorrect
- Configured Ones seemed unlikely as none had been set up in eBox
- eBox seemed a possibility
- Custom was exactly the option required
It was and is unclear what the difference is between 'Custom' and 'Configured Ones' but I decided to configure one which pointed to the router/switch and try the 'Configured Ones' option as the 'Custom' option was unsuccessful.
Having set up the gateway, and before selecting the 'Configured Ones' option, (i.e. the 'Custom' option is selected) browsing started to work as expected and ping beyond the LAN address of the router is also successful.
Can anyone explain why eBox provides the 'Custom' option in DHCP which allows an existing address to be specified but does not use it until a gateway is created in Network-->Gateways by specifying exactly the same information again?
Having created the gateway would it not also be used if the 'Configured Ones' option is selected in eBox DHCP? Tests reveal the answer is yes.
Am I missing something which is obvious to others? It does appear odd to my eyes.
-
Can anyone explain why eBox provides the 'Custom' option in DHCP which allows an existing address to be specified but does not use it until a gateway is created in Network-->Gateways by specifying exactly the same information again?
Having created the gateway would it not also be used if the 'Configured Ones' option is selected in eBox DHCP? Tests reveal the answer is yes.
Am I missing something which is obvious to others? It does appear odd to my eyes.
Hi SamK,
I'll try to give you a simple answer that may help you. eBox DHCP server may be put in several places within your local network.
- A separate box: in that case eBox is not set as gateway, so you must configure the gateway which DHCP clients must connect to browse Internet. You may set it as Configured one (if you have already set that gateway for other user, trafficshaping or multigateway rules) or a custom one (in that case you just want eBox to be a simple box for DHCP server). Normally, that box where eBox is installed would have a single NIC (Ethernet cable).
- Your gateway: in that case eBox has, at least, two NICs. One set as internal (to your LAN) and one set as external (to your WAN). As eBox is the gateway, you will set in your DHCP server eBox as gateway where LAN DHCP clients connect to. Furthermore, eBox must have firewall module enabled in order to do NAT and packet forwarding likewise a router does.
I hope I have clarified a little the options you have.
-
Thanks for the information sixstone. Two points arise from this.
- A separate box: in that case eBox is not set as gateway, so you must configure the gateway which DHCP clients must connect to browse Internet...
eBox DHCP was set up on the test server. This used a Default Gateway='Custom' and specified the ip address of the router. At this point, a gateway had not been created in Network-->Gateways. A test LAN Workstation successfully received an ip address from the eBox DHCP and was able to access the internet in the usual manner.
QUESTION 1
How is it that the LAN workstations (with dynamically allocated IP addresses from eBox DHCP) were able to web browse successfully but the eBox itself (with a static address) could not? No gateway had been defined at this stage.
For a Default Gateway='Custom' (together with a specified the ip address) to function eBox requires the ip address to again be specified and saved in Network-->Gateways.
QUESTION 2
Is it not possible for eBox to to create the 'Custom' gateway using the information provided when setting up eBox DHCP? It would be more user friendly done in this way.
-
QUESTION 1
How is it that the LAN workstations (with dynamically allocated IP addresses from eBox DHCP) were able to web browse successfully but the eBox itself (with a static address) could not? No gateway had been defined at this stage.
Because you haven't configured your default gateway for eBox. You must set one at Network -> Gateways, ticking Default setting. If it is the same one that your DHCP clients then you may choose Configured one option in DHCP server.
For a Default Gateway='Custom' (together with a specified the ip address) to function eBox requires the ip address to again be specified and saved in Network-->Gateways.
QUESTION 2
Is it not possible for eBox to to create the 'Custom' gateway using the information provided when setting up eBox DHCP? It would be more user friendly done in this way.
I think the other around is more user friendly since your host always has a default gateway to route its packets and there is not always a configured DHCP server in eBox. For me, it is confusing to do so.
Best regards,
-
- A separate box: ... (in that case you just want eBox to be a simple box for DHCP server)...
In this case, are the eBox DHCP clients behind the eBox firewall?
-
- A separate box: ... (in that case you just want eBox to be a simple box for DHCP server)...
In this case, are the eBox DHCP clients behind the eBox firewall?
No, they aren't. They are under the gateway you set previously as default gateway.
-
Because you haven't configured your default gateway for eBox. You must set one at Network -> Gateways, ticking Default setting. If it is the same one that your DHCP clients then you may choose Configured one option in DHCP server.
Just checking here that I understand.
The LAN Workstations are able to browse the web because they are DHCP clients and are aware of the gateway address which is specified in eBox-->DHCP-->Default Gateway='Custom'. The ebox itself is not a DHCP client as it has a static address and therefore is unaware of whatever gateway is specified in DHCP. For this reason the eBox requires a gateway to be specified in Network-->Gateways.
Is this correct?
I think the other around is more user friendly since your host always has a default gateway to route its packets and there is not always a configured DHCP server in eBox. For me, it is confusing to do so.
I can accept that. Would it be more intuitive if the eBox-->DHCP-->Default Gateway='Custom' option was 'greyed-out' (unavailable) until a gateway has been defined in Network-->Gateways? The 'Custom' gateway cannot be used until it has been setup. It might be less ambiguous.
-
"No, they aren't."
As I thought. But I've managed to get my self pretty thoroughly confused about what it is we're trying to accomplish, so I better leave it at that.
I did learn that eBox can provide simple DHCP services. If/when someone who gets this has the time, I'd like to understand better the benefits of a simple DHCP server in light of APIPA and the address range reserved for that purpose. Thanks. :)
-
@Sam Graf,
Sam, it was good to meet you, thanks for your input to my requests. Perhaps I can confuse you some more as I continue to explore eBox. Overall I am quite satisfied that I have the information I was looking for on this matter.
-
Well, I'm glad you got to where you wanted to get. As for me getting confused along the way, I take full responsibility. :)
eBox is proving to be a lot of fun. I'm along for the ride, whatever happens.
-
@SamK
Make sure, once you configured the Gateway as 192.168.2.1, you go into your DHCP server and instead of choosing "Custom", choose "Configured Ones" and select the one you just setup in there earlier today.
That is JUST IN CASE you change your gateway's IP. If you do change it, you have to change it in eBox too right? Well now you don't have to change it in your DHCP server, you just change it in the Gateway area only. It is one less place to change it. That is what sixstone meant.
-
Make sure, once you configured the Gateway as 192.168.2.1, you go into your DHCP server and instead of choosing "Custom", choose "Configured Ones" and select the one you just setup in there earlier today.
Already done, but thanks for the reminder.
Other than the two questions I posed in Reply #62 to sixstone i think we are done with this thread. I will monitor it for a short time to see if he wants to respond.
@Saturn2888
I hope we can meet in a future thread.
-
Guys,
a pointer that may help answer all the questions being asked here.
http://www.daemon-systems.org/man/dhcpd.conf.5.html
There are ways of doing most of the stuff I have seen discussed here. and an answer to my questions about DHCP and other services. on the same site are some other useful DHCP and DNS documents.
Also for those looking for good references,
http://docstore.mik.ua/orelly/ and http://docstore.mik.ua
I don't know that they are legal, but it is truly impressive what is available there.
-jeff
-
I can say for one, if you live in the US, probably not legal here.
-
http://www.daemon-systems.org/man/dhcpd.conf.5.html
There are ways of doing most of the stuff I have seen discussed here. and an answer to my questions about DHCP and other services. on the same site are some other useful DHCP and DNS documents.
Just to add to this for users new to Linux...
When installing a package (application) In Ubuntu it is usual for the installation process to place a copy of the manual on the local machine. This can be accessed in a terminal window. Try the following:
man dhcpd.conf
It might prove helpful if troubleshooting problems when an internet connection is unavailable.
-
Hey SamK, there are some quotes of me from you in this thread with my name in them, would you mind cleaning those up so it's just my username please? Since PMs are disabled I have to publicize it I guess.
-
Hey SamK, there are some quotes of me from you in this thread with my name in them, would you mind cleaning those up so it's just my username please?
Happy to oblige. It's a long thread containing quite a few instances of your name, I hope I got them all.
-
Thanks buddy! I wish the PM system was back up, haha.