New containers failing with no network or DNS lookup failure

[jnewman33]

Hey all,

Retired Proxmox hobbyist here who has come to rely alot on tteck scripts. I use them almost daily. Much like a previous poster here I suddenly am finding all the scipts not working all citing some sort of networking failure. Let me be clear in that I know its not the scripts! I know have a local networking issue. Also like the previous poster I believe I have IPV6 interfering. My cluster is behind a Ubiquiti UDM Pro and as best I can tell I have IPV6 disabled on both the WAN and LAN.

Just as example when creating Debian LXC the script is showing Network Connected: as IPV6 address jsut before indicating DNS lookup failure and error in line23.

I chose to start this discussion here as I trust this community a lot. Am I on the right track looking at IPV6 as the problem?

Thanks for any help,
James

[tteck]

the script is showing Network Connected: as IPV6 address

This would indicate that IPv6 is not disabled in your router.

[tteck]

As a test, try disabling IPv6 in the container using Advanced settings.

[afmotta]

I was having the same issue, and installing with Advanced setting with IPv6 Disabled fixed it.

[jnewman33]

tteck-
Thanks for enganging in this discussion. I have discovered something this morning. I had seen a comment in another thread asking about available IP's.

I have a lidarr container that shows (in part) the following with ip a command:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:0d:bb:2d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.10.33.164/24 brd 10.10.33.255 scope global dynamic eth0
valid_lft 26785sec preferred_lft 26785sec
inet 10.10.33.170/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26797sec preferred_lft 26797sec
inet 10.10.33.175/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26828sec preferred_lft 26828sec
inet 10.10.33.176/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26860sec preferred_lft 26860sec
inet 10.10.33.177/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26881sec preferred_lft 26881sec
inet 10.10.33.178/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26892sec preferred_lft 26892sec
inet 10.10.33.180/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26903sec preferred_lft 26903sec
inet 10.10.33.183/24 brd 10.10.33.255 scope global secondary dynamic eth0
valid_lft 26924sec preferred_lft 26924sec
inet 10.10.33.184/24 brd 10.10.33.255 scope global secondary dynamic eth0

This goes on for all IP's in the scope.

Shutting down this container has enabled DHCP to resume normal function and the scripts now complete properly.

My only ongoing question would be what made this container go "rogue" in this fashion?

Thanks again for all you do and your attention to this matter.

James