Doorbird und Unifi USG 3P - VLAN Probleme

Nachts ist's kälter als draußen... Den Satz versteht doch kein Mensch !
Kein Wort davon welches Transport Protokoll die Doorbird App nutzt geschweige denn mit einem Wireshark Trace mal selber überprüft.
Wie soll man da zielgerichtet helfen ? Unmöglich ohne diese Information !
Da hilft auch uns dann nur der Blick in die berühmte Kristallkugel !
Wie Kollege @StefanKittel schon richtig vermutet ist das vermutlich irgendwein Broad- oder Multicast Verfahren was dann einen UDP Helper und oder Multicast Routing oder Proxying erzwingt.
Aber da sind wir schon wieder mitten drin im Raten und Spekulieren im freien Fall...! Ohne entsprechende Infos keine Chance.

Du kannst doch ganz einfach mal einen Wireshark Trace mit HTTP mit dem eines HTTPS vergleichen. Anahnd des Paket Flows kannst du dann doch sofort sehen wo es kneift.
Es ist auch NICHT davon auszugehen das es beim Protokoll HTTP und HTTPS an sich liegt denn beide sind vollkommen problemlos routebar. Wären sie das nicht würde das Internet gar nicht funktionieren.
Also wird das ganz sicher auch bei dir über die VLAN Segmente vollständig routebar sein.
Der Knackpunkt bei solchen Geräten ist immer die Frage WIE machen die sich im Netzwerk bekannt, damit sie von den Konfig Clients DAU sicher erkannt werden und von Usern mit maximaler Technikferne bedient werden können.
Hierzu nutzen sie in der Regel Broadcast oder Multicast Technologien die automatisch diese Devices und ihre Präsenz ins Netz blasen an alle Teilnehmer.
Das wiederum geht aber nicht immer ohne Hilfsmittel wie UDP Helper Adressen, PIM usw. usw. auf dem Router denn bekanntlich gehen Broad- und Multicasts nicht so ohne weiteres über Router Grenzen.
Da wir aber diese Mechanismen vom Doorbird Produkt nicht kennen kann man hier nur im freien Fall raten.
Erschwerend kommt noch dazu das wenn der Router mit Accesslisten arbeitet oder er eine Firewall mit Regeln ist und ein Anwender das nicht weiss diese Regeln dann noch blockierend dazukommen.
Ob du z.B. komplett offen und transparent routest über deine VLANs oder da auch ACLs oder Firewalls im Spiel sind hast du auch noch mit keinem Wort erwähnt.
In der Beziehung ist das für alle hier ohne diese wichtigen Informationen wie russiches Roulette.

Nur so viel:
Sieh dir mal das Doorbird Produktblatt an. Dort steht doch die Lösung des Problems und das sollte der Doorbird Produkt Support eigentlich wie aus der Pistole geschossen wissen:
Für das Bekanntmachen im Netz nutzt das Doorbird Produkt Bonjour sprich also den mDNS Standard:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
mDNS nutzt einen nicht routebare Link Local Multicast Adresse. Nicht routebar, weil deren TTL fest auf 1 gesetzt ist in dieser MC Gruppenadresse.
Die Lösung ist aber kinderleicht und man verwendet einen mDNS Proxy. In vielen besseren WLAN Accesspoints ist sowas schon fest implementiert wie z.B. hier bei einem Ruckus AP:

Du kannst es aber auch ganz einfach und preiswert im LAN oder WLAN mit einem Raspberry Pi lösen. Guckst du hier:
Netzwerk Management Server mit Raspberry Pi
Das ist schnell erledigt !
Sprich den Doorbird Support darauf an !!! Das sollten die eigentlich wissen wenn sie mDNS Techniken in ihren Produkten nutzen !!

Was den Trace anbetrifft kann man das mDNS auch sehen. Allerdings redet das Teil nach seinem Broadcast hier schon direkt mit dem DNS Server:

Sehr gruselig ist aber das hier:

Damit bläst das Teil irgendeine Konfig von sich oder was auch immer ins Netz. Warum dort eine IP Gateway Adresse des US Postal Services in Raleigh (NC) angegeben wird mit einer syntaktisch völlig falschen und wirren Subnetzmaske weiss wohl auch nur der Hersteller selber.
Sieht aber gruselig aus und spricht nicht gerade für das Produkt, denn es erweckt den Eindruck als ob hier mit der sehr heissen Nadle gestrickt wurde und schlimmer noch das irgendwas "nach Hause" telefoniert wird. Für ein Security Produkt ein absolutes NoGo !
Auch dazu solltest du den Support mal auf den Zahn fühlen...