[Freedombox-discuss] UPDATE: Dnsmasq starts reliably on both interfaces, but...

[Sunil Mohan Adapa]

On 10/21/21 12:12, A. F. Cano wrote:
[...]
> 
> So now internal machines get assigned addresses from the ranges
> specified.  However, from the first paragraph in the dnsmasq man page:
> 
>         Dnsmasq  accepts  DNS queries and either answers them from a small, lo‐
>         cal, cache or forwards them to a real, recursive, DNS server. It  loads
>         the  contents of /etc/hosts so that local hostnames which do not appear
>         in the global DNS can be resolved and also answers DNS queries for DHCP
>         configured  hosts.  It can also act as the authoritative DNS server for
>         one or more domains, allowing local names to appear in the global  DNS.
>         It can be configured to do DNSSEC validation.
> 
> "It loads the contents of /etc/hosts so that local hostnames which do
> not appear in the global DNS..."
> 
> This is exactly what I wanted.  In fact I have added all my local hosts
> to the FreedomBox /etc/hosts file, in the form of:
> 
> 192.168.224.19  <local-machine-name>.local    <local-machine-name>
> 
> but those IP numbers are ignored and local machines are assigned high
> numbers (178 in the case of the machine above), even after I changed the
> 19 to 39, so it would be inside the range of 36-254 as specified in the
> command line arguments, and rebooted.  Something is not working as the
> manual says it should.

I think this is a misunderstanding. When client sends a DNS query to 
dnsmasq, it will look into /etc/hosts for answers. If you have an entry 
such as `1.2.3.4 foo.example.org` in /etc/hosts. When machine in the 
network try to resolve 'foo.example.org' dnsmasq will respond with 1.2.3.4.

This does not apply to the DCHP server functionality. DHCP server will 
not look into the /etc/hosts when allocating IP addresses to the clients 
on the network.

There is, however, an option for dnsmasq's DHCP server functionality 
that can make this happen. If you pass:

--dhcp-host=foo,192.168.224.19

then, a machine on the local network with hostname set to 'foo' (this is 
passed in a DHCP request, typically) will be allotted this particular IP 
address. There is also `--dhcp-hostsfile=` to put all these allocations 
in a single file. First create the file with all the mappings you want. 
Then pass the --dhcp-hostsfile option to dnsmasq instance spawned by 
Network Manager using the trick I mentioned earlier. That should take 
care of all the static IP address allocations that you need to do.

Also note that .local TLD is special. Most hosts when they see .local 
domain to resolved, they will not perform a DNS query and instead 
perform an mDNS query on the local network.

[...]
> 
> Also, the "no route to host" issue remains.  I have to turn off the
> firewall for anything to get out/in.  I've noticed the problem with imap
> and fetchmail, matrix/Element and Quassel.  Web traffic works ok but
> only because it goes through privoxy on the FreedomBox.

I could not spend time on this issue yet.

> 
> There is also the issue of communicating between the 2 internal
> interfaces.  Nothing seems to get through between them and turning off
> the firewall doesn't affect this.  I can't do unison syncs or ssh
> between machines on the 2 sub-nets, not even ping.
> 

I haven't tried doing this before but here are two possible way to 
handle this.

Solution 1) You can merge the two internal interfaces into a bridge 
interface and allocate IP addresses to all clients from a single IP range.

The way bridging works is, you create a new bridge interface, say 'br0'. 
Then you de-configure the two LAN interfaces and add them to the bridge. 
After that configure the bridge interface 'br0' as if this is a regular 
network interface (shared mode, dnsmasq, etc.).

This configuration be done with Network Manager (although not from 
FreedomBox interface). Cockpit might provide a GUI for it. Otherwise, 
use nmtui.

Solution 2) You can add masquerade=true "internal" zone in firewalld. 
Like this:

firewall-cmd --zone=internal --add-masquerade
firewall-cmd --zone=internal --add-masquerade --permanent

I don't know if there are any security implications to this.

-- 
Sunil