Posts Tagged ‘Ubiquiti’

Sonntag, 28. März 2021

Mit gehärtetem SSH-Client kann man sich nicht mehr auf UniFi-Geräte einloggen

$ ssh us-8-60w
Unable to negotiate with 10.1.2.3 port 22: no matching MAC found. Their offer: hmac-sha1

Bummer. Ich musste meine gehärtete ~/.ssh/config folgendermassen abschwächen, um mich per SSH wieder auf den Access Point einloggen zu können:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-sha1
...

Siehe auch SSH Into Ubiquiti Access Point

Die lokal verfügbaren MACs zeigt man folgendermassen an:

$ $ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Auf einem UniFi Switch die Vitaldaten eines SFPs auslesen

Dieses Anliegen ist zum Glück deutlich besser dokumentiert als bei einem EdgeRouter ER-X-SFP, generell aber etwas komplizierter umgesetzt:

Nachdem man sich per SSH auf den UniFi Switch mit SFP-Modul eingeloggt hat, gibt man folgende Befehle ein:

# telnet localhost
(UBNT) >show fiber-ports optics all

                                    Output    Input
Port      Temp  Voltage  Current     Power    Power   TX     LOS
           [C]   [Volt]     [mA]     [dBm]    [dBm]   Fault
--------  ----  -------  -------   -------  -------   -----  ---
0/9       42.9    3.284     34.3    -5.983   -8.520   No     No

Quelle: SFP/SFP+ info on UniFi switches

Nachtrag

Um anzuzeigen, was genau für SFPs im Switch verbaut sind, verwendet man folgenden Befehl (Achtung, es handelt sich um einen anderen Switch als den obigen):

# swctrl sfp show
Port  Vendor Name      Serial Number    Part Number      Rev  Compliance
----  ---------------- ---------------- ---------------- ---- ----------------
   9  UBNT             X20061111111     UF-RJ45-1G       1.0  1000T           
  10  UBNT             X20061111112     UF-RJ45-1G       1.0  1000T

Quelle: Ubiquiti US-16-XG 10GbE switch command line

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Auf einem ER-X-SFP die Vitaldaten eines SFPs auslesen

Nirgends sauber dokumentiert, habe ich es nach einigen Stunden Recherche geschafft, die Temperatur, die Spannung, den Strom sowie die Sende- und Empfangsstärke eines in einem ER-X-SFP verbauten Fiber7-SFPs auszulesen:

/usr/sbin/ubnt-hal getSfp eth5
connector=LC
vendor=FLEXOPTIX       
oui=38-86-02
part=S.B1312.10.XDL  
rev=A   
serial=1234567
date=170110  
temp=67.601 C
voltage=3.23 V
current=17.03 mA
tx_power=0.15 mW
rx_power=0.23 mW
tx_fault=no
rx_los=no

Diesen goldenen Tipp erhielt ich von diesem Kommentar im Community-Thread Support for g.fast SPF. Was /usr/sbin/ubnt-hal sonst noch kann, ist im (leider seit 2013 nicht mehr aktualisierten) Artikel Undocumented EdgeOS commands beschrieben.

Wieso ich wusste, dass das geht? Im Router GUI werden diese Daten angezeigt, wenn man mit der Maus über den im Header graphisch dargestellten SFP-Port fährt. Das GUI holt diese Daten über die Websockets-Schnittstelle /ws/stats, welche von lighthttpd auf den Socket /tmp/ubnt.socket.statsd zeigt. Leider habe ich nicht herausgefunden, wie ich diesen Socket von der Kommandozeile aus ansprechen kann.

Tags: , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

Tags: , , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 30. Juni 2019

Irgendwas ist am UniFi Firmware 4.0.42.10433 nicht ganz koscher

Bis vor wenigen Wochen hatte ich nie irgendwelche Probleme mit Firmware-Upgrades für UniFi-Produkte. Das hat sich mit Version 4.0.42.10433 geändert: Ich verzeichne mindestens zwei Probleme mit diesem Upgrade.

DHCP funktioniert mit gewissen Geräten nicht mehr

Bei mir macht dieses Update auf einem UniFi AP-AC-Mesh wie auch auf einem UniFi AP-AC-LR im Zusammenspiel mit DHCP-Anfragen Probleme. Das Resultat: Die Geräte sind zwar im Controller sichtbar, können aber keine IP beziehen.

In der Controller-App für iOS sieht man bei solchen Geräten die Warnung:

„DHCP Timeout. Please check that your DHCP server is accessible and properly configured“

image-8417

