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.