[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[nero355]

ardvark99 schreef op woensdag 1 mei 2019 @ 14:57:
Zoals ik al schreef, wanneer je gebruik maakt van het Guest profiel in de controller, worden er standaard firewall rules aangemaakt, die je niet kan bekijken of aanpassen in de controller. Misschien kan ik er een rule bij maken om DHCP wel door te laten. Ik ben er nog niet verder mee bezig geweest.

Ik had ooit in dit topic dus begrepen dat je het inderdaad op die manier kan aanpakken, maar ik kan het mis hebben...

[Comp User]

nero355 schreef op woensdag 1 mei 2019 @ 14:50:
[...]


[...]

Men moet echt kappen met alles vanuit een app te willen beheren!

Pak gewoon een PC of laptop erbij en open gewoon de UniFi Controller!


[...]


[...]

nero355 schreef op zondag 28 april 2019 @ 17:27:
[...]

Je moet je netwerk dan ook niet via WiFi vanuit een app beheren... de horror!

[...]

Je hebt volledig gelijk - voor degene die ooit bedacht heeft om het via een app te doen

Zogezegd omdat het "handig" zou zijn

[borft]

ardvark99 schreef op woensdag 1 mei 2019 @ 14:57:
[...]

Zoals ik al schreef, wanneer je gebruik maakt van het Guest profiel in de controller, worden er standaard firewall rules aangemaakt, die je niet kan bekijken of aanpassen in de controller. Misschien kan ik er een rule bij maken om DHCP wel door te laten. Ik ben er nog niet verder mee bezig geweest.

Ik zou even inloggen op de USG, dan kan je alle firewall rules zien en zo nodig aanpassen met een custom json

[ardvark99]

borft schreef op woensdag 1 mei 2019 @ 16:11:
[...]


Ik zou even inloggen op de USG, dan kan je alle firewall rules zien en zo nodig aanpassen met een custom json

Bedankt voor de tip, was mij wel bekend dat ik die firewall rules kon inzien via de USG config. Maar ik ga daar zeker ff naar kijken. Btw, wel mooi dat Ubiquiti gelijk alles inregeld voor de gebruiker wanneer bepaalde functionaliteit geactiveerd wordt, waarom het dan niet in te zien is, of zelfs niet aan te passen is, snap ik weer niet. Maak dit dan mogelijk wanneer de optie Enable advanced features aangevinkt is. Aanpassingen in de controller is het risico zo wie zo voor de gebruiker. Markeer het desnoods als let op, systeem configuratie oid.

[Nindustries]

Ik heb de Unifi AP Pro met de PoE injector gp-h480-050g, maar deze lijkt op 100mbit te blijven steken.
Als ik de AP rechtstreeks op de (vorige) router aansloot, lag deze mooi op gigabit.
Router interface staat op auto-negotiate.

Nog ideetjes om te debuggen? Ik heb al kabels zitten verwisselen, en de injector zou gigabit moeten zijn.

[ Voor 6% gewijzigd door Nindustries op 01-05-2019 17:26 ]

[Wafeltje]

ardvark99 schreef op woensdag 1 mei 2019 @ 16:36:
[...]

Bedankt voor de tip, was mij wel bekend dat ik die firewall rules kon inzien via de USG config. Maar ik ga daar zeker ff naar kijken. Btw, wel mooi dat Ubiquiti gelijk alles inregeld voor de gebruiker wanneer bepaalde functionaliteit geactiveerd wordt, waarom het dan niet in te zien is, of zelfs niet aan te passen is, snap ik weer niet. Maak dit dan mogelijk wanneer de optie Enable advanced features aangevinkt is. Aanpassingen in de controller is het risico zo wie zo voor de gebruiker. Markeer het desnoods als let op, systeem configuratie oid.

Vallen deze regels in de controller niet gewoon onder:
Routing & Firewall > Firewall > Rules IPv4 > GUEST IN / GUEST OUT / GUEST LOCAL?

Toegegeven, je kunt niet zien of het op bepaalde poorten wel/niet wordt doorgelaten, want je ziet niets qua source/destination, en je kunt niet op edit klikken.

Dat het niet te wijzigen is snap ik wel, want dan kunnen zij niets meer garanderen. Dan zul je een corporate vlan aan moeten maken en zelf al die regels in stellen, en er dus zelf een guest vlan van maken.

[Capa]

Nindustries schreef op woensdag 1 mei 2019 @ 17:21:
Ik heb de Unifi AP Pro met de PoE injector gp-h480-050g, maar deze lijkt op 100mbit te blijven steken.
Als ik de AP rechtstreeks op de (vorige) router aansloot, lag deze mooi op gigabit.
Router interface staat op auto-negotiate.

Nog ideetjes om te debuggen? Ik heb al kabels zitten verwisselen, en de injector zou gigabit moeten zijn.

Kan je de poort van de router niet hard op 1000 mbit zetten?

[GioStyle]

ardvark99 schreef op woensdag 1 mei 2019 @ 13:23:

-knip-

Succes, en ik hoor graag jouw bevindingen @GioStyle .

Ik heb jouw instellingen in mijn netwerk toegepast en het werkt!

Ik heb nog wel een vraagje: in je eerste post heb je bij 'DHCP Relay' instellingen de 'hop count', 'maximum packet size' en 'listen and transmit port' ingevuld. In je tweede post zeg je dat je deze instellingen leeg heb gelaten. Ik heb het nu leeg gelaten. Ik neem aan jij nu ook?

In mijn geval moet ik nog alleen stoeien met firewall rules (zodat bepaalde vlan's niet met elkaar kunnen communiceren) en dan is onderhand mijn netwerk alweer 'af'.

Mocht ik in de komende weken problemen tegenkomen, dan tag ik je in deze topic.

[Cyleo]

Ik heb sinds kort een USG welke een oude DD-WRT router vervangt. Om het direct goed aan te pakken heb ik daarnaast een pi-hole server geïnstalleerd, welke werkt als DNS voor de USG zoals hieronder:

ISP->USG->Switch->Server (/w Pihole, Unifi Controller)

Nu wil de server nog wel eens bokken, dus ik wil niet dat de server/pihole zowel DHCP als DNS doet, daarom is er in de USG ook een alternatieve DNS. Nu heb ik echter het volgende ding: ik wil graag mijn server en een aantal andere apparaten kunnen bereiken via *.local domeinnamen. De /etc/hosts file van de USG gaat voor die van de pihole, en beter ook, want daar draait de DHCP server en deze is gekoppeld aan het MAC adres.

Echter, ik krijg het niet voor elkaar om ieder apparaat een goede alias te geven. Als ik bijvoorbeeld naar mijn versterker wil navigeren zou ik graag naar DN860.local gaan, maar dit lijkt niet te werken, terwijl ik die wel als alias heb opgegeven. Ik weet dat er een backup is om de pihole te gebruiken, maar dat is niet mijn voorkeur.

Aangezien ik vast niet de enige ben die local aliassen wil gebruiken vroeg ik mij af hoe jullie dit hebben opgelost.

[Yoshimi]

Bloemstukje schreef op woensdag 1 mei 2019 @ 11:53:
Als ik mijn netwerk scan, krijg ik een IP adres met een vreemde naam te zien; "HeartOfGold" . Heb het internet al afgestruind, maar kan niks vinden. Iemand enig idee wat dit zou kunnen zijn?

[Afbeelding]

Zie je dit apparaat ook terug in je controller bij 'Known Clients'?
Of heb je toevallig een apparaat van iemand overgenomen, dat later opgenomen en geconfigureerd in je eigen netwerk, maar heeft het nog een IP lease van .212?
De optie die @nero355 noemt is altijd goed, zo kom je in elk geval meer te weten welke poorten open staan en kun je op die manier eventueel ontdekken wat het voor apparaat is.

[ardvark99]

GioStyle schreef op woensdag 1 mei 2019 @ 18:26:
[...]

Ik heb jouw instellingen in mijn netwerk toegepast en het werkt!

Ik heb nog wel een vraagje: in je eerste post heb je bij 'DHCP Relay' instellingen de 'hop count', 'maximum packet size' en 'listen and transmit port' ingevuld. In je tweede post zeg je dat je deze instellingen leeg heb gelaten. Ik heb het nu leeg gelaten. Ik neem aan jij nu ook?

In mijn geval moet ik nog alleen stoeien met firewall rules (zodat bepaalde vlan's niet met elkaar kunnen communiceren) en dan is onderhand mijn netwerk alweer 'af'.

Mocht ik in de komende weken problemen tegenkomen, dan tag ik je in deze topic.

In de eerste post heb ik het idd daar over gehad, maar mijn laatste post zijn de instellingen zoals het nu werkt. Ik had op het UBNT forum een paar posts gevonden waarbij gezegd werd dat die waardes niet ingevuld moesten worden. Na veel zoeken ben ik qua instellingen hierop wat wijzer geworden, zoals dat DHCP Guarding uit moet staan, en DHCP Relay ook aan moet staan op het LAN netwerk waarop de DHCP server draait. Jammer dat er niet echt uitgebreide handleidingen op de site van UBNT te vinden zijn waarin alle instellingen uitgebreid toegelicht worden. Sommige topics worden wel goed toegelicht, maar geen echte knowledgebase.

Maar mooi dat het bij jou ook werkt.

Wafeltje schreef op woensdag 1 mei 2019 @ 18:17:
[...]
Vallen deze regels in de controller niet gewoon onder:
Routing & Firewall > Firewall > Rules IPv4 > GUEST IN / GUEST OUT / GUEST LOCAL?

Toegegeven, je kunt niet zien of het op bepaalde poorten wel/niet wordt doorgelaten, want je ziet niets qua source/destination, en je kunt niet op edit klikken.

Dat het niet te wijzigen is snap ik wel, want dan kunnen zij niets meer garanderen. Dan zul je een corporate vlan aan moeten maken en zelf al die regels in stellen, en er dus zelf een guest vlan van maken.

Klopt, daar zijn die firewall rules te vinden. Maar ik ga eens kijken hoe ik dit ga oplossen. Komt goed

[nero355]

Cyleo schreef op woensdag 1 mei 2019 @ 18:49:
Ik wil graag mijn server en een aantal andere apparaten kunnen bereiken via *.local domeinnamen.

Echter, ik krijg het niet voor elkaar om ieder apparaat een goede alias te geven. Als ik bijvoorbeeld naar mijn versterker wil navigeren zou ik graag naar DN860.local gaan, maar dit lijkt niet te werken, terwijl ik die wel als alias heb opgegeven.

Aangezien ik vast niet de enige ben die local aliassen wil gebruiken vroeg ik mij af hoe jullie dit hebben opgelost.

.local is eigenlijk een gereserveerde extensie die je onder andere makkelijk kan gebruiken door Multicast DNS aan te zetten op een apparaat!

Wil je thuis een domein draaien dan zou ik lekker iets pakken als .lan of .thuis.lan om conflicten of ongewenste effecten te voorkomen!

Wat ik zou voorstellen is gewoon de /etc/hosts van Pi-Hole gebruiken en dan je Pi-Hole setup op deze manier redundant maken : https://discourse.pi-hole...-pihole-ive-done-it/12716

[Nindustries]

Capa schreef op woensdag 1 mei 2019 @ 18:21:
[...]


Kan je de poort van de router niet hard op 1000 mbit zetten?

Neen, via the web gui enkel 10mbit half/full of 100mbit half/full.
Via cli wel, maar dat zie ik niet zitten. Want als auto-negotiate al niet werkt, waarom zou het forceren dan wel werken?

Ik heb er een topic over op ubnt: https://community.ubnt.co...9/highlight/false#M390643

[mindcre8r]

Heeft iemand de ervaring dat na het opkomen van een ACpro de snelheid goed is maar dat deze naar verloop van tijd degrade?
ik heb 2 accespoints waarvan 1 van ziggo in de connectbox, die heeft me de volle snelheid (600mbit) maar de ACpro kakt dus in na een aantal uren / dagen (niet exact gemeten)

[Xtince]

Annuk schreef op zondag 28 april 2019 @ 11:32:
[...]


Als je een laptop hebt met een gewone Gbit netwerk kaart kan je mogelijk ook ff makkelijker checken.
• Wifi-kaart uitschakelen
• De patchkabel tussen switch en patchpaneel in je laptop doen om te checken of je laptop direct Gbit verbinding geeft
• Zelfde testje als hierboven met het stukje kabel wat je op zolder gebruikt om te checken of die direct Gbit geeft. (Dan heb je de 2 patchkabels alvast uitgesloten)
• Dan op zolder je laptop verbinden per kabel, geeft die ook direct Gbit dan zit het met de kabel in 9/10 gevallen vaak wel goed (natuurlijk geen 100% uitsluiting, maar als je laptop direct Gbit maakt zonder al te lang bezig te zijn, zijn de kabels vaak wel goed).
• Zijn de kabels wel goed dan je AP's wisselen (kijk even welke makkelijker te verwisselen is, de Pro v/d beneden verdieping of de Lite van de 1e verdieping, en wissel die met zolder).

Zo deed/doe ik vaak even snelle test als ik bij iemand kabeltje had getrokken en bijv. geen kabeltester o.i.d. bij me had (en in de tijd voor ik een nette kabeltester had).

Het lag blijkbaar aan de kabel op zolder naar de ap. Deze vervangen en tot nu toe geen problemen meer gehad.

Wat ik wel heb is het volgende. Ik had een abo van 200mb van ziggo. Tot vorige week heb ik deze snelheid gewoon gehaald met de ap’s. Echter vanaf deze week is de abo gratis verhoogd naar 250mb, maar haal sindsdien maar 140mb bij de ap’s. Kan dit liggen aan de ap/instellingen in ubiquiti of gaat er iets mis bij ziggo?

[borft]

Xtince schreef op donderdag 2 mei 2019 @ 14:41:
[...]


Het lag blijkbaar aan de kabel op zolder naar de ap. Deze vervangen en tot nu toe geen problemen meer gehad.

Wat ik wel heb is het volgende. Ik had een abo van 200mb van ziggo. Tot vorige week heb ik deze snelheid gewoon gehaald met de ap’s. Echter vanaf deze week is de abo gratis verhoogd naar 250mb, maar haal sindsdien maar 140mb bij de ap’s. Kan dit liggen aan de ap/instellingen in ubiquiti of gaat er iets mis bij ziggo?

140 milibit is vrij weinig, en ook geen snelheid. Ik neem aan dat je 140 Mb/s bedoelt

Sluit even een laptop oid met een kabel direct op het modem aan, draai een speedtest en je weet het. Als je dan wel 250 Mbps haalt, ligt het mogelijk aan je wifi. Vragen dan zijn:
- gebruik je 2.4GHz of 5 GHz?
- welke snelheid gebruikt je wifi?
- als je meet, weet je zeker dat er geen andere clients actief zijn?

[nero355]

Xtince schreef op donderdag 2 mei 2019 @ 14:41:
Het lag blijkbaar aan de kabel op zolder naar de ap. Deze vervangen en tot nu toe geen problemen meer gehad.

Mooi!

Wat ik wel heb is het volgende. Ik had een abo van 200mb van ziggo. Tot vorige week heb ik deze snelheid gewoon gehaald met de ap’s. Echter vanaf deze week is de abo gratis verhoogd naar 250mb, maar haal sindsdien maar 140mb bij de ap’s. Kan dit liggen aan de ap/instellingen in ubiquiti of gaat er iets mis bij ziggo?

Hoe heb je die snelheden gemeten ?!

Bedenk wel dat als je speedtest.net gebruikt je dus ook buiten je netwerk meet en daar kan al een heleboel heel snel veranderen zonder dat je het door hebt...

Wat ik altijd zou doen is het volgende :
- Snelheid met iPerf3 meten tussen een bekabelde en draadloze client.
- Snelheid met SMB/Windows File Sharing meten tussen een bekabelde en draadloze client.

Zo blijf je altijd binnen je eigen netwerk en zorg je ervoor dat daar alles goed is getest!

Wat Ziggo dan verder doet op hun veel te drukke backbones en brakke DNS servers is dan niet jouw probleem

[Hindelaufen]

Shaggie_NB schreef op zondag 28 april 2019 @ 19:04:
[...]

Je kunt de amplifi als router of als bridge installeren. In jouw geval zou ik hem als bridge installeren.
1. Open the AmpliFi app.
2. Tap the picture of the Router.
3. Tap Internet.
4. Tap Bridge Mode to enable it.
5. Confirm the use of bridge mode.

Off Topic maar toch

@nero355 & @Shaggie_NB

Persoonlijk vind ik het vervelend als mensen om hulp vragen, hulp krijgen en om vervolgens nooit meer iets van zich te laten horen.
Dat is ook zeker niet mijn bedoeling hier. Echter ik ben niet meer bij mijn zus langs geweest -ver weg- en zij moet het zelf doen. Ze is echter niet zo enthousiast als ik geen Tweaker -ik sta er desnoods midden in de nacht voor op om nieuwe settings uit te proberen- dus zaken hebben een zekere vertraging.
Maar "I keep you posted"

Nogmaals dank.

[Amaze86]

Zouden jullie voor de Ubiquiti UniFi AP-AC-LR of de PRO versie gaan?

Heb de Ubiquiti UniFi AP-AC-LR gekocht maar twijfel om die terug te sturen,vooral omdat de PRO versie 2 poorten heeft.Mocht ik in de toekomst een mediaplayer erop aansluiten in me slaapkamer dan is het mooi meegenomen.

Twijfel twijfel,kost iets meer.

[RobertMe]

Amaze86 schreef op donderdag 2 mei 2019 @ 22:38:
Zouden jullie voor de Ubiquiti UniFi AP-AC-LR of de PRO versie gaan?

Heb de Ubiquiti UniFi AP-AC-LR gekocht maar twijfel om die terug te sturen,vooral omdat de PRO versie 2 poorten heeft.Mocht ik in de toekomst een mediaplayer erop aansluiten in me slaapkamer dan is het mooi meegenomen.

Twijfel twijfel,kost iets meer.

Tsja, de extra poort kan natuurlijk een goede reden zijn om voor de Pro te zijn. Echter kun je als het alleen daarom gaat ook kijken naar de AC In-Wall. Deze heeft namelijk twee ingebouwde poorten en een "echte" switch, waar de tweede poort van de AC Pro in bridge werkt, en ik meen zelfs begrepen te hebben dat die zelfs "offline" gaat tijdens een firmware update.

Voor de snelheid zal het ook niet uit maken of je voor een AC LR of een AC IW gaat. Want je wilt altijd/zoveel mogelijk gebruik maken van 5GHz en zowel de AC LR als AC IW hebben in die band 2 antennes. En de vraag is ook of je de extra antenne van de LR in de 2,4GHz band daadwerkelijk gaat merken. De LR versie is namelijk voornamelijk bedoeld voor grote (open) ruimtes zoals bv een bedrijfshal. In een thuissituatie met allemaal muren valt het voordeel dus (grotendeels) weg.

De AC Pro ondersteund dan weer wel hogere snelheden door zowel 3 antennes in de 2,4GHz band als de 5GHz band. Maar je clients moeten dan weer ook 3x3 MIMO ondersteunen.

[burne]

Hindelaufen schreef op donderdag 2 mei 2019 @ 16:40:
[...]

Persoonlijk vind ik het vervelend als mensen om hulp vragen, hulp krijgen en om vervolgens nooit meer iets van zich te laten horen.

Pas op met dat oordeel: veel mensen bedanken je in een PM, en dat ziet niemand, behalve jij en 'hullie'.

Er is meer dan fake internet points (zegt de ouwe lul 'hero' met 'godlike'-karma..).

[nero355]

RobertMe schreef op donderdag 2 mei 2019 @ 22:46:
Tsja, de extra poort kan natuurlijk een goede reden zijn om voor de Pro te zijn. Echter kun je als het alleen daarom gaat ook kijken naar de AC In-Wall. Deze heeft namelijk twee ingebouwde poorten en een "echte" switch, waar de tweede poort van de AC Pro in bridge werkt, en ik meen zelfs begrepen te hebben dat die zelfs "offline" gaat tijdens een firmware update.

In-Wall serie FTW!!! inderdaad

Voor de snelheid zal het ook niet uit maken of je voor een AC LR of een AC IW gaat. Want je wilt altijd/zoveel mogelijk gebruik maken van 5GHz en zowel de AC LR als AC IW hebben in die band 2 antennes. En de vraag is ook of je de extra antenne van de LR in de 2,4GHz band daadwerkelijk gaat merken. De LR versie is namelijk voornamelijk bedoeld voor grote (open) ruimtes zoals bv een bedrijfshal. In een thuissituatie met allemaal muren valt het voordeel dus (grotendeels) weg.

De AC Pro ondersteund dan weer wel hogere snelheden door zowel 3 antennes in de 2,4GHz band als de 5GHz band. Maar je clients moeten dan weer ook 3x3 MIMO ondersteunen.

Er is ook nog de pricewatch: Ubiquiti UniFi In-Wall HD als snelheid of nog meer LAN poorten een eis zijn

Maar ik zou lekker die In-Wall AC "Lite" zeg maar kopen : Goedkoper en werken gewoon prima!

[Xtince]

nero355 schreef op donderdag 2 mei 2019 @ 16:29:
[...]

Mooi!

[...]

Hoe heb je die snelheden gemeten ?!

Bedenk wel dat als je speedtest.net gebruikt je dus ook buiten je netwerk meet en daar kan al een heleboel heel snel veranderen zonder dat je het door hebt...

Wat ik altijd zou doen is het volgende :
- Snelheid met iPerf3 meten tussen een bekabelde en draadloze client.
- Snelheid met SMB/Windows File Sharing meten tussen een bekabelde en draadloze client.

Zo blijf je altijd binnen je eigen netwerk en zorg je ervoor dat daar alles goed is getest!

Wat Ziggo dan verder doet op hun veel te drukke backbones en brakke DNS servers is dan niet jouw probleem

De snelheden heb ik gemeten met zowel speedtest als de wifi tester in de unifi controller. Maar vanavond heb ik gemerkt dat ik opeens 250mb/s haal met de ap’s. Schommelt dus heen en weer.

[Amaze86]

@RobertMe Heb wel erg goede wifi bereik met die LR zelfs op me 3e verdieping,en me huis is uit 2008.

Zal is die in-wall ook bestellen.

[Qualixo]

Nindustries schreef op woensdag 1 mei 2019 @ 17:21:
Ik heb de Unifi AP Pro met de PoE injector gp-h480-050g, maar deze lijkt op 100mbit te blijven steken.
Als ik de AP rechtstreeks op de (vorige) router aansloot, lag deze mooi op gigabit.
Router interface staat op auto-negotiate.

Nog ideetjes om te debuggen? Ik heb al kabels zitten verwisselen, en de injector zou gigabit moeten zijn.

Er zit een reset switch op de onderkant, een paperclip pin hole. al eens gebruikt?
Heb er eventueel nog 3 liggen als je er een wilt testen om te kijken of die van jouw gammel is

[ Voor 8% gewijzigd door Qualixo op 03-05-2019 07:59 ]

[Nindustries]

Qualixo schreef op vrijdag 3 mei 2019 @ 07:58:
[...]


Er zit een reset switch op de onderkant, een paperclip pin hole. al eens gebruikt?
Heb er eventueel nog 3 liggen als je er een wilt testen om te kijken of die van jouw gammel is

Bedankt, ik heb beta upgrade en reset uigeprobeert.
Uiteindelijk bleek dat eth4 op mijn Edgerouter X SFP niet hoger als 100mbit kon gaan, geRMAt en nu werkt alles

[Typhone]

Zo nu ben ik wel redelijk bekend met Unifi (al gaat het technische deel veelal met tutorials) maar ik ben op zoek naar de best practice solution voor het volgende:

NAS moet gebruik gaan maken van een dedicated VPN verbinding. Is het verstandiger dat op de NAS zelf te doen of is het verstandiger dat via een VLAN te doen binnen Unifi (kan dat überhaupt op deze manier?). Het betreft gewoon een NAS met vaste LAN aansluiting. Verbinding met de VPN moet 24/7 aanwezig zijn.

[m3gA]

Typhone schreef op vrijdag 3 mei 2019 @ 09:47:
Zo nu ben ik wel redelijk bekend met Unifi (al gaat het technische deel veelal met tutorials) maar ik ben op zoek naar de best practice solution voor het volgende:

NAS moet gebruik gaan maken van een dedicated VPN verbinding. Is het verstandiger dat op de NAS zelf te doen of is het verstandiger dat via een VLAN te doen binnen Unifi (kan dat überhaupt op deze manier?). Het betreft gewoon een NAS met vaste LAN aansluiting. Verbinding met de VPN moet 24/7 aanwezig zijn.

Ik zou een site to site vpn opzetten op de USG.

[ASS-Ware]

Cyleo schreef op woensdag 1 mei 2019 @ 18:49:
Ik heb sinds kort een USG welke een oude DD-WRT router vervangt. Om het direct goed aan te pakken heb ik daarnaast een pi-hole server geïnstalleerd, welke werkt als DNS voor de USG zoals hieronder:

ISP->USG->Switch->Server (/w Pihole, Unifi Controller)

Nu wil de server nog wel eens bokken, dus ik wil niet dat de server/pihole zowel DHCP als DNS doet, daarom is er in de USG ook een alternatieve DNS. Nu heb ik echter het volgende ding: ik wil graag mijn server en een aantal andere apparaten kunnen bereiken via *.local domeinnamen. De /etc/hosts file van de USG gaat voor die van de pihole, en beter ook, want daar draait de DHCP server en deze is gekoppeld aan het MAC adres.

Echter, ik krijg het niet voor elkaar om ieder apparaat een goede alias te geven. Als ik bijvoorbeeld naar mijn versterker wil navigeren zou ik graag naar DN860.local gaan, maar dit lijkt niet te werken, terwijl ik die wel als alias heb opgegeven. Ik weet dat er een backup is om de pihole te gebruiken, maar dat is niet mijn voorkeur.

Aangezien ik vast niet de enige ben die local aliassen wil gebruiken vroeg ik mij af hoe jullie dit hebben opgelost.

Device1.local, Device2.local, etc?
Waar is de domeinnaam?

Maak in je DNS server een zone aan, bijvoorbeeld home.local, registreer daar je apparaten in.
Dan zijn je apparaten bereikbaar op device.home.local.
Overigens is iets als .lan beter dan .local, ik heb eens gelezen dat Apple devices niet zo van .local houden.

[borft]

ASS-Ware schreef op vrijdag 3 mei 2019 @ 11:16:
[...]

Device1.local, Device2.local, etc?
Waar is de domeinnaam?

Maak in je DNS server een zone aan, bijvoorbeeld home.local, registreer daar je apparaten in.
Dan zijn je apparaten bereikbaar op device.home.local.
Overigens is iets als .lan beter dan .local, ik heb eens gelezen dat Apple devices niet zo van .local houden.

de .local postfix is onderdeel van mdns (zie bv https://en.wikipedia.org/wiki/Multicast_DNS), die kan je daar dus beter niet voor gebruiken. Vaak is het handiger om dan een eigen tld te verzinnen.

[ Voor 4% gewijzigd door borft op 03-05-2019 13:09 ]

[nero355]

@ASS-Ware @borft : nero355 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"

[ed1703]

borft schreef op vrijdag 3 mei 2019 @ 13:08:
[...]


de .local postfix is onderdeel van mdns (zie bv https://en.wikipedia.org/wiki/Multicast_DNS), die kan je daar dus beter niet voor gebruiken. Vaak is het handiger om dan een eigen tld te verzinnen.

Voor zover ik weet zijn die multicast schreeuwomjeheen domeintjes allemaal *iets*._tcp.local
Kans dat je hiermee bijt is minimaal. Op al mijn apple-devices heb ik er geen last van. Maar device.local is not-done. Daar moet wel een domein in zitten. Is ook niet zo handig, als je wilt afkorten door te zoeken in het domein hebben we daar search-domain voor uitgevonden binnen DHCP/Resolving op je systemen.

[borft]

ed1703 schreef op vrijdag 3 mei 2019 @ 13:23:
[...]

Voor zover ik weet zijn die multicast schreeuwomjeheen domeintjes allemaal *iets*._tcp.local
Kans dat je hiermee bijt is minimaal. Op al mijn apple-devices heb ik er geen last van. Maar device.local is not-done. Daar moet wel een domein in zitten. Is ook niet zo handig, als je wilt afkorten door te zoeken in het domein hebben we daar search-domain voor uitgevonden binnen DHCP/Resolving op je systemen.

de kans is 100% er zijn dan twee verschillende systemen die hetzelfde tld beheren, zonder dat er communicatie over is.

Daarnaast kan ik me zo voorstellen dat sommige devices, bv Apple devices, helemaal geen dns requests doen voor hostnames in het .local domein. En dan werkt het dus niet.

Ik gebruik thuis bv als alternatief .lan en dat werkt prima. Ansich zou .local ook kunnen werken, ware het niet, dat het bij conventie al ergens anders voor gebruikt wordt. Er is helemaal geen reden waarom een fqdn uit 3 delen zou moeten bestaan.

[ed1703]

borft schreef op vrijdag 3 mei 2019 @ 13:29:
[...]


de kans is 100% er zijn dan twee verschillende systemen die hetzelfde tld beheren, zonder dat er communicatie over is.

Daarnaast kan ik me zo voorstellen dat sommige devices, bv Apple devices, helemaal geen dns requests doen voor hostnames in het .local domein. En dan werkt het dus niet.

Ik gebruik thuis bv als alternatief .lan en dat werkt prima. Ansich zou .local ook kunnen werken, ware het niet, dat het bij conventie al ergens anders voor gebruikt wordt. Er is helemaal geen reden waarom een fqdn uit 3 delen zou moeten bestaan.

Tja, als 'admin's' zich niet inlezen hoe dns via .local gebruikt dient te worden wat ik net uitleg, dan stopt elke discussie wel een beetje. Er zijn genoeg best-practice documenten te vinden hoe je .local dient te gebruiken. Er is wel degelijk een reden waarom je FQDN uit 3 delen moet bestaan, omdat je vaak een herkenbare scheiding wilt maken tussen bijvoorbeeld mgmt.local en thuis.local. Het is vooral netter en herkenbaar en met vlan-scheiding zoals multi-home/proeftuin/testomgeving/etc/etc ook gewoon wel nodig. Natuurlijk werkt device.lan ook, net als dat device.home ook werkt, maar .local is zeer zeker niet totaal onbruikbaar. Iemand die gewend is vanuit het werk al met domeinen te werken, doen dat thuis namelijk ook en die .local-conflicten met mdns zijn zeer eenvoudig op te lossen.

Overigens klopt mijn opmerking over mdns niet, het is wel degelijk device.local, maar dat terzijde.

[ Voor 11% gewijzigd door ed1703 op 03-05-2019 13:59 ]

[llagendijk]

ed1703 schreef op vrijdag 3 mei 2019 @ 13:23:
[...]

Voor zover ik weet zijn die multicast schreeuwomjeheen domeintjes allemaal *iets*._tcp.local
Kans dat je hiermee bijt is minimaal. Op al mijn apple-devices heb ik er geen last van. Maar device.local is not-done. Daar moet wel een domein in zitten. Is ook niet zo handig, als je wilt afkorten door te zoeken in het domein hebben we daar search-domain voor uitgevonden binnen DHCP/Resolving op je systemen.

Zie bijv. http://cr.yp.to/djbdns/dot-local.html voor suggesties, bijv. internal. De kans dat dat ooit als top level domain wordt gebruikt lijkt me klein. Echt perfecte suggesties zijn er niet, Misschien je achternaam als die geen verwarring met een TLD kan gaan opleveren?
Gebruik .local in ieder geval niet: dat is voor MDNS en geeft zeker met Apple spul problemen.
Of misschien een echte domainnaam kopen en gebruiken? Dan moet er echter wel iets in dat domain staan wat wijst naar een machine (web-server of mail-server).

[ed1703]

llagendijk schreef op vrijdag 3 mei 2019 @ 21:50:
[...]

Zie bijv. http://cr.yp.to/djbdns/dot-local.html voor suggesties, bijv. internal. De kans dat dat ooit als top level domain wordt gebruikt lijkt me klein. Echt perfecte suggesties zijn er niet, Misschien je achternaam als die geen verwarring met een TLD kan gaan opleveren?
Gebruik .local in ieder geval niet: dat is voor MDNS en geeft zeker met Apple spul problemen.
Of misschien een echte domainnaam kopen en gebruiken? Dan moet er echter wel iets in dat domain staan wat wijst naar een machine (web-server of mail-server).

Ik zou echte domeinnamen lekker beperkt houden tot iets wat bij een hostingpartij zit. .lan .1 .2 is dan wel beter. Waarbij ik .lan nog de mooiste oplossing vind.
Een echte domeinnaam zorgt weer voor andere issues met mx-records en dichtzittende smtp-poorten en dat je zaken soms dubbel moet gaan opvoeren voor intern en extern. Hebben wij op het bedrijf wel ooit gehad en het zorgt soms voor nog grotere problemen als in een aantal gevallen met mdns.
Mail zou ik verder dan regelen met een smarthost oid.

Maargoed, back to Ubiquiti.

Versie 2.03 is uit voor de Edgerouter, maar heeft gelijk last van freezing webinterface.
Voor de X en X-SFP is deze niet uitgekomen ivm corrupt filesysteem.

https://community.ubnt.co...een-released/td-p/2770958

Verder zijn met Unifi beta 4.0.35 voor Wifi/SW de 100FX-autosense problemen opgelost en is dan ook te installeren. Volgens mij heeft stable daar geen last van, maar een aantal betaversies terug wel.

https://community.ubnt.co...p-to/first-unread-message

[ Voor 7% gewijzigd door ed1703 op 04-05-2019 16:28 ]

[burne]

llagendijk schreef op vrijdag 3 mei 2019 @ 21:50:
[...]

Gebruik .local in ieder geval niet: dat is voor MDNS en geeft zeker met Apple spul problemen.

Ik moet er even in duidelijk, maar een EdgeRouter heeft ook een mDNS-daemon aan boord, maar die wil niet zonder meer starten:

code:

root@ubnt:~# /etc/init.d/avahi-daemon start
[FAIL] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon failed!

Het voordeel van mDNS is dat het zichzelf configureert en dat ook aanpast als er dingen veranderen. Het heet niet voor niets 'zeroconf'. Mijn printer is te vinden voor alles wat mDNS doet, door te zoeken naar devices in de klasse 'printers', mijn NAS door de zoeken naar devices in de klasse 'storage'. Het feit dat m'n printer nog wel eens een ander IP krijgt van DHCP maakt niet uit voor mDNS.

[ed1703]

burne schreef op zaterdag 4 mei 2019 @ 16:36:
[...]


Ik moet er even in duidelijk, maar een EdgeRouter heeft ook een mDNS-daemon aan boord, maar die wil niet zonder meer starten:

code:

root@ubnt:~# /etc/init.d/avahi-daemon start
[FAIL] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon failed!

Het voordeel van mDNS is dat het zichzelf configureert en dat ook aanpast als er dingen veranderen. Het heet niet voor niets 'zeroconf'. Mijn printer is te vinden voor alles wat mDNS doet, door te zoeken naar devices in de klasse 'printers', mijn NAS door de zoeken naar devices in de klasse 'storage'. Het feit dat m'n printer nog wel eens een ander IP krijgt van DHCP maakt niet uit voor mDNS.

Ik weet echt niet wat UBNT met de MDNS in unifi heeft gedaan, maar zodra ik Philips Hue laat overhoppen qua mdns via VLANS en m'n iPhone is aanwezig in het netwerk, gaat m'n Philips Hue om de paar uur herstarten. Als ik het uitzet in de VLAN-config en ik zit in hetzelfde VLAN 0,0 problemen. Dus dat heb ik maar lekker laten zitten.

[ChUcKiE]

[...]

Sonos apparaten zijn sowieso raar dus daar kan ik je niet mee helpen, maar alsjeblieft...

Sluit die printer gewoon bedraad aan!

De printer is nu bedraad aangesloten en (uiteraard) zijn hier de problemen weg. Wel blijf ik problemen met mijn SONOS houden. Het valt op, dat met name de apparaten die op 2,4Ghz soms raar doen.
Zou daar een instelling kunnen zitten die ik verkeerd heb staan en die dat veroorzaakt?

En het stomme is, het heeft altijd in deze opstelling goed gewerkt tot zeg een maand geleden.

[ Voor 9% gewijzigd door ChUcKiE op 05-05-2019 07:57 ]

[Comp User]

ed1703 schreef op zaterdag 4 mei 2019 @ 16:25:
[...]


Versie 2.03 is uit voor de Edgerouter, maar heeft gelijk last van freezing webinterface.
Voor de X en X-SFP is deze niet uitgekomen ivm corrupt filesysteem.

https://community.ubnt.co...een-released/td-p/2770958

Beta firmware zo te zien - ik blijf nog wel even op 1.10.9, dat is zo te lezen de betere optie.

[iMars]

Een misschien wel heel simpele vraag, maar ik wil het toch zeker weten

Kan je met een "domme" unmanaged switch ook een gastennetwerk opzetten? Of moet je echt een managed switch hebben voor de vlans?

[RobertMe]

iMars schreef op zaterdag 4 mei 2019 @ 19:28:
Een misschien wel heel simpele vraag, maar ik wil het toch zeker weten

Kan je met een "domme" unmanaged switch ook een gastennetwerk opzetten? Of moet je echt een managed switch hebben voor de vlans?

Gaat het dan puur om de APs? Zo ja, dat kan zonder VLANs. Als je bij een Wireless network de Apply guest policies checkbox aanzet wordt op het AP (o.a.) de firewall geactiveerd die vanaf het gast netwerk alle verkeer naar private subnets (dus 192.168.0.0/16 etc) blokkeert. Scheiding met VLANs is dan dus ook niet nodig

Daarnaast helpen VLANs ook niet 100%. Bij bedrade gasten kun je niet afdwingen dat verkeer alleen internet op moet en niet naar andere apparaten binnen het VLAN. Dit omdat de switch geen soortgelijke firewall heeft en dus domweg wel van 192.168.x.10 naar 192.168.x.11 etc kan switchen. Daarop is dan weer wel een oplossing in de vorm van PVLAN / Private VLAN waarbij de switch het verkeer altijd naar de router stuurt, en daar zal het dan wel door de firewall rules van de router heen gaan. Maar PVLAN zit helaas (nog?) niet in de UniFi lijn. De EdgeSwitches ondersteunen dat volgens mij weer wel.

[OMX2000]

RobertMe schreef op zaterdag 4 mei 2019 @ 19:42:
[...]

Gaat het dan puur om de APs? Zo ja, dat kan zonder VLANs. Als je bij een Wireless network de Apply guest policies checkbox aanzet wordt op het AP (o.a.) de firewall geactiveerd die vanaf het gast netwerk alle verkeer naar private subnets (dus 192.168.0.0/16 etc) blokkeert. Scheiding met VLANs is dan dus ook niet nodig

Daarnaast helpen VLANs ook niet 100%. Bij bedrade gasten kun je niet afdwingen dat verkeer alleen internet op moet en niet naar andere apparaten binnen het VLAN. Dit omdat de switch geen soortgelijke firewall heeft en dus domweg wel van 192.168.x.10 naar 192.168.x.11 etc kan switchen. Daarop is dan weer wel een oplossing in de vorm van PVLAN / Private VLAN waarbij de switch het verkeer altijd naar de router stuurt, en daar zal het dan wel door de firewall rules van de router heen gaan. Maar PVLAN zit helaas (nog?) niet in de UniFi lijn. De EdgeSwitches ondersteunen dat volgens mij weer wel.

Port isolation kan voorkomen dat er tussen clients gecommuniceerd wordt.

[RobertMe]

OMX2000 schreef op zaterdag 4 mei 2019 @ 20:38:
[...]


Port isolation kan voorkomen dat er tussen clients gecommuniceerd wordt.

Volgens mij voorkomt port isolation alleen broadcast verkeer, maar zorgt het niet ervoor dat alle verkeer via de router (en dus firewall) loopt. Dat was in ieder geval mijn conclusie na wat onderzoek een paar maanden terug.

[burne]

OMX2000 schreef op zaterdag 4 mei 2019 @ 20:38:
[...]


Port isolation kan voorkomen dat er tussen clients gecommuniceerd wordt.

Ik citeer 'm nog maar even:

Ports that are protected cannot forward traffic to other protected ports, regardless of the VLAN membership. However, protected ports can forward traffic to unprotected ports. Unprotected ports can forward traffic to both protected and unprotected ports.

En voor de duidelijkheid: we hebben het hier over layer-2 verkeer. Wat dit doet is je broadcast-domain kleiner maken. Waarom je dit wilt is dat als je 2000 telefoons en laptops in een VLAN hebt je niet voor iedereen apart alle broadcast af wil handelen, omdat dat ook door de lucht moet. Het zorgt ervoor dat je laptop niet te vinden is voor die meneer met een iPhone omdat de mDNS beacons niet bij hem aankomen. (Maar wel op je router en op overgebleven 'unprotected' poorten.)

Wat er op layer 3 gebeurt is aan je router.

[boomer21]

Heb 2 unifi switches en geen usg. Kan ik dan 4 vlans in de controller programmeren en dan 2 vlans op 1 poort
Van de switch doen?

[GioStyle]

boomer21 schreef op zaterdag 4 mei 2019 @ 21:30:
Heb 2 unifi switches en geen usg. Kan ik dan 4 vlans in de controller programmeren en dan 2 vlans op 1 poort
Van de switch doen?

Kortgezegd: ja.

Je moet dan volgens mij een groep aanmaken.

[ed1703]

OMX2000 schreef op zaterdag 4 mei 2019 @ 20:38:
[...]


Port isolation kan voorkomen dat er tussen clients gecommuniceerd wordt.

Voor dit soort zaken heb je toch echt private vlans nodig.

Private vlan isolated, kan niet onderling communiceren maar wel met de uplink

Private vlan community, kan onderling communiceren en met uplink. Daarin kun je overigens ook meerdere communitys in configureren.

Zoals @RobertMe al aangeeft niet beschikbaar op Unifi maar wel op de edgeline.

[boomer21]

GioStyle schreef op zaterdag 4 mei 2019 @ 21:37:
[...]


Kortgezegd: ja.

Je moet dan volgens mij een groep aanmaken.

Weet iemand hoe je 2 vlans in een groep krijgt?

[RobertMe]

boomer21 schreef op zaterdag 4 mei 2019 @ 21:45:
[...]


Weet iemand hoe je 2 vlans in een groep krijgt?

Uit mijn hoofd: settings => profiles => port profiles. Daar een nieuw profiel aanmaken en dan alleen die twee VLANs aanvinken. Uiteraard wel eerst een (VLAN only) network aanmaken. Daarna kun je de switch openen, port(s) editten en je nieuwe profiel selecteren.

[boomer21]

RobertMe schreef op zaterdag 4 mei 2019 @ 21:55:
[...]

Uit mijn hoofd: settings => profiles => port profiles. Daar een nieuw profiel aanmaken en dan alleen die twee VLANs aanvinken. Uiteraard wel eerst een (VLAN only) network aanmaken. Daarna kun je de switch openen, port(s) editten en je nieuwe profiel selecteren.

Mooi dank je ga proberen

[Quakie]

Om te leren en het beter te begrijpen ben ik een paar dagen geleden begonnen met VLANs.
Via de edgerouter heb ik VLAN20 aangemaakt voor IoT.
Nu heb ik mijn Chromecast verplaatst naar de VLAN en de meeste apps (youtube app niet) vinden hem via normale LAN. Ik kan dus netjes iets starten.. Nu wil ik uiteraard firewall rules erbij hebben en daar gaat het mis.

Ik heb dus VLAN 20 (eth1.20) IN rule set aangemaakt die standaard alles accepteert.
Met een paar rules:
1. Allow Established Related all protocols accept destination local lan
2. Allow Pihole DNS op mijn Synology NAS accept tcp udp port 53
3. Allow Plex op mijn Synology NAS accept tcp udp port 32400
4. Block IoT to LAN all protocols naar local lan

Helaas werkt dit dus niet. Als ik rule 4 disable werkt het en kan ik via Infuse op mijn iPhone iets starten op de chromecast. Ik zou zeggen dat rule3 er voor moet zorgen dat dit ook werkt als rule 4 actief is.

Wat mis ik hier? Het liefst geef ik alles vrij richting mijn Synology NAS. Ik heb all protocols naar ip van Synology gedaan maar dat werkt ook niet...

[TheMystery]

Quakie schreef op zondag 5 mei 2019 @ 11:07:
Om te leren en het beter te begrijpen ben ik een paar dagen geleden begonnen met VLANs.
Via de edgerouter heb ik VLAN20 aangemaakt voor IoT.
Nu heb ik mijn Chromecast verplaatst naar de VLAN en de meeste apps (youtube app niet) vinden hem via normale LAN. Ik kan dus netjes iets starten.. Nu wil ik uiteraard firewall rules erbij hebben en daar gaat het mis.

Ik heb dus VLAN 20 (eth1.20) IN rule set aangemaakt die standaard alles accepteert.
Met een paar rules:
1. Allow Established Related all protocols accept destination local lan
2. Allow Pihole DNS op mijn Synology NAS accept tcp udp port 53
3. Allow Plex op mijn Synology NAS accept tcp udp port 32400
4. Block IoT to LAN all protocols naar local lan

Helaas werkt dit dus niet. Als ik rule 4 disable werkt het en kan ik via Infuse op mijn iPhone iets starten op de chromecast. Ik zou zeggen dat rule3 er voor moet zorgen dat dit ook werkt als rule 4 actief is.

Wat mis ik hier? Het liefst geef ik alles vrij richting mijn Synology NAS. Ik heb all protocols naar ip van Synology gedaan maar dat werkt ook niet...

Heb je mdns ook aanstaan voor vlan 20?

[Quakie]

@TheMystery sorry ja mDNS staat aan

[TheMystery]

Quakie schreef op zondag 5 mei 2019 @ 11:26:
@TheMystery sorry ja mDNS staat aan

Misschien UDP 5353 voor mdns in de firewall open zetten.

[Yoshimi]

Quakie schreef op zondag 5 mei 2019 @ 11:07:
Om te leren en het beter te begrijpen ben ik een paar dagen geleden begonnen met VLANs.
Via de edgerouter heb ik VLAN20 aangemaakt voor IoT.
Nu heb ik mijn Chromecast verplaatst naar de VLAN en de meeste apps (youtube app niet) vinden hem via normale LAN. Ik kan dus netjes iets starten.. Nu wil ik uiteraard firewall rules erbij hebben en daar gaat het mis.

Ik heb dus VLAN 20 (eth1.20) IN rule set aangemaakt die standaard alles accepteert.
Met een paar rules:
1. Allow Established Related all protocols accept destination local lan
2. Allow Pihole DNS op mijn Synology NAS accept tcp udp port 53
3. Allow Plex op mijn Synology NAS accept tcp udp port 32400
4. Block IoT to LAN all protocols naar local lan

Helaas werkt dit dus niet. Als ik rule 4 disable werkt het en kan ik via Infuse op mijn iPhone iets starten op de chromecast. Ik zou zeggen dat rule3 er voor moet zorgen dat dit ook werkt als rule 4 actief is.

Wat mis ik hier? Het liefst geef ik alles vrij richting mijn Synology NAS. Ik heb all protocols naar ip van Synology gedaan maar dat werkt ook niet...

Ik zou je adviseren het andersom te doen en je LAN toegang te geven tot je IOT VLAN en verkeer andersom te blokkeren (of in elk geval de nodige restricties op te leggen).

Probeer het volgende eens:
LAN_IN
1. Allow established/related - accept all (state established, related, geen source + destination opgeven)
2. Drop invalid - drop all (state invalid, geen source + destination opgeven)
3. Allow Plex - accept tcp udp, (source network IOT, destination Plex Server, port 32400)
4. Allow LAN to IOT - accept all (source network LAN, destination network IOT)
Optioneel: 5. Drop inter-VLAN traffic - drop all (source RFC1918 subnets, destination RFC1918 subnets). <- hiermee blokkeer je inter-VLAN verkeer en dien je middels allow regels het benodigde verkeer toe te staan. Ik heb deze regel zelf actief, maar natuurlijk wel eerst geïnventariseerd wat ik aan rules nodig had

LAN_LOCAL
1. Allow IOT mDNS - accept UDP (source: je mDNS clients, port 5353 UDP, destination 224.0.0.251, poort 5353)
2. Allow IOT DNS - accept TCP+UDP (source network IOT, destination pi-hole, port 53)
3. Allow IOT DHCP - accept UDP (source network IOT, destination port 67)
4. Drop all IOT traffic - drop all (source network IOT, destination alle RFC1918 subnetten)

Misschien dat deze video's je helpen:
YouTube: EdgeRouter IoT/Guest Network Isolation
YouTube: Secure IoT Network Configuration

[ Voor 8% gewijzigd door Yoshimi op 05-05-2019 18:03 ]

[Quakie]

@TheMystery @Yoshimi Thx ik ga hiermee stoeien. Wel grappig. Beide YouTube videos gezien en ik gebruik dus 1op1 die van crosstalk. Wat dus niet werkt..

[Falcon10]

ed1703 schreef op zaterdag 4 mei 2019 @ 16:25:
[...]

Maargoed, back to Ubiquiti.

Versie 2.03 is uit voor de Edgerouter, maar heeft gelijk last van freezing webinterface.
Voor de X en X-SFP is deze niet uitgekomen ivm corrupt filesysteem.

Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
Versta me niet verkeerd, ben zelf meer dan tevreden met hoe het bij mij loopt, opgezet is kunnen worden etc, maar komt er vooral op neer vind ik : als je het in werking hebt gekregen ( wat normaal zonder al te veel problemen/vrij simpel lukt ), blijf er daarna met je fikken vanaf, want met bijna elke firmware/software upgrade komen er daarna misschien wel problemen voor.
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....
Goed, op prijs en al win je het van die jongens, maar op vlak van degelijke software patches.
En afhankelijk van je werkgever ofzo, zijn die niet mals op gebied van stabiliteit van dat soort zooi.
Afhankelijk van het soort netwerk ben je verplicht om minstens jaarlijks, 3 maandelijks of zelfs maandelijks firmware/software updates te installeren ivm security. Lollig werkje hoor als elke paar maand je switchen terug mag restoren omdat de laatste software update van hen in jou config weer een boel dingen niet meer laat werken.

Zelf tevreden over Ubiquiti voor bij me thuis, maar op men werk heb ik toch maar voor Netgear Prosafe switchen gekozen.

[ed1703]

Falcon10 schreef op maandag 6 mei 2019 @ 06:36:
[...]


Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
....
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....
Goed, op prijs en al win je het van die jongens, maar op vlak van degelijke software patches.

Goed.. even resumerend..

Je denkt bij Cisco beter af te zijn:

3750-24G: Versie 12.2 SEE4v.*blablanogwat: Switches crashen op het moment de je in configuration mode naar de interface ging bij een uptime langer dan 50-60 dagen.

3750V2-24PS: ipbase 150 SE2: memoryleak, switches crashen na 150-200 dagen uptime.
Leuk hoor als je een remotesite alle stacks met zo'n 400 gebruikers op dezelfde dag hebt geinstalleerd/vervangen .. !
Uiteindelijk hebben we alle stacks naar SE4 moeten brengen, zo'n 5000 devices in totaal, leuk werkje. Gelukkig hebben we daar tools voor die dat deels automatiseren.

3850-24SE: Verie 15.2(3)E4: Crashing core-switches als deze gestacked zijn en je vervolgens een laag2 VLAN gaat toevoegen. Laag3 interface toevoegen kreeg ik niet eens de kans voor. want gelijk freeze van m'n ssh sessie. Spanning-tree in een loop (waarom geen idee) en uiteindelijk een reboot van de switch waarop je het VLAN hebt toegevoegd. Daarna kwam alles weer tot rust. Bij niet gestacked zijn deze problemen er niet. U weet wel, die stackkits van cisco waar je tegenwoordig ook al voor moet bijbetalen.
Oplossing is in de maak, maar we kunnen op onze omgevingen met honderden lokaties in het land niet "zomaar" upgraden.

Aankomende vrijdag ga ik een omgeving met 19 switches installeren (nieuwe site) voor zo'n 350 man. Kosten 80.000 euro. Veel plezier met je Cisco-Gear. (Dan hebben wij zelfs nog tientallen procenten korting)

Dus nee, ben het niet met je eens

Software heeft nu eenmaal bugs. Ubiquiti heeft de boel voor een aantal versies ook teruggetrokken. Heel goed dus. Probleem van Ubiquiti is ook nog dat het leunt op Vyatta, terwijl het misschien met zoveel apparatuur beter is om in-house zelf iets met vyatta als source te gaan ontwikkelen, waardoor je ook beter kunt sturen op je bugs. Geen idee of ze dat nu al doen, maar als dat met 2.x het geval is, leveren ze gewoon slecht werk af. Freezing interface behoort gewoon tijdens tests naar voren te komen.

[ Voor 3% gewijzigd door ed1703 op 06-05-2019 07:45 ]

[RobertMe]

Falcon10 schreef op maandag 6 mei 2019 @ 06:36:
[...]


Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
Versta me niet verkeerd, ben zelf meer dan tevreden met hoe het bij mij loopt, opgezet is kunnen worden etc, maar komt er vooral op neer vind ik : als je het in werking hebt gekregen ( wat normaal zonder al te veel problemen/vrij simpel lukt ), blijf er daarna met je fikken vanaf, want met bijna elke firmware/software upgrade komen er daarna misschien wel problemen voor.
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....
Goed, op prijs en al win je het van die jongens, maar op vlak van degelijke software patches.
En afhankelijk van je werkgever ofzo, zijn die niet mals op gebied van stabiliteit van dat soort zooi.
Afhankelijk van het soort netwerk ben je verplicht om minstens jaarlijks, 3 maandelijks of zelfs maandelijks firmware/software updates te installeren ivm security. Lollig werkje hoor als elke paar maand je switchen terug mag restoren omdat de laatste software update van hen in jou config weer een boel dingen niet meer laat werken.

Zelf tevreden over Ubiquiti voor bij me thuis, maar op men werk heb ik toch maar voor Netgear Prosafe switchen gekozen.

Correct me if I'm wrong, maar 2.0 is officieel wel stable, maar volgens mij is het ook bekend dat het dat (verre van) is en als je echt stabiliteit wilt wordt v.z.i.w. ook aangeraden om op de 1 serie te blijven. Beetje hetzelfde als bij UniFi waar ze ook verschillende versies nog ondersteunen en er nu zelfs nog een stable candidate van de 5.6 controller loopt.

Overigens ben ik het er wel mee eens dat iets als een niet werkende WebUI toch wel mag blijken uit interne tests, maar zoals @ed1703 zegt houd je de kans op bugs altijd. En als je het risico op bugs (enorm) wilt verkleinen blijf je dus op de v1 firmware totdat is gebleken dat 2.0 echt stabiel is en alle kinderziektes eruit zijn.

[Falcon10]

Hoi Ed,


Ik ga niet zeggen dat Cisco slecht is of ook geen bugs heeft, maar hun bugs lijken op een ander niveau te zitten. Bij bedrijf waar ik werk hebben ze Cisco's, en om de x aantal tijd hebben ze daar inderdaad ook dat er eens een switch spontaan een reboot geeft, maar das inderdaad om het half jaar ofzo, verveldn, maar zou ik nog mee kunnen leven
Thuis met men Ubiquiti, elke keer ik een update doe, doe ik toch een beetje crossfingers omdat je al niet 100% zeker bent dat je apperatuur terug up komt na de reboot. En je vervolgens wat mag gaan klooien.
Nu moet ik zeggen dat ik dat zelf nog maar 1x voorgehad heb, en mooi snel opgelost gekregen dmv de hulp hier op het forum, maar je leest hier toch bijna bij elke software update dat hier op het forum toch wel altijd iemand problemen heeft met/na de update. Dat vind ik toch verontrustend dat voor een beperkt aantal Ubiquiti gebruikers, er toch bijna altijd problemen voordoen, bij "gewone" updates.

En nogmaals, versta me niet verkeerd : heel blij over het Ubiquiti spul, maar heb toch het gevoel dat er iets nog niet 100% goed loopt voordat men nieuwe updates vrijgeeft.

[burne]

ed1703 schreef op maandag 6 mei 2019 @ 07:37:
[...]
Goed.. even resumerend..

Je denkt bij Cisco beter af te zijn:

3750-24G: Versie 12.2 SEE4v.*

Bedoel je echt de IOS 12.2 uit 2004? Dat is redelijk antiek..

[Falcon10]

Je wil niet weten wat voor antiek spul ik hier al heb zien rondslingeren : nog oude 2960's, zelfs 2950's en hou je vast op 1 locatie effectief nog een 1924 in dienst !

[ed1703]

burne schreef op maandag 6 mei 2019 @ 09:05:
[...]

Bedoel je echt de IOS 12.2 uit 2004? Dat is redelijk antiek..

Ohja, ik had het ook over de 3750G (uitgebracht in 2003 als het goed is) die tot 2012 dacht ik in de support zat, waarvan 12.2 in 2004 inderdaad gestopt is en je naar 15.0 moest (of 12.3, ben ik even kwijt, mijn geheugen is niet meer wat het geweest is). Volgens mij hadden ze ook niet eens stackwise. (het was dus even een voorbeeld hoe slecht cisco het soms voor elkaar heeft)
Dan heb ik een vollopende /var/log op Nexus 5000 / 7000 nog niet eens hier neergekalkt waardoor je geen logs meer kon inzien (bug uit 2014).. Ook erg fijn.

Falcon10 schreef op maandag 6 mei 2019 @ 08:45:
Dat vind ik toch verontrustend dat voor een beperkt aantal Ubiquiti gebruikers, er toch bijna altijd problemen voordoen, bij "gewone" updates.
En nogmaals, versta me niet verkeerd : heel blij over het Ubiquiti spul, maar heb toch het gevoel dat er iets nog niet 100% goed loopt voordat men nieuwe updates vrijgeeft.

Tja, een beperkt aantal gebruikers. Datzelfde idee heb ik nu met Cisco ook. Wat het allemaal niet beter/slechter maakt. Of we gaan een discussie starten over de hardware, wat Cisco met mijlen wint tov UBNT. Hoe dan ook kun je als leverancier niet met *alles* rekening houden, hoe gek dat ook klinkt. Het is ook gewoon onmogelijk om alle cases te testen. Dus of het Cisco, Juniper, Netgear of UBNT is, ze hebben allemaal bugs. De ene is vervelender dan de ander. Feit is wel dat het niet perse meer is met UBNT dan met Cisco, maar je projecteert de zaak op je eigen installatie omdat je er daadwerkelijk last van hebt.
(Er zijn er ook die nergens last van hebben namelijk.)
Zo heb ik ook gezien dat er gebruikers zijn die na een USG-update last hebben van een continue herstartende USG omdat een bepaalde setting binnen de config.gateway.json verplaatst was naar de userinterface. Zelf geen last to note en ook ik heb voor testdoeleinden (OSPF en DNAT met mijn Edge-speeltuintje) zaken in de config.gateway.json staan.

Soms lezen admins de release-notes ook niet goed, ook al meerdere keren gezien op het ubnt-forum.
Zoals dit bijvoorbeeld: UAP, UAP-LR, UAP-IW, UAP-OD and UAP-OD5 cannot be downgraded from firmware 4.0.17+ to an earlier release.

[ Voor 70% gewijzigd door ed1703 op 06-05-2019 09:39 ]

[MisteRMeesteR]

Falcon10 schreef op maandag 6 mei 2019 @ 09:11:
Je wil niet weten wat voor antiek spul ik hier al heb zien rondslingeren : nog oude 2960's, zelfs 2950's en hou je vast op 1 locatie effectief nog een 1924 in dienst !

Ha!

Ik heb in mijn beheerde omgeving nog een heuse 3550!

EOS 2006

[boomer21]

Falcon10 schreef op maandag 6 mei 2019 @ 06:36:
[...]


Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
Versta me niet verkeerd, ben zelf meer dan tevreden met hoe het bij mij loopt, opgezet is kunnen worden etc, maar komt er vooral op neer vind ik : als je het in werking hebt gekregen ( wat normaal zonder al te veel problemen/vrij simpel lukt ), blijf er daarna met je fikken vanaf, want met bijna elke firmware/software upgrade komen er daarna misschien wel problemen voor.
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....
Goed, op prijs en al win je het van die jongens, maar op vlak van degelijke software patches.
En afhankelijk van je werkgever ofzo, zijn die niet mals op gebied van stabiliteit van dat soort zooi.
Afhankelijk van het soort netwerk ben je verplicht om minstens jaarlijks, 3 maandelijks of zelfs maandelijks firmware/software updates te installeren ivm security. Lollig werkje hoor als elke paar maand je switchen terug mag restoren omdat de laatste software update van hen in jou config weer een boel dingen niet meer laat werken.

Zelf tevreden over Ubiquiti voor bij me thuis, maar op men werk heb ik toch maar voor Netgear Prosafe switchen gekozen.

Wat kan je doen als je dit overkomt als huis tuin en keuken gebruiker? ( en wil het verkomen )
1 eerst backup
2 update firmware
3 als niet werkt met update ( ik als gebruiker weet niet alle instellingen meer)
4 oude firmware terug zetten ( weet niet als het kan)
4 restore
5 later uit vinden wat je moet doen om de instellingen aan te passen op de nieuwe firmware

[ed1703]

MisteRMeesteR schreef op maandag 6 mei 2019 @ 09:18:
[...]

Ha!

Ik heb in mijn beheerde omgeving nog een heuse 3550!

EOS 2006

Ik had hier ergens in een stoffig vergeten deel van een DC tot vorig jaar een 2950-24 uit 2001. Die hebben we na een uptime van 13 jaar maar eens uitgefaseerd en de ook deels onbelangrijke patchkabelzooi maar naar een 3650 verplaatst

[MdBruin]

@Quakie Je gaat nu net de foute kant op net als Yoshimi ook al aangaf.

Denk als volgt, wie vraagt om de informatie/pakketje en hoe krijgt deze het.
Cliënt -> firewall/router -> source

In jouw geval vraagt de Chromecast om het pakketje aan je Synology (DNS en plex)

Bij jouw firewall regels heb je een IN en een OUT rule set als in het goed interpreteer. De IN rule is voor het overige verkeer wat pakketje naar het VLAN stuurt en de OUT voor het VLAN wat pakketje naar het overige.

[ZaZ]

Deze gebruik ik altijd tijdens het configureren van firewall e.d. Retehandig.

[ardvark99]

ZaZ schreef op maandag 6 mei 2019 @ 10:06:
[Afbeelding]

Deze gebruik ik altijd tijdens het configureren van firewall e.d. Retehandig.

Thanks, ben de afgelopen dagen bezig om de firewall onder de knie te krijgen. Heb ook al diverse YouTube films bekeken. Alle info is welkom

[furian88]

heren,

ongetwijfeld dat dit al wel eens voorbij is gekomen.. ik zou niet weten waar ik op moet zoeken zonder heel veel resultaten te krijgen.

Ik heb afgelopen weekend een 2e AP toegevoegd aan mijn netwerk.
1e ap is een AC-PRO
2e ap is een NANO-HD

beide werken feilloos en ik ben er heel tevreden mee.
Wat ik echter nog tegen aan loop is het automatisch overzetten van clients naar de andere AP.

ik zie nu devices met een lage snelheid verbinding maken naar de AP die juist het verste weg staat.
Staat ergens nu nog iets verkeerd of zie ik iets over het hoofd waardoor de AP's dit niet automatisch doen?

radio instellingen NANO-HD:

2G
HT20
channel 1
transmit low

5G
VHT80
channel 36
transmit high

Bandsteering prefer 5G

radio instellingen AC-PRO:

2G
HT20
channel 11
transmit low

5G
VHT80
channel 48
transmit high

Bandsteering prefer 5G

[ Voor 6% gewijzigd door furian88 op 06-05-2019 11:08 ]

[RobertMe]

furian88 schreef op maandag 6 mei 2019 @ 10:38:
heren,

ongetwijfeld dat dit al wel eens voorbij is gekomen.. ik zou niet weten waar ik op moet zoeken zonder heel veel resultaten te krijgen.

Ik heb afgelopen weekend een 2e AP toegevoegd aan mijn netwerk.
1e ap is een AC-PRO
2e ap is een NANO-HD

beide werken feilloos en ik ben er heel tevreden mee.
Wat ik echter nog tegen aan loop is het automatisch overzetten van clients naar de andere AP.

ik zie nu devices met een lage snelheid verbinding maken naar de AP die juist het verste weg staat.
Staat ergens nu nog iets verkeerd of zie ik iets over het hoofd waardoor de AP's dit niet automatisch doen?

radio instellingen NANO-HD:

2G
HT20
channel 1
transmit low

5G
VHT80
channel 36
transmit high

Bandsteering prefer 5G

radio instellingen AC-PRO:

2G
HT20
channel 11
transmit low

5G
VHT80
channel 48
transmit high

Bandsteering prefer 5G

Op welke band verbinden die clients? Kan ook zijn dat je op 5GHz al voldoende hebt aan medium en je nu met high teveel overlap creeerd. Of juist dat het domme clients zijn (IoT device bv) die vasthouden aan het AP waarmee ze ooit hebben verbonden en daardoor blijven verbinden met de AC Pro terwijl de AC NanoHD korter bij is.

[furian88]

RobertMe schreef op maandag 6 mei 2019 @ 11:26:
[...]

Op welke band verbinden die clients? Kan ook zijn dat je op 5GHz al voldoende hebt aan medium en je nu met high teveel overlap creeerd. Of juist dat het domme clients zijn (IoT device bv) die vasthouden aan het AP waarmee ze ooit hebben verbonden en daardoor blijven verbinden met de AC Pro terwijl de AC NanoHD korter bij is.

ik zal vanavond thuis nog eens een scan doen om te zien hoeveel signaal ik op de kanalen heb als ik door het huis loop.

[nero355]

furian88 schreef op maandag 6 mei 2019 @ 11:50:
ik zal vanavond thuis nog eens een scan doen om te zien hoeveel signaal ik op de kanalen heb als ik door het huis loop.

Dat is sowieso Stap #2 nadat je de instellingen hebt toegepast die je al hebt vermeld : 2.4 GHz op Low en 5 GHz op High

In mijn geval was het toevallig meteen goed, maar uiteindelijk hangt alles ook af van de plek waar elke accesspoint staat!

ZaZ schreef op maandag 6 mei 2019 @ 10:06:
[Afbeelding]

Deze gebruik ik altijd tijdens het configureren van firewall e.d. Retehandig.

ardvark99 schreef op maandag 6 mei 2019 @ 10:17:
Thanks, ben de afgelopen dagen bezig om de firewall onder de knie te krijgen. Heb ook al diverse YouTube films bekeken. Alle info is welkom

Die afbeelding is al een paar keer gepost geloof ik, maar staat dus niet in de TS zo te zien

Gauw toevoegen dan!

Falcon10 schreef op maandag 6 mei 2019 @ 06:36:
Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
Versta me niet verkeerd, ben zelf meer dan tevreden met hoe het bij mij loopt, opgezet is kunnen worden etc, maar komt er vooral op neer vind ik : als je het in werking hebt gekregen ( wat normaal zonder al te veel problemen/vrij simpel lukt ), blijf er daarna met je fikken vanaf, want met bijna elke firmware/software upgrade komen er daarna misschien wel problemen voor.
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....

Zelf tevreden over Ubiquiti voor bij me thuis, maar op men werk heb ik toch maar voor Netgear Prosafe switchen gekozen.

Ik zou zakelijk ook waarschijnlijk eerder voor HP switches kiezen : Onbeperkte garantie periode en extreem stabiel de keren dat ik ermee heb gewerkt!

Ubiquiti is leuk Pro Consumer en MKB spul, maar heel eerlijk gezegd zou ik daar misschien ook met een schuin oog naar andere merken kijken afhankelijk van de grootte van de omgeving.

Om maar iets simpels te noemen : Waarom zou ik een duurder USG model kopen als de UniFi Controller net zo beperkt is als voor de gewone USG ?!

En daarnaast had volgens mij iemand al eerder gepost dat hij geen garantie kreeg op een kapotte UAP, omdat de importeur of groothandel waar het exemplaar vandaan kwam ondertussen failliet was gegaan! W-T-F?!?!


Maar goed... leuk spul voor thuis verder...

[GioStyle]

nero355 schreef op maandag 6 mei 2019 @ 15:24:

En daarnaast had volgens mij iemand al eerder gepost dat hij geen garantie kreeg op een kapotte UAP, omdat de importeur of groothandel waar het exemplaar vandaan kwam ondertussen failliet was gegaan! W-T-F?!?!

Dat is toch wettelijk gezien hun recht. Je hebt geen koopovereenkomst met de fabrikant, maar met de winkelier/webshop. Garantie claim je bij de winkelier/webshop. Garantieafhandelingen rechtstreeks via de fabrikant is een stuk service, geen verplichting.

[ed1703]

ZaZ schreef op maandag 6 mei 2019 @ 10:06:
[Afbeelding]

Deze gebruik ik altijd tijdens het configureren van firewall e.d. Retehandig.

Mooi.. ben sowieso ook altijd van het eerst uittekenen van zaken. Firewall is daar ook zoiets. Meestal eerst kalken op een A4-notitieblok en vervolgens in Visio aan de gang. Met remote-sites ook zo.

[nero355]

GioStyle schreef op maandag 6 mei 2019 @ 15:35:
Dat is toch wettelijk gezien hun recht. Je hebt geen koopovereenkomst met de fabrikant, maar met de winkelier/webshop. Garantie claim je bij de winkelier/webshop. Garantieafhandelingen rechtstreeks via de fabrikant is een stuk service, geen verplichting.

Maar dan nog : Na 2 jaar is de lol over en mag je een nieuw exemplaar gaan kopen als er wat stuk gaat... ouch!

[burne]

ed1703 schreef op maandag 6 mei 2019 @ 16:01:
[...]
en vervolgens in Visio aan de gang.

Voor de rest wellicht interessant: draw.io (zij die geen Visio kunnen draaien..)

[SmokingCrop]

nero355 schreef op maandag 6 mei 2019 @ 15:24:
[...]
Om maar iets simpels te noemen : Waarom zou ik een duurder USG model kopen als de UniFi Controller net zo beperkt is als voor de gewone USG ?!

Verschil in IDS/IPS en QoS (Smartqueus, fq_codel) performance

[ardvark99]

Ik zit vanavond in mijn USG te kijken, met het commando show log tail, wat er allemaal voorbij komt. Nu valt mij het volgende op, er is nogal wat verkeer vanaf 91.203.10x.xxx op poort 8443 en 8080 richting mijn UniFi controller op local 172.19.1.9. Waarbij LEN= 40, en tweede site op mijn controller geeft een LEN-60, vanaf ip adres 217.62.xx.yy. Ik heb ff gekeken, die IP range behoort tot een Duits bedrijf: Yalwa GmbH

En wat betekend die DF, tussen ID en PROTO?

Moet ik mij zorgen maken, of kan ik dit gewoon negeren?

code:

May  6 20:45:48 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.20 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=57168 DF PROTO=TCP SPT=63247 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:49 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.87 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=38147 DF PROTO=TCP SPT=38320 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:50 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.77 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=25736 DF PROTO=TCP SPT=35533 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:51 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.37 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=74 ID=59773 DF PROTO=TCP SPT=59808 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:52 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=217.62.xx.yy DST=172.19.1.9 LEN=60 TOS=0x00 PREC=0x00 TTL=61 ID=48282 PROTO=TCP SPT=33884 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:53 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.180 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=77 ID=10071 DF PROTO=TCP SPT=38220 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:53 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.103 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=51531 DF PROTO=TCP SPT=44084 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:55 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.60 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=70 ID=47736 DF PROTO=TCP SPT=57867 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:55 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.148 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=27518 DF PROTO=TCP SPT=59438 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:57 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.87 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=3063 DF PROTO=TCP SPT=36183 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0

[nero355]

SmokingCrop schreef op maandag 6 mei 2019 @ 18:13:
Verschil in IDS/IPS en QoS (Smartqueus, fq_codel) performance

Weet ik, maar je blijft dus met het probleem zitten dat er heel veel opties/settings nog steeds niet zichtbaar zijn in de UniFi Controller

[burne]

ardvark99 schreef op maandag 6 mei 2019 @ 21:09:

En wat betekend die DF, tussen ID en PROTO?

Moet ik mij zorgen maken, of kan ik dit gewoon negeren?

DF zijn packets met het Don't Fragment bit gezet. Verder niet druk over maken, zolang je geen rare dingen doet ga je daar nooit mee te maken krijgen.

De vraag is vooral of je dit doorlaat of niet. Je controller hoort (in mijn ogen) niet voor de hele wereld toegankelijk te zijn. Die van mij is dat in ieder geval niet. Overdag host ik spannende sites dus mijn uitgangspunt is ronduit paranoïde.

Als dit je log van gedropt verkeer is hoef je je maar één ding af te vragen: waarom willen Duitsers inloggen op jouw controller? Het zal ze als je het verkeer dropt niet lukken, dus waarom proberen ze het gericht? Iemand moet ze verteld hebben dat er bij jou misschien iets te halen valt.

[xbeam]

Falcon10 schreef op maandag 6 mei 2019 @ 06:36:
[...]


Pfff, als je dat zo leest soms, dan heb ik toch men bedenkingen hoor bij Ubiquiti.
Versta me niet verkeerd, ben zelf meer dan tevreden met hoe het bij mij loopt, opgezet is kunnen worden etc, maar komt er vooral op neer vind ik : als je het in werking hebt gekregen ( wat normaal zonder al te veel problemen/vrij simpel lukt ), blijf er daarna met je fikken vanaf, want met bijna elke firmware/software upgrade komen er daarna misschien wel problemen voor.
Das "niet erg" voor de huis/tuin/keuken gebruiker zoals een boel onder ons, maar ze positioneren zich ook in de zakelijke markt, en vergelijken zich dan ook met oa Cisco, Aruba, ....
Goed, op prijs en al win je het van die jongens, maar op vlak van degelijke software patches.
En afhankelijk van je werkgever ofzo, zijn die niet mals op gebied van stabiliteit van dat soort zooi.
Afhankelijk van het soort netwerk ben je verplicht om minstens jaarlijks, 3 maandelijks of zelfs maandelijks firmware/software updates te installeren ivm security. Lollig werkje hoor als elke paar maand je switchen terug mag restoren omdat de laatste software update van hen in jou config weer een boel dingen niet meer laat werken.

Zelf tevreden over Ubiquiti voor bij me thuis, maar op men werk heb ik toch maar voor Netgear Prosafe switchen gekozen.

Hahaha 😝 maak er niet zoon drama van een update terug draaien is 1 CLI regel. EdgeOS werkt heel netjes met een dubbel file system.
Na een firmware update kan gewoon heen en switchen tussen de nieuwste en vorige versie.

code:

set system image default-boot

Dus wanneer de update problemen kies je gewoon de oude boot file en reboot je edge.
Kost je hoogstens 5 min ;-)

[xbeam]

ardvark99 schreef op maandag 6 mei 2019 @ 21:09:
Ik zit vanavond in mijn USG te kijken, met het commando show log tail, wat er allemaal voorbij komt. Nu valt mij het volgende op, er is nogal wat verkeer vanaf 91.203.10x.xxx op poort 8443 en 8080 richting mijn UniFi controller op local 172.19.1.9. Waarbij LEN= 40, en tweede site op mijn controller geeft een LEN-60, vanaf ip adres 217.62.xx.yy. Ik heb ff gekeken, die IP range behoort tot een Duits bedrijf: Yalwa GmbH

En wat betekend die DF, tussen ID en PROTO?

Moet ik mij zorgen maken, of kan ik dit gewoon negeren?

code:

May  6 20:45:48 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.20 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=57168 DF PROTO=TCP SPT=63247 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:49 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.87 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=38147 DF PROTO=TCP SPT=38320 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:50 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.77 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=25736 DF PROTO=TCP SPT=35533 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:51 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.37 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=74 ID=59773 DF PROTO=TCP SPT=59808 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:52 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=217.62.xx.yy DST=172.19.1.9 LEN=60 TOS=0x00 PREC=0x00 TTL=61 ID=48282 PROTO=TCP SPT=33884 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:53 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.180 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=77 ID=10071 DF PROTO=TCP SPT=38220 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:53 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.103 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=51531 DF PROTO=TCP SPT=44084 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:55 UniFiUSG kernel: [WAN_IN-3014-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.103.60 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=70 ID=47736 DF PROTO=TCP SPT=57867 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:55 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.148 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=27518 DF PROTO=TCP SPT=59438 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0
May  6 20:45:57 UniFiUSG kernel: [WAN_IN-3012-A]IN=eth0 OUT=eth1 MAC=fc:ec:da:43:bc:e0:00:01:5c:ac:e0:46:08:00 SRC=91.203.101.87 DST=172.19.1.9 LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=3063 DF PROTO=TCP SPT=36183 DPT=8443 WINDOW=29200 RES=0x00 SYN URGP=0

Maak je gebruik van de unifi cloud connectie.
Dus log je in via unifi.ui.com of unifi.ubnt.com

Ubnt maak voor deze dienst gebruik van proxy’s en de nl proxies staan in Frankfurt.

Ik ben hier ook een keer in gedoken omdat ik onverklaarbare ip’s bij de logins zag op mij nvr.

Maar wanneer de unifi app en nvr en protect app niet direct naar het ip kunnen van je controller of nvr kunnen verbinden zetten ze via de Frankfurt proxy een webRtc verbinding op wat dus in de logs ziet zijn de proxy IP-adressen En niet het ip van je mobile telefoon of het ip adress van de locatie waar je unifi.ubnt.com opvraagt.


Wikipedia: WebRTC

[xbeam]

Dubbel

[ Voor 99% gewijzigd door xbeam op 07-05-2019 07:29 ]

[burne]

xbeam schreef op dinsdag 7 mei 2019 @ 01:45:
[...]


Ubnt maak voor deze dienst gebruik van proxy’s en de nl proxies staan in Frankfurt.

Handig dat ze dat netjes melden middels RIPE NCC en reverse pointers. Incompetente flapdrollen zijn het.

[Quad]

Wanneer ik met usenet mijn verbinding dichttrek, wordt mijn USG tijdelijk niet benaderbaar via de Cloudkey.
Heartbeat missed en disconnected melding.

Zodra de verbinding weer vrij is, komt de USG weer terug zoals hij was en lijkt er niks aan de hand.
Iemand die dit herkent? Onderlinge verbinding tussen USG en Cloudkey is 1Gb en internet snelheid is 100Mbps.
Provider capabilities is wel ingevuld, maar dit kan geen invloed hebben hierop, omdat dit enkel voor statistieken is. IPS staat uit, DPI staat aan.

Het is geen groot issue, verbinding blijft gewoon up, maar apart is het wel.

[RnB]

Dat herken ik niet en mijn USG Pro zit regelmatig een lange tijd op 100% cpu (250Mbps met IPS en DPI enabled).

De keren dat ik een heartbeat missed / disconnected devices heb gehad, lostte ik dit op door een reset to defaults en re-adoption.

[ardvark99]

burne schreef op maandag 6 mei 2019 @ 23:37:
[...]
De vraag is vooral of je dit doorlaat of niet. Je controller hoort (in mijn ogen) niet voor de hele wereld toegankelijk te zijn. Die van mij is dat in ieder geval niet. Overdag host ik spannende sites dus mijn uitgangspunt is ronduit paranoïde.

Als dit je log van gedropt verkeer is hoef je je maar één ding af te vragen: waarom willen Duitsers inloggen op jouw controller? Het zal ze als je het verkeer dropt niet lukken, dus waarom proberen ze het gericht? Iemand moet ze verteld hebben dat er bij jou misschien iets te halen valt.

Ik host verder geen spannende sites ;-) Maar ik kan mij voorstellen dat je een controller niet van buiten af toegangkelijk wilt hebben. Maar in mijn geval vind ik het wel handig, en kan ik eventueel ook de mobiele apps gebruiken. Ik kan natuurlijk ook een VPN gaan gebruiken, maar dan moet ik dat ook op mijn mobiel gaan instellen.
Vandaar dat ik de afgelopen weken bezig ben om met VLAN's en firewalls mijn netwerk intern, maar ook extern veiliger kan maken. Zodoende leer ik steeds meer

En onbedoeld heb ik die Duitsers verteld om hier te komen kijken, door de unifi cloud connectie te enabelen. Totaal over het hoofd gezien. Zal eens kijken of ik die niet gewoon uit kan zetten, of ipv externe toegang, via de cloud connectie ga werken, weet nog niet wat handiger en/of veiliger is.

xbeam schreef op dinsdag 7 mei 2019 @ 01:45:
[...]
Maak je gebruik van de unifi cloud connectie.
Dus log je in via unifi.ui.com of unifi.ubnt.com

Ubnt maak voor deze dienst gebruik van proxy’s en de nl proxies staan in Frankfurt.

Ik ben hier ook een keer in gedoken omdat ik onverklaarbare ip’s bij de logins zag op mij nvr.

Maar wanneer de unifi app en nvr en protect app niet direct naar het ip kunnen van je controller of nvr kunnen verbinden zetten ze via de Frankfurt proxy een webRtc verbinding op wat dus in de logs ziet zijn de proxy IP-adressen En niet het ip van je mobile telefoon of het ip adress van de locatie waar je unifi.ubnt.com opvraagt.


Wikipedia: WebRTC

Ik heb dus idd de unifi cloud connectie aan staan, zie hierboven. Maar bedankt voor de toelichting. Weer wat geleerd.

[xbeam]

ardvark99 schreef op dinsdag 7 mei 2019 @ 10:13:
[...]

Ik host verder geen spannende sites ;-) Maar ik kan mij voorstellen dat je een controller niet van buiten af toegangkelijk wilt hebben. Maar in mijn geval vind ik het wel handig, en kan ik eventueel ook de mobiele apps gebruiken. Ik kan natuurlijk ook een VPN gaan gebruiken, maar dan moet ik dat ook op mijn mobiel gaan instellen.
Vandaar dat ik de afgelopen weken bezig ben om met VLAN's en firewalls mijn netwerk intern, maar ook extern veiliger kan maken. Zodoende leer ik steeds meer

En onbedoeld heb ik die Duitsers verteld om hier te komen kijken, door de unifi cloud connectie te enabelen. Totaal over het hoofd gezien. Zal eens kijken of ik die niet gewoon uit kan zetten, of ipv externe toegang, via de cloud connectie ga werken, weet nog niet wat handiger en/of veiliger is.


[...]

Ik heb dus idd de unifi cloud connectie aan staan, zie hierboven. Maar bedankt voor de toelichting. Weer wat geleerd.

Wat is veiliger? Dat is de vraag.

Helemaal geen porten open hoeven zetten zoals met de cloud connect is Local het veiligst maar zijn die proxies en Ubnt te vertrouwen.

Ik zou gaan voor Ubnt mocht het mis gaan bij ubnt dan en daardoor bij jouw dan heb je Iers om te wijzen. Heb je porten open staan je en gaat mis dan kijkt iedereen naar naar jouw.

Ik zeg lekker porten dicht houden. En kunnen wijzen naar Ubnt.

[Quad]

xbeam schreef op dinsdag 7 mei 2019 @ 11:23:
[...]


Wat is veiliger? Dat is de vraag.

Helemaal geen porten open hoeven zetten zoals met de cloud connect is Local het veiligst maar zijn die proxies en Ubnt te vertrouwen.

Ik zou gaan voor Ubnt mocht het mis gaan bij ubnt dan en daardoor bij jouw dan heb je Iers om te wijzen. Heb je porten open staan je en gaat mis dan kijkt iedereen naar naar jouw.

Ik zeg lekker porten dicht houden. En kunnen wijzen naar Ubnt.

Cloudconnectie uit, poorten dicht en enkel VPN toestaan.

[nero355]

Quad schreef op dinsdag 7 mei 2019 @ 09:42:
Wanneer ik met usenet mijn verbinding dichttrek, wordt mijn USG tijdelijk niet benaderbaar via de Cloudkey.
Heartbeat missed en disconnected melding.

Zodra de verbinding weer vrij is, komt de USG weer terug zoals hij was en lijkt er niks aan de hand.
Iemand die dit herkent? Onderlinge verbinding tussen USG en Cloudkey is 1Gb en internet snelheid is 100Mbps.
Provider capabilities is wel ingevuld, maar dit kan geen invloed hebben hierop, omdat dit enkel voor statistieken is. IPS staat uit, DPI staat aan.

Het is geen groot issue, verbinding blijft gewoon up, maar apart is het wel.

Dit is wel vaker langsgekomen en er was een oplossing voor door de USG voor de gek te houden op de een of andere manier en daardoor bleef die connectie dan wel gewoon actief!

Maar wat het precies was weet ik niet meer... moet je effe zoeken

[m3gA]

Heeft iemand ervaring met Chromecast /Google home en speakergroups over mdns?

Mijn chromecasts zitten in een eigen vlan en mdns werkt prima voor het normaal detecteren maar speakergroups worden alleen in het zelfde subnet herkent. MDNS kan verder niet geconfigureerd worden. Het is uit of aan.

[ Voor 11% gewijzigd door m3gA op 07-05-2019 15:54 ]

[Remco Tr]

Wat is de beste methode.

Controller is geinstalleerd op pc hoe ik kan het verplaatsen naar mn raspberry pi?

[RobertMe]

Remco Tr schreef op dinsdag 7 mei 2019 @ 18:11:
Wat is de beste methode.

Controller is geinstalleerd op pc hoe ik kan het verplaatsen naar mn raspberry pi?

Ergens onder settings => sites staat een export of move optie. Die maakt (eerst) een backup aan die je op de RPi tijdens de initiële setup van de controller meteen kunt importeren. Daarna kun je evt. nog een aantal stappen volgen (in controller op PC) om de inform URL aan te passen en daarna moet alles gewoon weer werken.

[Yoshimi]

Ik weet niet zeker of dit de juiste plek is, maar probeer het toch eens.
Heb op mijn iPhone de app ‘Network Analyzer Pro’ geïnstalleerd, welke ik een hele tijd geleden eens gekocht had. Fijne app, nu zie ik bij mijn LAN menu echter een VPN die actief blijkt te zijn, maar ik niet kan plaatsen?
Op mijn USG heb ik geen VPN ingesteld en de 10.x reeks gebruik ik ook niet. Ik heb geen flauw idee wat het is, en probeer dit te achterhalen.

Het ziet als volgt uit in de app:


Heeft iemand tips hoe (en of) ik zou kunnen achterhalen wat dit is?

[theblindman]

Yoshimi schreef op dinsdag 7 mei 2019 @ 22:11:
Ik weet niet zeker of dit de juiste plek is, maar probeer het toch eens.
Heb op mijn iPhone de app ‘Network Analyzer Pro’ geïnstalleerd, welke ik een hele tijd geleden eens gekocht had. Fijne app, nu zie ik bij mijn LAN menu echter een VPN die actief blijkt te zijn, maar ik niet kan plaatsen?
Op mijn USG heb ik geen VPN ingesteld en de 10.x reeks gebruik ik ook niet. Ik heb geen flauw idee wat het is, en probeer dit te achterhalen.

Het ziet als volgt uit in de app:
[Afbeelding]

Heeft iemand tips hoe (en of) ik zou kunnen achterhalen wat dit is?

Heb je bellen over 4G toevallig aanstaan? Dan zou het daarmee te maken kunnen hebben

[ardvark99]

xbeam schreef op dinsdag 7 mei 2019 @ 11:23:
[...]


Wat is veiliger? Dat is de vraag.

Helemaal geen porten open hoeven zetten zoals met de cloud connect is Local het veiligst maar zijn die proxies en Ubnt te vertrouwen.

Ik zou gaan voor Ubnt mocht het mis gaan bij ubnt dan en daardoor bij jouw dan heb je Iers om te wijzen. Heb je porten open staan je en gaat mis dan kijkt iedereen naar naar jouw.

Ik zeg lekker porten dicht houden. En kunnen wijzen naar Ubnt.

Quad schreef op dinsdag 7 mei 2019 @ 12:59:
[...]

Cloudconnectie uit, poorten dicht en enkel VPN toestaan.

Thanks, ik ga de opties eens bekijken. Het moet natuurlijk ook beheersbaar en makkelijk te gebruiken zijn. En de eigenaar van de andere site die ik host moet op een of ander manier ook bij de controller kunnen (Site2site VPN?), en/of de app kunnen gebruiken. De vraag is dan alleen op locatie van een van de sites, of ook op externe locaties.

Ik begrijp, hoe toegangkelijker, hoe onveiliger het wordt (en nu dus al zo is).

Maar eerst verder met mijn eigen VLANs en firewall, niet alles tegelijk... De cloud connectie heb ik in ieder geval al uit gezet.

[Yoshimi]

theblindman schreef op dinsdag 7 mei 2019 @ 22:35:
[...]

Heb je bellen over 4G toevallig aanstaan? Dan zou het daarmee te maken kunnen hebben

Ik heb bellen over 4G uitgeschakeld en nu komt die VPN verbinding inderdaad niet meer terug.
Dat had ik niet verwacht om eerlijk te zijn (ik was al in logs gaan duiken van de USG).
Niet UniFi gerelateerd uiteindelijk, maar evenmin bedankt voor je hulp!

[RobertMe]

ardvark99 schreef op dinsdag 7 mei 2019 @ 23:37:
[...]


[...]

Thanks, ik ga de opties eens bekijken. Het moet natuurlijk ook beheersbaar en makkelijk te gebruiken zijn. En de eigenaar van de andere site die ik host moet op een of ander manier ook bij de controller kunnen (Site2site VPN?), en/of de app kunnen gebruiken. De vraag is dan alleen op locatie van een van de sites, of ook op externe locaties.

Ik begrijp, hoe toegangkelijker, hoe onveiliger het wordt (en nu dus al zo is).

Maar eerst verder met mijn eigen VLANs en firewall, niet alles tegelijk... De cloud connectie heb ik in ieder geval al uit gezet.

Je kunt de controller ook achter een reverse proxy plaatsen op een domein. Zodat je dus niet naar https://ip-adres:8442 moet gaan maar naar https://unifi.eigen-domeinnaam.nl/. Dan komen kwaadwillenden dus alleen bij de controller uit als ze de juiste domeinnaam gokken. Uiteraard is het dan wel een vorm van security through obscurity, maar het voegt wel weer een "laagje" toe.