Beiträge von DoPe

Ich denke mal das liegt am NAT Loopback (oder einen der tausend anderen Bezeichnungen dafür)... Der DDNS Host sollte ja auf die WAN IP zeigen, sonst geht der Zugriff von Aussen nicht. Sieht so aus als ob das NAT Loopback nur in einem VLAN funktioniert oder die Firewall blockiert da was ... kannst Du aus VLAN 3 den Proxy erreichen und auch vom Proxy das VLAN3?

Ich für meinen Teil mache bei sowas gerne Split DNS, lasse also den DNS der im LAN verwendet wird, für den DDNS hostnamen gleich die korrekte LAN IP (in dem Fall vom Proxy) ausspucken. Dann wird gleich direkt kommuniziert ohne von wildem SNAT/DNAT und Maskieren des Routers am WAN Port abhängig zu sein.

Das Gast WLAN und auch Gast LAN (über Port 4) der Fritzbox ist ziemlich zugerammelt was auch okay ist.

Man kann in der Fritzbox keine Portweiterleitungen in das Gastnetz konfigurieren, die Geräte sind isoliert und der Gastbereich der Fritte hat von Hause aus ausgehende Sperren für alle Ports ausser die zum Surfen und Mailen. Den kann man anpassen oder Deaktivieren .... aber nur für alle Gastgeräte.

Zu finden unter Internet - Filter. Dort sieht man Zugangsprofil Gast ist fest hinterlegt. Beim Reiter Zugangsprofile kann man dann die Anpassungen vornehmen.

Das ist ein ganz normales Verhalten. Der Download nutzt mehrere Sessions und diese werden auf beide Anschlüsse verteilt. Wir haben hier mit 2x250Mbit VDSLern knappe 500MBit im Downstream.

Das kann man sogar mit einem Downloadmanager ausnutzen. Dieser teilt den Download nach Möglichkeit in kleinere Segmente und lädt mit mehreren Sessions gleichzeitig die einzelnen Segmente.

Oder hängt der Cloudkey evtl. im Rackmount? Da hatte ich auch schon Probleme mit dem Kontakt zum Rackmount und das Ethernet war ständig am Connecten und Disconnecten. War nur stabil wenn man etwas Druck an einer bestimmten Stelle ausgeübt hat, was dann durch mehrfach gefalltetes Papier zwischen Rackmount und Cloudkey "gefixt" wurde.

Am APL hast Du eigentlich nichts zu suchen. Der sollte normalerweise verschlossen sein ist er aber in den meisten Fällen nicht. Falls es nur ein zusätzlicher Verteiler ist, dann den Eigentümer fragen. Ansonsten sag ich mal wo kein Kläger da kein Richter.

Ich hoffe mal dein altes Drehscheibentelefon ist nicht wirklich uralt. Könnte sonst schwierig werden mit Impulswahlverfahren.

Zitat von razor

Ich habe mit WireGuard auf beiden USGs eine VPN-S2S-Verbindung mit dynamische IP und VLANs realisiert. Sollte also mit UDMs * auch möglich sein - denke ich.

Kann man in der UDM an der Oberfläche vorbei Konfigurieren. Bei mir muss ich aber unbedingt das Kabelmodem ready haben bevor die UDM bootet, sonst ist das wireguard nicht aktiv. Kann man evtl.mit skript lösen.

Zitat von ReneW

Vielleicht geht es, dass man erst alle IP's Blockiert und dann eine einzelne IP mit den passenden Ports wieder erlaubt.

Aber so tief stecke ich noch nicht in den "Vorfahrtsregeln" der Firewall drin.

Andersrum wird ein Schuh draus. Die Firewall klappert die Regeln von oben nach unten ab bis eine passende Regel gefunden wird... oder halt am Ende die Default Regel greift.

Wenn man also den Zugriff bis auf eine oder mehrere Ausnahmen verbieten will, solltest Du erst die Ausnahmen erlauben und dann ALLE Sperren.

