Beiträge von sliderffm

    Nun ja, wenn ich das hier so richtig sehe, ist es auch hier eigentlich ganz einfach :winking_face:


    Die L3-Switch zu Haus ist als Gateway für die drei Netzwerke eingetragen, also Routing zwischen diesen Netzten bleibt quasi "lokal" und wird nicht über die UBB geschickt. Macht eventl. Sinn, um die Funkstrecke zu entlasten und der Traffic ist erstmal zwischen diesen drei Netzwerken unabhängig von der UDM-Pro. DNS-Traffic geht aber trotzdem da drüber, da offensichtlich als Default-DNS-Server die 10.255.254.1 verteilt wird, die wiederrum an der UDM-Pro anliegt und als Defaults-GW in der Switch konfiguriert ist. Will man also auf den Server im Firmen-Netzwerk zugreifen, wird es über die Switch und dann auf die UDM-Pro geroutet. Hier könnte man dann auch entsprechende FW-Regeln anlegen, das nur bestimmt Clients aus den Heim-Netzwerken Zugriff bekommen.


    Das Problem ist ja aktuell, das die Clients sich unterschiedlich mit dem DNS-Server verhalten, bei manchen, wie z.b dem iPhone, wird die 10.255..254.1 vom DHCP-Server verteilt. Ob das iPhone den DNS-Server anfragen konnte, ist nicht klar, es wurde nur gesagt, das der Wifiman nicht funktioniert. Der funktioniert glaube ich nur wenn der Client und der Server sich im gleichen Netzwerk befinden. Und auf der Switch wird der Wifiman-Server nicht rennen.


    Daher erstmal abklären, ob der DNS-Server generell aus den anderen Netzwerken mit dem Laptop funktioniert. Ist das der Fall, liegt ein Problem bei den nicht funktionierenden Clients vor. Hier meine Vermutung, das sie noch nicht die neuen Einstellungen vom DHCP-Server erhalten haben. Ein Neustart der Clients sollte das beheben, wenn das den die Ursache sein sollte.


    Ziel war wohl, das Heimnetzwerk vom Firmennetzwerk zu trennen und das Routing im Heimnetzwerk von der Switch übernommen wird, damit nicht alles über die UDM-Pro geroutet wird. Das sollte auch so funktionieren, das Routing übernimmt die Switch, alles was die nicht kennt, wird an die UDM-Pro weitergeleitet. Zwischen den drei Netzwerken im Heimnetzwerk greifen hier natürlich keine Firewall-Regeln, da die Switch hier nur ACLs kennt, die man auch nur über die Console der Switch einstellen kann. Und Stateful Packet Inspection kann die schon gar nicht.


    Mal abwarten, ob der Laptop in den einzelnen Netzwerken den DNS-Server erreichen konnte.

    ja einen Laptop hätte ich um all dies zu prüfen.

    per ssh wird mir das hier angezeigt


    Also gehe ich mit meinem Laptop in jedes Netzwerk und überprüfe welcher DNS server dort eingetragen ist?

    Genauso, wie ich es vermutet habe, das Default-GW ist für die Switch 10.255.253.1:

    S 0.0.0.0/0 [1/41 via 10.255.253.1, 21:00:56, vlan 4040


    Ja genau, so würde ich zumindest vorgehen, um die allgemeine DNS-Funktionalität aus allen Netzwerken zu prüfen, wenn das von dem Laptop funktioniert, dann haben die Endgeräte wohl irgendein Problem. Wie schon geschrieben, es könnte noch ein alter DNS-Eintrag von der alten Konfiguration vorhanden sein und daher die Clients einen DNS-Server Problem melden. Hier sollte ein Neustart von dem Gerät helfen, damit es die neue DNS-Konfig bekommt vom DHCP-Server.


    Also mit dem Laptop in jedes Netzwerk verbinden und nicht nur schauen, welcher DNS-Server eintragen wird - hier sollte ja überall die 10.255.254.1 eingetragen sein - sondern auch mit nslookup testen, ob er funktioniert. Hierbei aber immer einen anderen DNS-Namen zum auflösen nehmen, nicht das der Name aus dem DNS-Cache aufgelöst wird. Hierbei kannst du dann auch gleich mal schauen, ob du aus den einzelnen Netzwerken das routing funktioniert, also nicht nur ein nslookup auf den DNS-Namen machen, sondern auch schauen, ob er via ping erreichbar ist.


    Von den einzelnen Netzwerken könntest du auch testen, ob du mit "https://10.255.253.1:8900" (könnte auch sein, das du es mit http aufrufen musst, ich habe bei mir ein eigenes Zertifikat installiert, daher ist mir nicht bekannt, wie das ohne Zertifikat konfiguriert ist) den Wifiman Server erreichen kannst. Hier sollte die Ausgabe "WiFiman server" ausgegeben werden. Wie schon geschrieben, ich nehme mal an, das der Wifiman-Client das Default-GW benutzt und wenn das aus dem Netzwerk 192.168.1.0/24, 192.168.40.0/24 oder 192.168.100.0/24 kommt, wird er wohl auf der Switch versuchen den Server zu finden, was aber nicht klappen wird.

    Das Gerät war im Heimnetz, zu Hause funktionierte es auch nicht.

    Ich habe bei meinem iPhone nachgeschaut dort steht als dns automatisch der Server 10.255.253.1 (inter-vlan-routing)


    Habe das system gestern komplett neu aufgesetzt. Also ist alles frisch und hat noch keine Firewall regeln.

    Okay, das ist eine Bogon IP Adresse, diese wurde wohl automatisch beim erstellen der Layer3-Switch erstellt und wird von der Switch als Default-Route benutzt.

    Das sollte man via SSH-Login auf der Switch sehen, wenn man folgendes dort eingibt:

    Code
    telnet localhost
    enable
    show ip route


    Hast du einen Laptop, mit dem du dich mit den einzelnen Netzwerken verbinden kannst, mit dem iPhone alleine wird das etwas umständlich.

    Hier könntest du die App "iNetTools" installieren, um dein Netzwerk zu prüfen, aber mit einem Laptop wäre das viel einfacher.


    Es wird wohl im Netzwerk als DNS-Server die 10.255.254.1 vergeben und hier ist jetzt zu prüfen, ob die DNS-Auflösung auf diesen DNS-Server aus allen Netzwerken funktioniert. Das sollte eigentlich der Fall sein, aber du hast ja geschrieben, das einige Geräte den DNS-Server nicht erreichen können. Also ich würde erstmal mit einem Laptop prüfen, ob der DNS-Server aus allen Netzwerken erreichbar ist. Sollte das mit dem Laptop funktionieren, musst du dir die Geräte anschauen, die keine DNS-Auflösung können. Ist bei diesen Geräten wirklich die IP-Adresse 10.255.254.1 eingetragen, oder haben diese event. noch den alten DNS-Server eingetragen? Hier hilft es mal das betroffene Gerät neu zu starten, wenn es den so sein sollte.


    Aber erstmal prüfen, ob der DNS-Server generell aus allen Netzwerken funktioniert und dann weiterschauen.

    Wifi man habe ich in der Firma versucht, ich werde es zur Mittagspause nochmal zu Hause testen.


    habe default auch mal mit rein gepackt um einen vergleich zu ziehen.

    Okay, hat es den in der Firma mit dem Wifiman funktioniert und in welchem Netzwerk war das Gerät?

    Interessant wäre hier auch welche DNS-Server im Client eingetragen wurde.


    Man müsste das Problem mal einkreisen, in welchem Netzwerk wird welcher DNS-Server benutzt und wo funktioniert es und wo nicht.

    Wo es dann nicht funktioniert, muss man schauen, warum es nicht geht, ist eventl.. ein falscher DNS-Eintrag vorhanden oder liegt es

    am Routing, das der DNS-Server nicht erreichbar ist. Hast du irgendwelche Firewall-Regeln, die eventl. eine Verbindung verhindern?

    Manche gerate beklagen sich über ein unerreichbaren DNS server.

    Welcher DNS wird den bei den Geräten benutzt, zeigen die alle auf die UDM?

    Zeig doch mal die "DHCP DNS Server"-Einstellungen bei deinen drei Netzwerken Schütz Wlan, ioT und Schütz Lan?

    Klick hierfür bei den 3 Netzwerken auf "Show Option" bei "DHCP Service Management" und poste mal die Einstellungen hier.


    Meine Vermutung, warum der Wifiman nicht funktioniert, könnte daran liegen, das er den Wifiman-Server auf dem Gateway auf Port 8900 sucht.

    In dem Fall wäre das die L3-Switch, und da läuft kein Wifiman-Server. Wie das intern laufen könnte über die L3-Switch kann ich leider auch nicht beantworten.

    Update wurde bei mir gestern Nacht irgendwas um 1 Uhr rum angezeigt und auch gleich installiert :face_with_tongue:

    Nach gute 10 Minuten wurde automatisch ein Neustart durchgeführt und anschliessend gab es eine Mitteilung, das es noch ca. 5 Minuten dauern wird, bis es fertiggestellt ist. Naja, aus den 5 Minuten wurden gute 15 Minuten. Also hat das Updates ca. 25 Minuten gedauert, bis ich mich wieder einloggen konnte. Man muss die Nerven behalten nach dem reboot, irgendwann kommt dann der Login-Screen. :smiling_face_with_sunglasses:


    Ansonsten schaut alles soweit gut aus... :smiling_face:


    Und wann kommt jetzt die 3er Version für die UDM-Pro? :winking_face::thinking_face::grinning_squinting_face:

    Ich habe die bekanntesten Blocklisten von Spamhaus und co. in meiner Firewall drin.

    Aber nicht in der Unifi-Firewall oder? Wenn doch, würde mich interessieren, wie du dort die Listen einpflegst.



    PS: für die VPN Fetischistischen hier :face_with_tongue::grinning_face_with_smiling_eyes:

    auch die VPN Ports werden regelmäßig ab- bzw. ausgetestet!

    Ja, auch die Dienste sollten abgesichert werden :winking_face:


    Generell sollte ein Server nicht ohne Fail2Ban und entsprechender Infrastruktur im Netz betrieben werden.

    Genauso wie sichere Passwörter und 2FA.

    :thumbs_up:

    Tag täglich finden im Netz Angriffe statt. Hab mir mal den Spass gemacht und Fail2Ban visuell dazustellen. Hier das Ergebnis:


    Stellt sich die Frage, muss der Dienst überhaupt öffentlich bereitgestellt werden? Würde hier eventl. ein VPN-Zugang ausreichend sein und darüber den SSH-Zugriff zugänglich zu machen? Um so weniger Angriffsfläche um so besser.

    SSH-Zugang absichern ist immer gut, da fällt mir neben Fail2Ban noch weitere Möglichkeiten ein, wie z.b.

    • SSH-Port ändern
    • Kein Login mit Benutzername und Passwort, sondern nur über Keys
    • Sichere Einstellungen für KexAlgorithms, Ciphers, MACs und HostKeyAlgorithms, z.b. kein MD5, SHA1 oder CBC verwenden.
    • Root Login verbieten
    • X11Forwarding abschalten
    • SSH-Agent-Forwardings abschalten
    • Port-Forwardings abschalten
    • Aktive Verbindungen, die nicht genutzt werden automatisch ausloggen nach einem bestimmten Zeitraum
    • Nur bestimmten Benutzter erlauben eine SSH-Verbindung herzustellen
    • Max. Authentifizierungsversuche begrenzen
    • Authentifizierungsdauer begrenzen, wann eine Anmeldung abgeschlossen sein muss
    • Nicht benötigte Authentifizierungsmethoden deaktivieren, wie z.b. Kerberos, GSSAPI usw..
    • benutzerdefinierte Umgebungsvariablen deaktivieren, wenn diese nicht genutzt werden
    • SSH-Banner deaktivieren
    • SSH-Zugriff nur von bestimmten IP-Adressen zulassen


    Die aktuellen SSH-Server-Einstellungen können z.b. mit dem Python-Programm ssh-audit überprüft werden.

    Habt Ihr einen Tipp für einen einfach zu installierenden SYSLOG Server der ein entsprechendes Dashboard liefert?

    Ich benutze Graylog auf einem Ubuntu Server, der als LXC auf einem Proxmox Server läuft und bin damit sehr zufrieden.

    Die Installation war nicht sehr schwierig, ich bin nach dieser Anleitung https://go2docs.graylog.org/5-…/ubuntu_installation.html vorgegangen.


    Die Installation besteht aus folgenden Schritten:

    • MongoDB installieren
    • OpenSearch (das habe ich genommen) oder Elasticsearch installieren
    • Graylog installieren und konfigurieren

    Aber ob die Installation einfach ist, muss wohl jeder für sich selbst entscheiden, in der Anleitung ist eigentlich alles beschrieben, wenn man sich daran hält, sollte man es zum laufen bekommen.

    Schau dir mal Zammad oder auch OTOBO an:

    OTOBO Launch | Fork zur ((OTRS)) Community Edition
    Straubing 13.07.2020 - Launch OTOBO Helpdesk. Produktivstart für den neuen Open-Source-Helpdesk auf Basis der ((OTRS)) Community Edition. Jetzt teste
    otobo.de

    Helpdesk-Software & Ticketsystem für Ihr Business | Zammad
    Stärken Sie Ihren Support für einen besseren Service | Jetzt Produktivität steigern | Helpdesk-Software und Ticketsystem für Ihr Unternehmen | Zammad
    zammad.com

    Aber eigentlich sollte der GAST Port doch einfach ein "doofer" Port sein welcher einfach Internet weiterleitet.


    Ich glaube hier ist das Problem, ich habe keine Fritz!Box aktuell hier, um zu schauen.

    Aber ich meine mich zu erinnern, das der Gastzugang einen eigenen IP-Bereich und auch einen Filter sowas wie "alles außer Sufen und Mailen" hat, welcher alle anderen Ports sperrt. Schau mal in deine Fritz!Box, ich meine dort müsste es irgendwelche Zugangsprofile und Speerlisten geben, die du anpassen kannst.

    Ich habe schon eine IP/Port Gruppe (OW2-Overwatch) mit den entsprechenden Ports erstellt aber egal wie ich welche Firewall Regel "baue", kann sich mein PC nicht am BattleNet anmelden.


    Muss denn die Regel an WAN out gebaut werden, da mein PC ja auf die Ports im Internet zugreifen will? Sogar eine any any Regel hat nicht funltioniert.

    Ich stehe da echt auf dem Schlauch ....

    Normalweise ist die Firewall nach der Installation so eingestellt, das ein Endgerät überall eine Verbindung aufbauen kann.

    In der WAN out musst du eigentlich nichts extra dafür konfigurieren.

    Es kommt darauf an, welche Regeln du eingestellt hast und eventl. wird dort die Verbindung geblockt.

    Wenn du z.B. so etwas konfiguriert hast:


    Type: LAN In
    Action: Drop

    ipv4 Protokoll: All


    SOURCE

    Source Type: Network
    Network: Default

    Network Type: IPv4 Subnet


    DESTINATION

    Destination Type: Port/IP Group

    IPv4 Address Group: Any

    Port Group: Any


    Dann wird sich ein Gerät aus dem Default-Network nicht mit einer anderen IP-Adresse verbinden können, ausser dem Gateway selbst über "LAN Local", wenn du hier nichts konfiguriert haben solltest.


    Vielleicht wird die Verbindung auch durch eine "Country Restriktion" blockiert, wenn du hier etwas eingestellt haben solltest.


    Ohne deine Konfiguration zu kennen, wird es schwer hier etwas sagen zu können.

    Wenn ich den Switch Port auf die MAC Adresse des AccessPoint einschränke, können sich alle an dem AP angemeldeten Clients nicht anmelden.


    Wie kann ich mein Vorhaben realisieren?


    Sowas habe ich auch mal probiert, du müsstest zusätzlich zur AP-MAC-Adresse auch die MAC-Adressen der WLAN-Clients auf dem Port eintragen, damit diese eine Verbindung aufbauen können.

    Ich glaube, hier vertust du dich aber mit dem Zustand nach einem Stromausfall, oder :thinking_face:? Den gibt es bei Shelly auch, aber jkasten hat es auch geschrieben, dass man das Update wohl auch ohne Neustart des Shellys einzuspielen ist.

    :thinking_face: Über den Befehl "PowerOnState" kann man das einstellen, wie sich die Steckdose verhalten soll nach einem Stromausfall. Hierbei gibt es folgende Optionen:



    Was ich meinte, das man Updates installieren kann und das Gerät bleibt einfach in dem Zustand wie es aktuell ist, hier wird kein Schaltvorgang durchgeführt. Somit brauche ich mir auch keine Gedanken darüber machen, Updates wird eingespielt und das angeschlossene Gerät läuft weiterhin oder bleibt eben aus, je nach aktuellen Zustand.


    Oder meintest du jetzt etwas anderes? Jetzt bin ich verwirrt :winking_face:

    Das geht mittlerweile zumindest bei den Plug S ohne neustart, kann das Update also im laufenden Betrieb machen.


    Also nur als Info, wenn ich auf dem Nous ein Update installiere und das Ding neu startet, wird das angeschlossene Gerät dabei nicht vom Strom getrennt, somit können Updates zur jederzeit installiert werden. Es gibt eine entsprechende Einstellungen, wie sich das verhalten soll: immer aus, immer an, oder letzte Zustand.