Ingenioes

I think the version on dockerhub is outdated, the official instance, that has been working for me (nitter.net) is on version 2023.09.02 while the dockerhub img is still on 2023.08.08.

As far as I'm aware of, the GS110EMX I'm using, has no routing functions or other feature sets that might result in that weird behaviour I'm witnessing. I've now only attached 1 notebook on a untagged VLAN30 port and on the same switch only attached the UNRAID Server eth0 = VLAN1 untagged, VLAN20 tagged, VLAN30 tagged (same other settings as above). The IP scan still found my br0 MAC, Vendor etc. even when I went as far as only setting VLAN30 tagged on the switch port to the UNRAID Server eth0 (no vlan1 untageed, no VLAN20 tagged). At this point I'm pretty sure this is some kind of UNRAID network bridge behaviour or some setting I've done in the past in UNRAID and no Switch/Router thing. But of course I'm far from experienced in that area and it can always be layer 8 issue ... I'm also aware of the fact that this is kind of impossible to solve if you are not present to all devices and can check all configs etc. so therefore I'm thankful for your input but I guess we will not solve this issue right now. I will - in a few weeks - offload my Firewall/Router to a separate box and stop using a VM for it ... maybe that will change things. I will try to solve it and give feedback

Thank you for your input. But to my understanding, the fact, that my network scan will no longer see the br0 interface(and the corresponding information like mac, motherboard vendor etc), the second I remove vlan20 from eth0, shows me that the information my network scan gets is not coming from/via my firewall ... its coming directly from that eth0.20 interface. I've just completely shut down my Untangle VM and tried the network scan again, it did show me the information of my br0 again

Hey there, I've recently decided to add some vlans to my network, to add some layer of security and separate guest wifi, server etc. Nearly everything works as indented but I've seen strange behaviour in terms of the br0 // br0.xx separation and I cant figure it out. First of all my Setup: vlan1 default network = 192.168.0.0/24 // 192.168.0.3 UNRAID // 192.168.0.1 Untangle FW vlan20 guest wifi = 10.20.0.0/24 // no UNRAID IP on br0.20 // 0.1 Untangle FW vlan30 IOT vlan/wifi = 10.30.0.0/24 // NO UNRAID IP on br0.30 // 0.1 Untangle FW (I have however already set the network information for the vlan20 and vlan30 in the Settings -> Docker area) [UNRAID -> 2x passthrough 1g nic to my Untangle firewall VM -> 1nic coming from the fibre modem of my ISP, 1nic to port1 GS110EMX (LAN NIC of the firewall)] UNRAID -> br0 192.168.0.3/24 -> port10 GS110EMX UNRAID -> br0.20 (no IP set) -> port10 GS110EMX UNRAID -> br0.30 (no IP set) -> port10 GS110EMX etc. etc. For UNRAID the GS110EMX port10 has vlan1(default) set as untagged and VLAN20, 30 etc. as tagged. For the firewall the GS110EMX port1 has vlan1 untagged and all other vlans as tagged.(traffic flows, dhcp works, everything fine) I have a Unifi Controller container running for my wifi management(management vlan1) and some aps with wifi networks in the default vlan1, vlan20 and vlan30. The Unifi controller runs on br0 with "bridge" as the network type. When I connect a device to my wifi vlan20 and run an ip scanner like Advanced IP Scanner, it will see my UNRAID br0 interface(192.168.0.3) with ip, motherboard vendor and mac address(its the mac of eth0/br0). When I remove vlan20 from port 10 of my GS110EMX the network scanner will no longer find my UNRAID br0 with 192.168.0.3. So I would assume the information is coming from br0.20 and not through my firewall or smth. I thought, when there is no IP set on a vlan interface in UNRAID, then UNRAID will not answer on that nic or show any services, let alone it will answer with another int? I would like to keep br0.20 in that vlan but stop my main br0 from "presenting itself" to network scanners talking on vlan20. Is it some weird behaviour because its a network bridge? Am I doing smth wrong? I also tried to use another nic on my server to physically separate br0 and the vlans. So I went for br0(192.168.0.3) on eth0, br1(no ip) on eth1 and added the vlans to br1 = br1.20, br1.30 etc. It sadly did not change the behaviour, my notebook in wifi vlan20 could still "see" the br0 int with 192.168.0.3 ... only when I removed vlan20 from the switch port of br1 the scan stopped showing the br0 details. I needs to be said, that no access is possible to that br0 int in any way, cant ping, cant see open ports, cant access the webui, cant ssh ... everything is blocked but you can see the ip, mobo-vendor and mac. Maybe thats helpful??? I started a tcpdump on br0.20 while running the scan and can see the following: root@Vault:~# tcpdump -i br0.20 src 10.20.0.149 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0.20, link-type EN10MB (Ethernet), capture size 262144 bytes 16:56:01.043646 ARP, Request who-has Vault.local tell Iris-PC, length 46 16:56:11.919226 IP Iris-PC.49667 > 239.255.255.250.3702: UDP, length 656 Im new to the vlan topic, doing a newbie error or maybe this is an indented behaviour? Would love to hear the opinion of someone else. If nothing comes up I guess I will just remove the vlan int from unraid and run everything via routing from the firewall into br0 ... Thank you in advance! vault-diagnostics-20220104-1804.zip

Hey guys, I've been fighting total lockups of my UNRAID now for a few weeks. I've done a thread in the General Support section before, where I was given the order to turn of all docker and activate them afterwards one by one. Link I think I've narrowed it down to the privoxy function of the binhexqbittorrentvpn docker. As soon as I turn that specific option inside the docker on, my server will hard lockup within the next 24-48h without any way to access it afterwards. Has anyone seen such behaviour before? Any tips what I could do, would rly like to keep the privoxy feature as its a rly nice thing. I will attach a screenshot of the docker logs when it locked up the last time(gathered via IDRAC), syslog and the docker supervisord.log. My Last lockdown iirc was 9th March ~22 00. Thank you in advance. supervisord.log syslog_crash_7-3-21-1712.log