Also ich kenne keine USG Firmware in der die VLANs untereinander per Default getrennt waren. Das muss also dann sehr sehr sehr alt sein, falls es das wirklich mal gab.

Wie Networker schon schreibt, die Trennung erfolgt über die Firewallregeln.

Das die UDM Routen für die einzelnen Netzwerke anlegt ist normal und ohne diese würde gar nichts gehen (Dann wüsste die UDM nicht über welche Schnittstelle die Antwortpakete raus müssen).

Das Traffic Management ist eine Art regelbasiertes Routing .... so ala alles von Client A soll über den Internetanschluss WAN2 raus, der Rest über WAN1. Routing ist ohne dieses Feature ausschliesslich zielbasiert also wird anhand der Ziel IP ermittelt wohin das Paket soll.

Stimmen diese Angaben oder Tipfehler? alt: 192.168.1.0/22 und neu: 192.168.1.0/24 und VLAN 2 - 192.168.2.0/24

Die Subnetmasken hast Du auch alle angepasst auf deinen Geräten?

Nur so als Idee, denn mit der alten Subnetmaske sind deine getrennten VLANs ein IP Netz und die Clients versuchen gar nicht erst das Gateway zu bemühen. Kann man ja mit paar Pings fix testen.

Ich hab bisher nur festgestellt, dass hier mit IPv6 offenbar Probleme mit mehreren Verbindungen bestehen. Ich mache gerne in Google die ungelesenen Beiträge auf und klicke dann die interessanten Themen so an, dass diese in einem neuen Tab öffnen. Seit einigen Tagen führt das dazu, dass diese Tabs nur am rumrödeln sind ohne fertig zu laden.

Mit einem PC der in einem IPv4 only VLAN hängt läuft es aber bisher immer problemlos.

Also die Konfiguration sollte problemlos laufen. Habe ich an 2 Schulen so mit DHCP-Relay auf Windows Server und diversen VLANs ....

So wie der TE Ersteller das einrichten will muss er:

Windows DHCP ins Default Netz packen.

Unifi DHCP im Default auf None setzen (Da das auch das Management Netz ist, aufpassen dass die UniFi Geräte entweder statische IPs bekommen oder der DHCP auch immer verfügbar ist. Die landen sonst alle irgendwann auf der Fallback IP wenn man unglückliches Timing hat).

DHCP im Marvin Netz ist korrekt mit DHCP-Relay zum Windows Server (im Default Netz).

Wenn ich es richtig verstanden habe, dann funktioniert dann auch im WLAN alles wie gewünscht. Das lässt für mich nur den Schluss zu, dass die LAN Ports für die verkabelten Geräte nicht korrekt zu den VLANs zugewiesen sind.

Verbindungen zwischen Switchen, Routern, Accesspoints bitte mal mit primären Netzwerk Default ohne Traffic Beschränkungshaken konfigurieren. (Bei Switch - Switch Verbindungen jeweils an den beiden Ports der 2 Switche). Bei USG und AP sollte das automatisch stattfinden.

Die Ports an denen Du Drucker, PCs, Server whatever anschliesst. Bitte auf primäres Netzwerk das wo das Gerät hingehört auswählen und Traffic Beschränkung anhaken und Block ALL setzen.

Auf einem Bild ist ein blockierter Port zu sehen. Vermutlich hast Du irgendwo Loops, ggf. weil LAN Ports nicht korrekt konfiguriert sind.

Reagiert der Touch Screen nicht mehr? Funktioniert denn das Netzwerk/Internet noch?

Hatten nicht einige das Problem nach Stromausfall ... von wegen der Displaymeldung? (und vermutlich zerschossener DB?)

Poste bitte mal Screen von beiden Netzwerke inkl. DHCP Einstellungen also am besten alles was da so drin ist mit Erweitert.

Und dann bitte mal Screens vom Switch - Portmanager ... je ein Port der zu einem PC mit Default und zu Marvin Netz gehören soll. Und den vom DHCP Server bitte auch.

