Not sure if `ipv4.firewall` is available in LXD 3.11 - not set = not implemented in my version?

There is a post API 1.0 variable ipv4.firewall :

The changes below were introduced to the LXD API after the 1.0 API was finalized.

network_firewall_filtering

Add two new keys, ipv4.firewall and ipv6.firewall which if set to false will turn off the generation of iptables FORWARDING rules. NAT rules will still be added so long as the matching ipv4.nat or ipv6.nat key is set to true.

Rules necessary for dnsmasq to work (DHCP/DNS) will always be applied if dnsmasq is enabled on the bridge.

Looking for it but it’s not there:

$ lxc network show lxdbr0
config:
  ipv4.address: 10.185.64.1/24
  ipv4.nat: "true"
  ipv6.address: fd42:f2c5:781c:6810::1/64
  ipv6.nat: "true"
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/C
- /1.0/containers/S
managed: true
status: Created
locations:
- none

or

lxc network get lxdbr0 ipv4.nat
true

and is true that setting both ipv4.nat and ipv4.firewall to false will result in no iptables rules for lxdbr0 at all?

Thanks.

true is the default value for ipv(4-6).firewall, if it’s not there it’s true.
I have never tried to turn off nat, If you use default bridging you usually don’t want to turn nat off else your container can’t access internet.
if you do it it will probably not turn off default rules for dhcp/dns, though. since your container will not have any ip address if you don’t set it manually.

1 Like

Thank you very much for the info about ipv4.firewall.

About the nat rule

-A POSTROUTING -s 10.185.64.0/24 ! -d 10.185.64.0/24  -j MASQUERADE

What I want to do is set up a small DNS-mostly-forwarding “man-in-the-middle” on the host which watches and sometimes takes action. This DNS agent wants to known the source address of the requests. It’s not secret so the container clients should have resolve.conf set to the DNS agents address (e.g. 10.185.64.2). Nevertheless any DNS traffic going to other destinations should be rerouted to the DNS agent. So some new NAT rules are required.

If rule order is going to be problem, it might be better to add the MASQ rule in the correct order from outside of LXD.

not sure if I follow all your requirements but the existing dnsmasq installed by default by LXD is already a MITM (dnsmasq is not a full resolver, it always routes to a true dns server)
you can set up dnsmasq to log queries, add a key to the configuration of your lxdbr0 bridge:

raw.dnsmasq: conf-file=/media/root/rawdnsmasq-lxd

the path /media/root is not mandatory, but you have to find some place on the disk that escapes the snap ‘protection’. I found that /media was accessible (/etc or /opt are not) and so I used it.
in the config file that I named ‘rawdnsmasq-lxd’, I added:

log-queries
log-async
log-facility=/var/log/dnsmasq-lxd.log

IIRC I had to create the log file by hand (not sure), it should belong to lxd in any case.

You can use in the additional dnsmasq config file all the considerable capabilities of dnsmasq (the fine manual is avaiable to help).

If you want to add a different dns server such as bind sure it’s possible, bind is not so much more difficult to use than dnsmasq, but the real pain will be to configure bind and lxd dnsmasq so that they can live together. And if you have systemd you will have to deal with the systemd resolver. And if you have a graphical computer you may have to deal with network manager. Using the existing dnsmasq like I have shown you will be a lot easier, believe me.

1 Like

Thanks! Set up the logging and it is working.

don’t forget that if standard routing is left as setup by default, your (evil ?) container can bypass the default dns server and address directly any dns server on the internet. That’s not something standard applications do, but rolling up its own name resolution can be done. If
dig @8.8.8.8 google.fr
works inside the container, your dns can be bypassed.

Good point. Yes, DNS can be bypassed from inside the container in the default system state.

I have another question: When I modify the container /etc/resolv.conf eventually LXD overwrites it. How can I prevent that? What follows is an attempt to describe the background for this question:

Already on my home network calls to DNS not made to the proper DHCP designated DNS server are rerouted via NAT tables to the correct DNS server. (This correct DNS server is actually a Raspberry Pi running Pihole). Those NAT settings are made on a home router Ubiquity ERLite-3. I explain in this post a method to do the rerouting without losing the identity of the senders, even on the same level 4 subnet.

One task I want to perform with LXD containers in a subnet is to conveniently simulate a small home network. Why would I want to do this? I am developing a DNS tool, and using an LXD subnet as a simulated network is easier/faster than running code on a Raspberry Pi.
That is why I sometimes want to override the original /etc/resolv.d to point to DNS tool under test, running on the host.

I added a new address on the host ip address add 10.185.64.2 dev lxdbr0 and pointed to DNS tool to listen to that address. It worked at first. But then LXD (I guess not the container root) overwrote the contents of /etc/resolv.d with

domain lxd
search lxd
nameserver 10.185.64.1

and the DNS tool under test no longer received DNS calls, they went to LXD’s dnsmasq instead.

When I modify the container /etc/resolv.conf eventually LXD overwrites it. How can I prevent that?
try this
dhcp-option = option:dns-server, 10.185.64.2
restart service by snap restart lxd

That does indeed work. Thank you very much

You are probably tired. it’s lxc list, the only thing you have to do with lxd is ‘lxd init’

1 Like