Die meisten Geräte wie Laptops, Smartphones und Tablets können mit DHCP IPs beziehen; Probleme haben derzeit nur zwei Geräte(typen) gemacht: Ein Canon Selphy sowie ein Industrieboard für einen Wechselrichter. Meine derzeitige Vermutung: Auf diesen Dingern läuft eine ältere Linux-Version und ein älterer DHCP-Client, der irgendwie nicht (mehr) mit Antworten des DHCP-Servers über UniFi-Komponenten klarkommt, oder UniFi blockiert Antworten auf DHCP-Requests dieser Clients aus irgendeinem Grund.

Das zeigt sich daran, dass in den DHCP-Server-Logs unzählige folgende Meldungen auftauchen:

...
Jun 30 18:16:31 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:36 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:37 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:42 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:43 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:48 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:49 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:54 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:55 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:00 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:01 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:06 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:07 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:12 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:13 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:18 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:19 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:26:24 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
...

Syslog geflutet

Der UniFi AP-AC-Mesh an einem Standort brachte meinen ELK-Cluster für das Sammeln von Syslog-Meldungen aus allen Sites fast zum Glühen, nachdem die neue Firmware installiert war und der Access Point neu gebootet hatte.

Das Gerät sendete folgende Meldung 29 Mal pro Sekunde an den Syslog-Server:

<4> Jun 10 16:00:00 unifi.site.domain.local U7MSH,788a20263e00,v4.0.42.10433 kernel: [103146.842183] [wifi1] FWLOG: [105639111] VDEV_MGR_DEBID_DEFINITION_START ( 0x3, 0x40, 0x1, 0x6 )

Sobald ich wieder die alte Firmware (4.0.21.9965) installiert hatte, hörte die Log-Flut auf.

In Kibana ist die Flutwelle gut ersichtlich …

image-8418

… welche sich auch in der CPU-Auslastung wiederspiegelt:

image-8419

Auch Smokeping zeigt, dass das Gerät mit dem neuen Firmware eine deutlich höhere Latenz bei ICMP Ping Requests aufweist:

image-8420

Ein anderer Benutzer hatte dieses Phänomen bereits im März 2019 beobachtet und dies in einem Beitrag im offiziellen Support-Forum kundgetan: WAL_DBGID_SECURITY_ALLOW_DATA and VDEV_MGR_DEBID_DEFINITION_START — leider ohne Lösung.

Um das Problem ohne Downgrade des Firmwares zu beheben, habe ich meine rsyslog-Konfiguration, welche die Meldungen lokal in Empfang nimmt und an ELK weiterleitet, folgendermassen angepasst:

/etc/rsyslog.conf

...
# EMERGENCY 2019-06-10
if $msg contains 'VDEV_MGR_DEBID_DEFINITION_START' then {
    /dev/null
    stop
}

# Send all logs to ELK server
*.* @10.1.2.3:514
...

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 31. Mai 2018

Init7 TV7: Installation mit einem Ubiquiti Edgerouter X SFP

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

An einem Zweitstandort betreibe ich einen Ubiquiti Edgerouter X SFP (Firmware v1.10.0) mit einem offiziellen FlexOptix-Transceiver von Fiber7. Damit dieser Router IPTV-Multicast ins LAN weiterleitet, waren folgende Anpassungen an der Konfiguration nötig (hat mich 90 Minuten meines Lebens gekostet):

Firewall

Auf rudimentärem Deutsch: Lasse IGMP sowie Multicast UDP durch die Firewall gegen das Internet

...
firewall {
    ...
    name WAN_IN {
        ...
        rule 4 {
            action accept
            description "Allow IGMP (max)"
            log disable
            protocol igmp
        }
        rule 5 {
            action accept
            description "Allow Multicast"
            destination {
                address 224.0.0.0/4
            }
            log disable
        }
    }
    name WAN_LOCAL {
        ...
        rule 4 {
            action accept
            description "Allow IGMP"
            log disable
            protocol igmp
        }
        ...
    }
    ...
}
...

IGMP Proxy

Auf rudimentärem Deutsch: Empfange IGMP-Traffic aus dem Internet und leite ihn in das LAN weiter.

...
protocols {
    igmp-proxy {
        interface switch0 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
        interface eth5 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
    }
    ...
}

Multicast-Status abfragen

Um zu überprüfen, ob Multicast grundsätzlich funktioniert, loggt man sich per SSH auf den Router ein und gibt im CLI folgende Befehle ein:

$ show ip multicast interfaces 
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
switch0            0.00b             0       31.17MB         24316        Y.Y.Y.1
eth5             31.17MB         24316         0.00b             0   X.X.X.X
$ show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  Y.Y.Y.5        eth5        switch0               1       116.00b      1
239.255.255.250 Y.Y.Y.50       eth5        switch0              56       17.61KB     56
239.77.3.21     77.109.129.16    eth5        switch0           37379       47.91MB      0

Die letzte Zeile war das Resultat, dass ich probehalber Dracula Untold auf Film 4 geschaut habe …