Guter Hinweis mit dem Flex Mini ... startet der evtl. sporadisch neu?

APIPA Adressen weisen sich die Geräte selbst zu. Das sollte nur passieren wenn kein DHCP Server verfügbar ist oder da was klemmt. Sind 2 DHCP Server aktiv, dann sollte es eher passieren dass die Geräte auch mal eine IP vom falschen DHCP bekommen.

Ich würde den Komponenten der PV-Anlage die IPs wirklich statisch konfigurieren statt DHCP Reservierungen zu benutzen. Wenn das in einem separaten VLAN läuft ist das mMn. am unproblematischsten.

Gerade gemacht. Sieht erstmal ok aus.

Zitat von Steho

Ich glaub, wir reden hier teils aneinander vorbei...

Gut möglich ist ja auch etwas umfangreicher Also ist dein 232 VLAN quasi eigentlich überhaupt nicht in Benutzung ausser in Richtung EON.

Hmm sieht ja dann so aus als ob bei Deinem Produkt das VLAN 232 überflüssig ist und bei EON wieder hochqualifizierer Produkt Support geleistet wird. Vermutlich hängst Du jetzt in einem Teil des EON Netzes der direkt Zugriff zu den SIP Servern hat und der VLAN Zauber ist eher für Standart 0815 Anschlüsse mit CGNAT oder etwas in der Art.

Für die Telekom Nummer hast Du aber dann offensichtlich Zugangsdaten erstellt?

Zitat von Slakish

Ich glaube es ging eher Darum das man die Verbindung ja einfach Blockieren kann, sich aber schon Nach Kurzer zeit eine sehr lange Liste An Firewall Regeln Ansammelt, durch die man immer wieder Durchscollen muss. Oder?

Selbstverständlich ist das so. Vielleicht kann man aber auch gezielt erlauben?

Also Filtern kannst Du prinzipiell nur mit verbieten oder erlauben - halt klassisch Firewall. Egal wie man das regelt ... entweder sperrt man zuviele oder es sind nicht alle Schergen gesperrt ...

Am besten wäre den Dienst nur via VPN erreichbar zu machen, wenn das denn möglich ist. Portweiterleitungen sind für Sicherheit nie gut.

Also alles eine Frage des Dienstes und des Nutzerverhaltens (z.B. von wo wird der Dienst genutzt)

Ganz einfach, trenne erstmal deine Netze sauber, denn wenn 2 VLANs existieren und die nicht versehentlich irgendwo wieder zusammengepatcht wurden, dann bekommt ein DHCP aus dem einen VLAN die Requests aus dem anderen VLAN. Genau desshalb gibt es ja DHCP Relays, damit in einem DHCP Server alles Scopes gemanaged werden können und man nicht wirklich in jedem VLAN einen separaten DHCP Server haben muss.

Logisch geht es über die Firewall nicht ... Broadcast wird ja auch nicht geroutet ...

Wie kommt man darauf? -> "Es scheint als wenn in Unternehmen kein UniFi eingesetzt wird, in Verbindung mit Servern wie Windows DHCP."

In großen Konzernen sicherlich nicht. Gelten kleine Unternehmen mit kleiner bis mittlerer 2 Stelliger Mitarbeiteranzahl auch? Da gibt es das mit Sicherheit.

Hast Du die Ports korrekt konfiguriert was die VLANs angeht? Davon habe ich nicht so recht was gesehen in deinem Eingangspost. Standardprofil ist Default untagget, Alles andere getaggt ... wenn Du AP anschliesst und Wifis mit den korrekten VLANs erstellt hast passt das so. Steckst Du PC an LAN Port bist Du aber immer im Default Netzwerk solange Du die Ports nicht anderweitig einstellst.

Von wo testest Du das? Ist an dem Standort von dem Du testest evtl. das 192.168.178.0/24 Netz in Benutzung?

Hast Du in der Firewall was konfiguriert? Da kann man natürlich die Verbindung auch blockieren.

Kannst Du die 192.168.2.1 anpingen?