Running a DHCP on the gateway is bad for many reasons.

The default DHCP daemon was vulnerable to shellshock because it uses environment variables.

Address exhaustion attacks by a malicious workstation can disrupt other workstations even if they are on different internal networks because they share the same server. Unfortunately this is a protocol deficiency and is not going away anytime soon.

KVM supports giving each internal network its own simplified dhcp server and address range.

Won't become a standard feature. Optional. Anything that works for data center support.

From what I see DHCP servers have their own DNS resolver set by default and pass queries recursively upstream if they cannot answer it for whatever reason.

https://en.wikipedia.org/wiki/Domain_Name_System

such a user will either have configured that server's address manually or allowed DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained name servers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not.

https://libvirt.org/formatnetwork.html

The name attribute on the domain element defines the DNS domain of the DHCP server. This element is optional, and is only used for those networks with a <forward> mode of "nat" or "route" (or an isolated network with no <forward> element). Since 0.4.5

If the optional localOnly attribute on the domain element is "yes", then DNS requests under this domain will only be resolved by the virtual network's own DNS server - they will not be forwarded to the host's upstream DNS server. If localOnly is "no", and by default, unresolved requests will be forwarded. Since 1.2.12

This is a huge task. Reading all the protocol and protocol extensions.
Plus DHCP server documentation and possibly source code.

If someone wants to help with this...

1. get an overview of available DHCP servers in Debian
2. pick the more minimal ones
3. ask the developers of the DHCP server if they work or can be

configured to work with Whonix's threat model [1] [2]

[1] No IP discovery from the workstation, no clearnet DNS leaks.
[2] be simple as in only provide IP addressed to workstations that
connect, no other fancy features

The DHCP functionality in Libvirt can be customized to stop that harmful behavior as documented. A generic DHCP package will run into the problems described here however.

At least now we know what the limitations are.

Why do we insist on running the server on the GW? It will always increase attack surface. Alternatively I think its fine if it runs on Workstation-zero where other new cloned WSs on the internal network can bootstrap from.

pydhcplib is the best choice for client/server combo because its memory safe.

Alternatively I think its fine if it runs on Workstation-zero where other new cloned WSs on the internal network can bootstrap from.

I don't understand?

Why do we insist on running the server on the GW? It will always

increase attack surface.

Good question. Has long not been reconsidered. In past perhaps because
of physical isolation, but that would not count anymore nowadays.

Virtualizer specific. Some comments here:

https://github.com/Whonix/whonix-gw-network-conf/blob/master/etc/network/interfaces.d/30_non-qubes-whonix

• VirtualBox: as per comments, seams doable.
• KVM: no idea
• Qubes: does not need this

So if I make it work for VirtualBox, I wouldn't know if the same config
would work for KVM. In case of VirtualBox, I don't remember if it caused
conflicts with real LAN, other VMs or cloned Whonix-Gateways.

pydhcplib is the best choice for client/server combo because its memory safe.

Yes, memory safe language would be nice. However, that's a lib, not a
binary. If you can make it work, we can consider it.

There is the original WS with IP 10.152.152.11. Why not turn it into a DHCP server for any new clones added to the internal network?

A clone when it boots up checks for DHCP requests and disables its own server copy if it detects and sets a dynamic IP.

I don't remember if it caused conflicts with real LAN, other VMs or cloned Whonix-Gateways.

What kind of conflicts? Could you fool the Gateway filtering rules with spoofed IPs?

However, that's a lib, not a binary. If you can make it work, we can consider it.

I'll look into it.

I messed that up. My last comment T239#10445 was an answer for T559 - please scratch my last comment.

Moving the DHCP server to another place than Whonix-Gateway, one that doesn't know its own real external IP address, is a good idea.

There are some challenges:

• How does the original Whonix-Workstation know it is the original Whonix-Workstation and not number two or a clone?
• I am not yet convinced, that a Whonix-Workstation as currently defined is a proper place for that. That is kinda a strange idea.

Imagine a data center. Many workstations, many wires to Whonix-Gateway. How would they connect to the master workstation for DHCP? That seems strange.