Nachtrag 1: Stream friert ein

Nach der Installation der TV7-App auf dem Apple TV (eigener Blog-Artikel zur App) musste ich entdecken, dass das Bild eines TV-Senders jeweils nach etwas mehr als 3 Minuten einfror (ich tippte nach mehreren Messungen auf ein Timeout von 200 Sekunden — und somit ein strukturelles Problem).

Recht schnell realisierte ich nach etwas Googlen, dass die Firewall-Regel 4 unter WLAN_LOCAL zwingend auch aktiviert werden muss. Diese hatte ich ursprünglich als überflüssig erachtet. Mein Fehler.

Meine Vermutung als IPTV-Laie: Diese (zusätzliche) Regel erlaubt ausgehende IGMP-Pakete. Wenn diese nicht an TV7 gesendet werden können (Heartbeat?), stellt TV7 den Multicast wieder ein. Sobald die Firewall-Rule aktiviert wurde, entfror sich das Bild und die Sendung lief weiter.

Nachtrag 2: Multicast flutet das Netzwerk

Obwohl die Streams nun auf dem Apple TV mit der offiziellen App problemlos laufen, habe ich einen schwerwiegenden Nachteil entdeckt, welcher bei meinem Turris Omnia nicht auftritt: Schaut man mit dem Apple TV einen TV7-Stream, wird das ganze LAN mit Multicast-Paketen geflutet. Dies beeinflusst meinen UniFi Access Point besonders, konnte ich doch einen spürbaren Lag zwischen Tastendruck und Anzeige des Buchstabens auf dem Bildschirm feststellen, wenn ich von meinem MacBook per WLAN per SSH auf einem Laptop im LAN verbunden war.

In meiner derzeitigen Konfiguration sendet der Edgerouter den eingehenden Multicast-Traffic an alle LAN-Interfaces weiter, die am switch0 hängen. Leider habe ich bis jetzt noch keine Lösung gefunden, wie man das auf einzelne Ports einschränken kann (ich brauche eigentlich nur den Apple TV- sowie den Laptop-Port, auf welchem udpxy läuft) respektive wie man IGMP-Snooping aktivieren kann, damit der Edgerouter selber realisiert, welches Gerät/welche Geräte im Netzwerk aktuell gerade Multicast-Streams abspielen möchte.

image-7912

Links

Tags: , , , , , , , , , , ,
Labels: IT, Linux, Medien, Schweiz

4 Kommentare | neuen Kommentar verfassen

Samstag, 14. April 2018

Ein Backup oder eine alte Version einer Ubiquiti Edgerouter-Konfiguration einspielen

Ich habe bei Bekannten derzeit je ein Ubiquiti Edgerouter X in Betrieb, welche als Router an einem Kabelmodem angeschlossen sind.

Die Router habe ich so konfiguriert, dass sie bei jeder Aktualisierung der Konfiguration über das Web-GUI resp. das CLI ein Backup der vorherigen Konfiguration per TFTP auf einen Linux-Laptop im lokalen Netz ablegen. Dies mit der folgenden Konfiguration:

...
system {
    config-management {
        commit-archive {
            location tftp://10.1.2.3/
        }
        commit-revisions 10
    }
...
}
...

Gestern trat der Notfall ein, dass ich einen der Router komplett zurücksetzen musste und danach eine ältere Version der Konfiguration einspielen wollte.

Dies ist recht trivial: Auf dem Linux-Laptop, auf welchem die Konfiguration versioniert ist, kopiert man das Backup folgendermassen auf den auf Fabrikzustand zurückgesetzten Router:

$ scp config.boot-ROUTER.20180413_133604 ubnt@10.1.2.1:/config

Das Kennwort lautet ubnt und sollte in der so übermittelten Konfiguration zwingend angepasst werden.

Anschliessend verbindet man sich per SSH mit dem Router und führt folgende Befehle aus (compare ist nicht nötig, zeigt aber schön auf, welche Anpassungen zur derzeit aktiven Konfiguration vorgenommen werden):

$ configure
$ load /config/config.boot-ROUTER.20180413_133604
$ commit
[$ compare]
$ save

Quelle: Re: Swap X-SFP to Pro8 – can we upload config.boot from X-SFP?

Siehe auch: EdgeRouter – Archiving and Managing the Configuration Files — Saving and Loading Backup Configurations

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Ubiquiti Edgerouter und DynDNS hinter einem doppelten NAT

Kürzlich musste ich einen Ubiquiti Edgerouter ER-X temporär hinter einem doppelten NAT betreiben (dass das nicht optimal sein kann, weiss ja wohl jeder).

