UDMp does not boot with pi hole enabled

[dirstel]

System:
UDMp v1.8.0 // 5.14.22 (installed v1.8.0 and did not change anything else)

Changes:
Installed bootscript as described here: https://github.com/boostchicken/udm-utilities/tree/master/on-boot-script
Installed pi hole as described here: https://github.com/boostchicken/udm-utilities/tree/master/run-pihole
added a custom script to start a ntp-container

Everything works fine, but rebooting the UDMpro leads to

• working local portal

• non operational controller
• non operational protect
• no dns

Switiching to any of the apps (tested "network" and "protect") gives a blank screen and application does not load.

log says repeatedly:
Sep 9 02:11:06 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"CNI'
Sep 9 02:11:11 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"CNI'
Sep 9 02:11:11 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"name:'
Sep 9 02:11:11 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"name:'
Sep 9 02:11:11 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"name:'
Sep 9 02:11:11 UDMpro user.notice ubios-udapi-server: ubios-udapi-server: Found unexpected rule --comment '"dnat'

Workarround:
I tried to prevent the 10_dns.sh script from executing by chomod -x /mnt/data/on_boot.d/10_dns.sh
Rebooting gives fully functional system again (including pi hole and networking/dns)

So, why/when is the 10-dns.sh script needed? when updating to new version?

[boostchicken]

The only time iptables rules are made would be during the FORCED_INTFC stuff. Have you tried removing that and seeing if it boots?

[boostchicken]

To answer your question the 10-dns script makes the network interfaces required for the DNS servers. The only iptables rules it makes are to force devices through pihole. None of the rules I made have comments on them so I don't what rules it's conflicting with. Could you give me an iptables-save command so I can see the rules its conflicting with?

The CNI rule is probably related to your ntp-container since it makes its own network

[dirstel]

Hmm, I do not think, the ntp-container is causing troubles, because it does not use special networking (attached the 90-ntp.sh), but uses the hosts network.

I experienced somewhat the same trouble earlier without investigation in detail, because in that case I had updated the controller to 6.0.15 and thought it was cause of my trouble. I decided to start plain and made a factory reset and restored an backup before trying again.

For further investigation, I attached the 20-dns.conflist and 10-dns.sh as well as a iptables-save.

Had to rename the files to .log to upload them here...
90-ntp.sh.log
10-dns.sh.log
20-dns.conflist.log
iptable-save.log

[spali]

Just as reference if it helps.
I have an UMDP also with vanilla 1.8.0 and the only rules with comments are simple "id"'s. I assume everything else with comment other than a id has to come from somewhere else.
Check out https://github.com/search?q=%22CNI+portfwd+requiring+masquerade%22&type=code
They come from podman itself... the question is why did podman actually create these rules. Did you start containers with different network options maybe?

Edit: correction... they come with the CNI plugins downloaded in the 10-dns.sh

[ghvader]

@dirstel read through this thread it should help - here

[boostchicken]

-A POSTROUTING -s 10.1.254.2/32 -m comment --comment "name: "podman" id: "0fcf505b0b159acf6fda413b676e9b15958b913ed5c5b727c0e4051016281276"" -j CNI-570663b1ad82829df38eadcc
-A CNI-570663b1ad82829df38eadcc -d 10.1.254.0/24 -m comment --comment "name: "podman" id: "0fcf505b0b159acf6fda413b676e9b15958b913ed5c5b727c0e4051016281276"" -j ACCEPT
-A CNI-570663b1ad82829df38eadcc ! -d 224.0.0.0/4 -m comment --comment "name: "podman" id: "0fcf505b0b159acf6fda413b676e9b15958b913ed5c5b727c0e4051016281276"" -j MASQUERADE
-A CNI-DN-570663b1ad82829df38ea -s 10.1.254.0/24 -p udp -m udp --dport 123 -j CNI-HOSTPORT-SETMARK

Those are coming from using the default podman network when launching your ntp container. Launch it with --host or something else. That hsould fix your issue

[dirstel]

I gonna try building everything from the scratch (using a controller backup). Seems there is no way to tell things apart. Pihole is more of an issue to me as ntp is.
For now I need a stable connection (Homeoffice) so I'll report back later.

[dirstel]

starting from scratch:

• factoryreset, configure basics, restore controller backup
• install on_boot script as described
• reboot -- everything is fine
• setup ntp contain (network host)
• reboot -- still everything is fine

bottomline:
happy :)

lessons learned:

1. stop messing arround (without need)
2. a shame this has to be done by "dirty hacks"