Perhaps for data center support, two gateway would be better. A Whonix-Workstation -> Whonix-DHCP-Server -> Whonix-Gateway.

So a Whonix-Workstation master that runs a DHCP server would not really work for data center support. It's still an interesting for VirtualBox / KVM.

How does the original Whonix-Workstation know it is the original Whonix-Workstation and not number two or a clone?

Good question. The way this happens is pydhcp listens to the network to see if there are any DHCP packets broadcasted and parses it. If it does not detect anything (in case of master WS) it assumes the role of the server and starts broadcasting. The good thing about this is network DHCP server is auto-replaced if master WS goes down for any reason. There should be a sufficiently long interval for checking to allow a comfortable race condition.

When subordinate WSs detect DHCP packets they immediately override the hardcoded static IP and only keep client functionality on.

I am not yet convinced, that a Whonix-Workstation as currently defined is a proper place for that. That is kinda a strange idea.

Its not unreasonable given that enabling DHCP for internal networks means DNSMASQ instance on the host is used to communicate with high risk VMs. My goal is fix usability problems while not risking anything more than we have to.

IMO though the multi WS behind a GW is not as critical a usecase because one must assume that these VMs are of the same trust level which would not justify the extra resources needed to spin them up. - might as well use the same WS then. The proper way is to have different GW-WS pairs to isolate activities. So I don't think this particular ticket is a good investment of time if its difficult.

Imagine a data center. Many workstations, many wires to Whonix-Gateway. How would they connect to the master workstation for DHCP? That seems strange.

It could work for physical isolation builds supposing they are wired to the same switch (equivalent of an internal net I guess)

From my tests in the other ticket:

Tested that multiple GWs using the same static ip works. No documentation changes needed for that.

Since this is true for the external net then multiple identical static ips on inet should work without conflicting too (without DHCP support at all). The reason multi-WS isn't working has something to do with cpfp limitations in answering multiple WS requests I think.

Tests confirm that TBB on multi-WSs work without changing the static IP. Timesync on both VMs finishes successfully. TPO check reports the same IP in both TBB instances. The problems I see is Tor Button is confused and reports Tor is not working and New identity sometimes hangs with a "cannot connect to controlport to change IP"

I don't know. May work. Sounds rather difficult. At the moment I cannot even think this through. data center support currently is no focus to me. No prospective sponsor for this at the moment. And we don't have anyone who would actually implement this anyhow at the moment.

If someone wanted data center support, I'd probably also not implement this one and rather go for Qubes-Whonix. That seems a lot more manageable for data center support. It can service many ws behind the same gw without need for any dhcp. And it has qrexec, a service service that allows to easily and securely copy around files from one VM to another. And allows to run commands inside a VM, invoked from outside a VM. All controlled by policy which VM can control which other VM.

A data center that wanted to provide custom Tor hidden services for clients had various options available to script this.

DHCP support would have been interesting to more easily support multi ws behind same gw. (T567) But since the increased attack surface, probably a better solution has to be found to simplify this. Would perhaps not be that hard. Just each ws needs a unique IP. That must be doable somehow. We could just go for a random IP and hope that is not used by another ws. Or ask the user for a unique number for the VM in a specific range and then automatically adjust it. Worth another ticket.

In T239#10619, @HulaHoop wrote:

The reason multi-WS isn't working has something to do with cpfp limitations in answering multiple WS requests I think.

It should be perfectly capable to do this. If not, there is very good chance it will in Whonix 14.

For the record:

Fact. AFL uncovered many serious 0days in the DHCP server reference implementation.

isc-dhcp

https://www.cvedetails.com/vulnerability-list.php?vendor_id=64&product_id=17706&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=19&sha=962c7d6b1c11cc74fc9698948983fb909135a10f

Especially https://www.cvedetails.com/cve/CVE-2009-0692/

dnsmasq

https://blog.skullsecurity.org/2015/how-i-nearly-almost-saved-the-internet-starring-afl-fuzz-and-dnsmasq