Obwohl DynDNS auf dem Edgerouter konfiguriert war, um den statischen Hostnamen mit der jeweils aktuellen dynamischen IP anzupassen, funktionierte dies in einer solchen Konfiguration nicht mehr: Der Router meldete seine private IP-Adresse (192.168.0.X) am WAN-Port an DynDNS, was natürlich nicht funktionieren kann.

Damit der Edgerouter in solchen Situationen zuverlässig die öffentliche IP-Adresse des Anschlusses verwendet, muss über das GUI unter Config Tree > service > dns > dynamic > interface > eth0 des Routers das Attribut web mit dem Wert dyndns ergänzt werden:

image-7799

Damit ist sichergestellt, dass der Router nicht die IP seines eth0-Interfaces zurückmeldet, sondern über den Web-Service von DynDNS seine öffentliche IP anfragt.

Wer das CLI bevorzugt:

$ configure
# set service dns dynamic interface eth0 web dyndns
# commit
# save

Quelle: Dynamic DNS behind double NAT?

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Freitag, 20. Oktober 2017

Ubiquiti hat seine Produkte gegen KRACK bereits gepatcht

More to the point, measure your current vendors by how long it takes them to patch. Throw away gear by those vendors that took a long time to patch and replace it with vendors that took a short time.

Quelle: Some notes on the KRACK attack

Im Januar 2016 habe ich meinen ersten Ubiquiti UniFi-Access Point gekauft und bin seither hell begeistert von den Produkten — bei mir kommt nur noch UniFi ins Haus, wenn es um die Versorgung eines Gebäudes mit WLAN geht. Mittlerweile habe ich solche Access Points an drei Standorten ausgerollt.

Als die Kunde von KRACK an die Öffentlichkeit gelangte, hatte ich die Hoffnung, dass Ubiquiti äusserst rasch reagieren würde.

Und das taten sie auch: Innert 24 Stunden standen aktualisierte Firmware-Dateien für die gesamte Produktepalette zum Download und zur manuellen Installation bereit.

Als ich mich heute auf den Controllern an den drei Standorten einloggte dann die frohe Botschaft im GUI des Controllers: Für alle meine Access Points stand Firmware 3.9.3.7537 zur automatisierten Installation bereit.

Das Bauchgefühl hat sich somit als richtig erwiesen: Der Hersteller baut nicht nur tolle Produkte, die man nie mehr hergeben möchte, sondern nimmt auch die Sicherheit seiner Software ernst und aktualisiert diese schnurstracks. Nach knapp zwei Minuten war das Upgrade vorüber und die Access Point frisch gegen KRACK gesichert.

Ubiquiti erhält das Sicherheits-Gütesiegel von mir. Wer es noch nicht getan hat: Kaufen!

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 7. Mai 2017

Ein Gästenetzwerk auf dem Ubiquiti EdgeRouter-X vom restlichen Netzwerk isolieren

Heute habe ich meinen ersten EdgeRouter-X in Betrieb genommen. Die Konfiguration war etwas gewöhnungsbedürftig, aber im Zusammenspiel mit Web-GUI und CLI hat es tatsächlich geklappt. Am meisten schätze ich, dass die Konfiguration des Routers eine simple Text-Datei ist, die man mit Subversion (oder: Git) versionieren kann und bei Bedarf mit ein paar Handgriffen für neue Umgebungen oder zusätzliche Installationen anpassen kann.

Da solche Ubiquiti-Geräte semi-professionelle Router und Switches sind, habe ich heute auch einen lang ersehnten Spezialfall umgesetzt: Am Installationsort teilen sich Vermieter und Mieter einen Internetanschluss. Der Vermieter möchte dabei aber dem Mieter aber eigentlich nur den Internetzugang ermöglichen und ihn aus dem heimischen LAN heraushalten.

Dies ist nicht sonderlich kompliziert, da der Mieter ein Ethernet-Kabel vom Router auf seinen Switch gezogen hat — es muss also einfach ein Faden geschützt werden.

Mit WLAN stellt man dies mit einer zweiten SSID sicher, die im UniFi-Controller als Gästenetzwerk konfiguriert wird. Auf Ethernet-Ebene ist es etwas komplizierter. Doch freundlicherweise hat sich ein geschätzter Zeitgenosse die Zeit genommen, genau diesen Use Case zu dokumentieren:

Setting up a guest network with the EdgeRouter Lite

Zwei kleine Anpassungen habe ich gemacht:

  1. Im DHCP-Server gebe ich als DNS die Server von Cablecom mit, weshalb sich aus meiner Sicht eine Firewall-Regel für internes DNS erübrigt.
  2. Als Privates Netz habe ich 192.168.1.0/24 gewählt und nicht 172.16.x.x.

Die Trennung mittels VLANs und Firewalls ist nun eingerichtet, aktiv und versioniert — leider konnte ich den Mieter aber noch nicht fragen, ob seine Geräte damit auch weiterhin funktionieren.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen