[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[Timmert]

RobertMe schreef op zaterdag 21 september 2019 @ 13:29:
[...]

Ik meen dat @ewoutw ook een captive portal wou gaan inzetten? Dan moet je ook de controller 24/7 hebben draaien.

Of je neemt een controller in de cloud af, al dan niet managed.
Mocht je daar meer info over willen dan mag je altijd een DM sturen

[Videopac]

m3gA schreef op woensdag 11 september 2019 @ 12:52:
[...]

https://help.ubnt.com/hc/...ntenna-Radiation-Patterns

De HD reeks wordt ook gezien als een Gen3 en de Pro is gen2.
De HD is gebaseerd op een mediatek chipset. Let even op dat de Pro met een PoE injector komt (behalve de Pro-E of 3 packs) en de HD niet.

De "gewone" HD heeft toch een Qualcom QCA9984 chipset?

[RobertMe]

Videopac schreef op zaterdag 21 september 2019 @ 16:39:
[...]

De "gewone" HD heeft toch een Qualcom QCA9984 chipset?

Klopt, alleen de NanoHD (en de IW HD) hebben een Mediatek chip. De rest van de UniFi APs die ze momenteel verkopen draaien allemaal op een Qualcom chip.

[Videopac]

RobertMe schreef op zaterdag 21 september 2019 @ 16:56:
[...]

Klopt, alleen de NanoHD (en de IW HD) hebben een Mediatek chip. De rest van de UniFi APs die ze momenteel verkopen draaien allemaal op een Qualcom chip.

Qualcom heeft wel een goede reputatie, o.a. echt werkende Mu-Mimo, hoe zit dat met Mediatek?

[m3gA]

Videopac schreef op zaterdag 21 september 2019 @ 16:39:
[...]

De "gewone" HD heeft toch een Qualcom QCA9984 chipset?

Klopt. was niet helemaal duidelijk maar verwees naar de Nano versies.

[toro]

Is de edgerouter x krachtig genoeg om 500mb up/down wan aan te kunnen?

Ik lees op het net tegenstrijdige verhalen

[Kavaa]

toro schreef op zondag 22 september 2019 @ 12:20:
Is de edgerouter x krachtig genoeg om 500mb up/down wan aan te kunnen?

Ik lees op het net tegenstrijdige verhalen

Zonder al te veel andere dingen en firewall rules/vlans ja, maar wil je meer gaan doen in de toekomst of iets met VPN etc. Dan zou ik toch de Edgerouter 4 nemen.

De X is leuk maar komt dan toch echt te kort😊

[nero355]

Kavaa schreef op zondag 22 september 2019 @ 16:31:
Zonder al te veel andere dingen en firewall rules/vlans ja, maar wil je meer gaan doen in de toekomst of iets met VPN etc. Dan zou ik toch de Edgerouter 4 nemen.

De X is leuk maar komt dan toch echt te kort😊

De ER-X en ER-Lite hebben toch gewoon offload chips voor NAT, waardoor ze 1 Gbps synchroon aankunnen

Al die duurdere modellen zijn leuk, maar de herrie van de fans is voor thuisgebruik vaak gewoon geen optie...

VPN kan je tegenwoordig beter door middel van een Raspberry Pi 4 doen, waar je gelijk ook andere leuke dingen mee kan doen!

[RobertMe]

nero355 schreef op zondag 22 september 2019 @ 17:25:
[...]

De ER-X en ER-Lite hebben toch gewoon offload chips voor NAT, waardoor ze 1 Gbps synchroon aankunnen

Al die duurdere modellen zijn leuk, maar de herrie van de fans is voor thuisgebruik vaak gewoon geen optie...

VPN kan je tegenwoordig beter door middel van een Raspberry Pi 4 doen, waar je gelijk ook andere leuke dingen mee kan doen!

De ERR-4 heeft bij mijn weten geen fans. En waarom zou je een RPi nemen voor VPN? Een router daarvoor lijkt mij toch echt logischer omdat je dan eerder / makkelijker kunt voorkomen dat verkeer vanaf VPN op bepaalde delen van je netwerk komt etc.

[nero355]

RobertMe schreef op zondag 22 september 2019 @ 17:35:
De ERR-4 heeft bij mijn weten geen fans.

Verrek... je hebt gelijk : pricewatch: Ubiquiti EdgeRouter 4

Het zijn de duurdere USG's die fannetjes hebben...

En waarom zou je een RPi nemen voor VPN? Een router daarvoor lijkt mij toch echt logischer omdat je dan eerder / makkelijker kunt voorkomen dat verkeer vanaf VPN op bepaalde delen van je netwerk komt etc.

Omdat OpenVPN via de CPU gaat voor zover ik weet en je dat niet kan offloaden, waardoor je router het best wel druk krijgt

[RobertMe]

nero355 schreef op zondag 22 september 2019 @ 17:50:
[...]

Omdat OpenVPN via de CPU gaat voor zover ik weet en je dat niet kan offloaden, waardoor je router het best wel druk krijgt

Niet verdiept in de specs, maar is OpenVPN dan zo zwaar op de CPU en de RPi zoveel beter? Volgens mij bevat de ER-4 ook een vrij krachtige (ARM?) processor.
En aangezien de ER het gewone verkeer normaliter via hardware offloading doet verwacht ik niet dat VPN een significante impact heeft op de verdere performance.


En daarnaast, wie gebruikt OpenVPN nu nog? * RobertMe moet nog steeds eens naar WireGuard kijken (alleen geen idee of die evt. iets van hardware offloading kan doen)

[nero355]

RobertMe schreef op zondag 22 september 2019 @ 18:01:
Niet verdiept in de specs, maar is OpenVPN dan zo zwaar op de CPU en de RPi zoveel beter? Volgens mij bevat de ER-4 ook een vrij krachtige (ARM?) processor.

Ik denk dat de Pi 4 hier gewoon de betere optie is allround

En aangezien de ER het gewone verkeer normaliter via hardware offloading doet verwacht ik niet dat VPN een significante impact heeft op de verdere performance.

Maar wel op al het andere, zoals de bereikbaarheid van de WebGUI of SSH denk ik

En daarnaast, wie gebruikt OpenVPN nu nog?

Zo'n beetje elke serieuze VPN provider

* RobertMe moet nog steeds eens naar WireGuard kijken (alleen geen idee of die evt. iets van hardware offloading kan doen)

Dat hele project is nog steeds zwaar in de ontwikkeling en dat gaat nog wel effe zo blijven vrees ik

[Kavaa]

@RobertMe Mocht je deze nog niet gezien hebben: https://community.ui.com/...52-4629-948a-3ac9d9c22311 -- https://github.com/Lochnair/vyatta-wireguard

Zelf zitten we erg vol op het moment dus hebben niet echt tijd om te testen.

[ Voor 9% gewijzigd door Kavaa op 22-09-2019 18:58 ]

[RobertMe]

Kavaa schreef op zondag 22 september 2019 @ 18:57:
@RobertMe Mocht je deze nog niet gezien hebben: https://community.ui.com/...52-4629-948a-3ac9d9c22311 -- https://github.com/Lochnair/vyatta-wireguard

Zelf zitten we erg vol op het moment dus hebben niet echt tijd om te testen.

Dat er een (officieel) package is van de WireGuard dev voor de ER en USG is mij inderdaad bekend. Alleen verder inderdaad niks mee gedaan. Maar als ik zelf WireGuard ga draaien denk ik eerder dat die op m'n NAS/thuisserver/whatever you'd like to call it zet. Zeker gezien het gemak waarmee WireGuard ingeregeld kan worden. Nu heb ik lekker makkelijk een IPSEC server op de USG draaien wat dus ook met een paar keer klikken geregeld is in de UniFi controller, maar zelf inregelen van IPSEC vereist volgens mij een stuk meer configuratie.

[Videopac]

RobertMe schreef op zondag 22 september 2019 @ 18:01:
[...]

Niet verdiept in de specs, maar is OpenVPN dan zo zwaar op de CPU en de RPi zoveel beter? Volgens mij bevat de ER-4 ook een vrij krachtige (ARM?) processor.
En aangezien de ER het gewone verkeer normaliter via hardware offloading doet verwacht ik niet dat VPN een significante impact heeft op de verdere performance.

Wel als je encriptie toepast. Ondersteund de Edgerouter 4 hardwarematige encriptie voor VPN verbindingen?

En daarnaast, wie gebruikt OpenVPN nu nog? * RobertMe moet nog steeds eens naar WireGuard kijken (alleen geen idee of die evt. iets van hardware offloading kan doen)

Wat is er mis met OpenVPN?

[Kavaa]

Videopac schreef op zondag 22 september 2019 @ 20:36:
[...]

Wel als je encriptie toepast. Ondersteund de Edgerouter 4 hardwarematige encriptie voor VPN verbindingen?

[...]

Wat is er mis met OpenVPN?

Met OpenVPN is niets mis, het is alleen wat zwaarder.

[nero355]

@RobertMe : Eerst zeg je dit =>

RobertMe schreef op zondag 22 september 2019 @ 17:35:
En waarom zou je een RPi nemen voor VPN? Een router daarvoor lijkt mij toch echt logischer omdat je dan eerder / makkelijker kunt voorkomen dat verkeer vanaf VPN op bepaalde delen van je netwerk komt etc.

Om dan vervolgens dit te posten =>

RobertMe schreef op zondag 22 september 2019 @ 19:08:
Maar als ik zelf WireGuard ga draaien denk ik eerder dat die op m'n NAS/thuisserver/whatever you'd like to call it zet. Zeker gezien het gemak waarmee WireGuard ingeregeld kan worden.

Ehh... Wat is het nou

"You lost me there buddy!"

[RobertMe]

nero355 schreef op maandag 23 september 2019 @ 00:10:
@RobertMe : Eerst zeg je dit =>

[...]

Om dan vervolgens dit te posten =>

[...]

Ehh... Wat is het nou

"You lost me there buddy!"

Precies wat ik schrijf, dat ik het niet op een RPi zou doen
Cruciale onderdelen van het netwerk (VPN, Pi-Hole, ...) vind ik persoonlijk nu niet het beste idee om te draaien op een kinda underpowered device dat draait op een SD kaart die bij wijze van elk moment kan overlijden.

[Bierkameel]

Meer mensen met een USG Pro die een oplopend geheugenverbruik zien als IPS aanstaat?
Ik zie het in 30 dagen oplopen en daarna crashe hij, nu voor de 2e keer, het disablen van IPS geeft het geheugen niet vrij, een reboot wel.
Uiteraard op de nieuwste stabiele firmware

Er staat bij dat IPS/IDS nog in beta is maar dit is best vreemd.

[RnB]

Ja, ik zie hetzelfde gebeuren op mijn USG Pro.
Ik heb het niet langer dan een week getest, daar de snelheid ook ineens inkakt. Ik heb een 200/200Mbps verbinding, na een week blijft hier nog maar 160Mbps van over.
IPS disablen en mijn snelheid is weer goed (en het mem verbruik is verlaagt).

[geenwindows]

Bierkameel schreef op maandag 23 september 2019 @ 13:26:
Meer mensen met een USG Pro die een oplopend geheugenverbruik zien als IPS aanstaat?
Ik zie het in 30 dagen oplopen en daarna crashe hij, nu voor de 2e keer, het disablen van IPS geeft het geheugen niet vrij, een reboot wel.
Uiteraard op de nieuwste stabiele firmware

Er staat bij dat IPS/IDS nog in beta is maar dit is best vreemd.

hier geen problemen met de pro4, rete stabiel met 25% geheugen gebruik. laatste 'stable' firmware 4.4.44.5213871, controller versie 5.11.39. overigens heet IPS bij mij "Threat Management (Beta)"

[nero355]

RobertMe schreef op maandag 23 september 2019 @ 07:24:
Precies wat ik schrijf, dat ik het niet op een RPi zou doen
Cruciale onderdelen van het netwerk (VPN, Pi-Hole, ...) vind ik persoonlijk nu niet het beste idee om te draaien op een kinda underpowered device dat draait op een SD kaart die bij wijze van elk moment kan overlijden.

Je bedoelt zoiets als de UniFi CloudKey ?!

[Ethirty]

Hoezo wachten op een dream machine
https://www.qnap.com/en/product/qgd-1600p

Ubiquiti better step up their game

[ardvark99]

Ethirty schreef op dinsdag 24 september 2019 @ 15:32:
Hoezo wachten op een dream machine
https://www.qnap.com/en/product/qgd-1600p

Ubiquiti better step up their game

Idd leuk apparaatje, ze adverteren op de site gewoon met Ubiquiti AP’s en controller die je erop kan draaien:

The QGD-1600P Creates a Wireless AP Controller With UniFi® AP
The QGD-1600P offers 4-port 60-watt and 12-port 30-watt Gigabit PoE for various types of high-power PoE wireless APs. Adopting PoE and VM technology to support PoE wireless APs and the Ubiquiti wireless LAN management software UniFi, the QGD-1600P becomes a hardware-based and software-based wireless AP controller. The QGD-1600P enables not only data transmission and PoE management over wireless APs, but also central management over wired and wireless networking devices in offices, hotels, retail stores, or other small-to-medium-sized networks, greatly promoting the effectiveness of network management and reducing costs.

Nu de prijs nog…

[nero355]

Ethirty schreef op dinsdag 24 september 2019 @ 15:32:
Hoezo wachten op een dream machine
https://www.qnap.com/en/product/qgd-1600p

Ubiquiti better step up their game

Hoeft niet : QNAP maakt zelfs reclame daar met UniFi Controller support!

De GUI vind ik alvast wel fijn en IMHO zoals het hoort :



Ik vrees alleen dat de kleine fannetjes van het gekke ding een hoop herrie zullen maken in de meterkast...

[rinkel]

Gisteren de USG achter de Ziggo router gehangen.
Dit had nog wel wat voeten in aarde, mede doordat mijn ip-range anders is en de USG nog een oude firmware had.
Vervolgens vielen al mijn ap's uit de controller en moest ik deze een harde reset geven. (managed on other controller)
Omdat ik de USG in de DMZ heb staan en de port forwarding nog op de ziggo-router had staan werkte deze niet. Nu alles gefixed en werkt alles naar behoren.
Nu de vraag: gaat de ziggo-router in bridge?
Op zich werkt het zo prima, maar wellicht toch beter om de ziggo in bridge te laten zetten.

[m3gA]

rinkel schreef op woensdag 25 september 2019 @ 09:52:
Gisteren de USG achter de Ziggo router gehangen.
Dit had nog wel wat voeten in aarde, mede doordat mijn ip-range anders is en de USG nog een oude firmware had.
Vervolgens vielen al mijn ap's uit de controller en moest ik deze een harde reset geven. (managed on other controller)
Omdat ik de USG in de DMZ heb staan en de port forwarding nog op de ziggo-router had staan werkte deze niet. Nu alles gefixed en werkt alles naar behoren.
Nu de vraag: gaat de ziggo-router in bridge?
Op zich werkt het zo prima, maar wellicht toch beter om de ziggo in bridge te laten zetten.

De Ziggo router kan prima in bridge. https://www.ziggo.nl/klantenservice/wifi/modem/bridge-modus/

[rinkel]

m3gA schreef op woensdag 25 september 2019 @ 09:54:
[...]

De Ziggo router kan prima in bridge. https://www.ziggo.nl/klantenservice/wifi/modem/bridge-modus/

Thanks
Ik moet alleen wel even bellen:

We kunnen dit modem alleen op afstand in bridge-modus zetten. Neem contact op met de Klantenservice. Dan helpen we je verder.

[MisteRMeesteR]

rinkel schreef op woensdag 25 september 2019 @ 09:58:
[...]

Thanks
Ik moet alleen wel even bellen:


[...]

Kost je 5 minuten en wordt direct voor je uitgevoerd

[Verwijderd]

Tenzij het, zoals altijd, “onverwacht” druk is en je een half uur in de wacht mag staan

[ Voor 4% gewijzigd door Verwijderd op 25-09-2019 10:44 ]

[Joris748]

Verwijderd schreef op woensdag 25 september 2019 @ 10:43:
Tenzij het, zoals altijd, “onverwacht” druk is en je een half uur in de wacht mag staan

Dan bel je toch op een ander tijdstip terug?

[rinkel]

Done. Uiteindelijk 5 minuten in de wacht.
Meteen geregeld. Alleen viel het gesprek weg, ik had natuurlijk wifi-bellen aan staan...

[The Eagle]

rinkel schreef op woensdag 25 september 2019 @ 11:05:
Done. Uiteindelijk 5 minuten in de wacht.
Meteen geregeld. Alleen viel het gesprek weg, ik had natuurlijk wifi-bellen aan staan...

Uitgerinkeld

[rinkel]

The Eagle schreef op woensdag 25 september 2019 @ 13:55:
[...]

Uitgerinkeld

Alles werkte behalve OpenVPN.
Wat blijkt: ik heb voor het eerst in jaren een nieuw wan-IP-adres van ziggo gekregen en aangezien die nooit is gewijzigd had ik deze hard in de config staan. Ook weer opgelost.

[Ethirty]

rinkel schreef op woensdag 25 september 2019 @ 13:58:
[...]


Alles werkte behalve OpenVPN.
Wat blijkt: ik heb voor het eerst in jaren een nieuw wan-IP-adres van ziggo gekregen en aangezien die nooit is gewijzigd had ik deze hard in de config staan. Ook weer opgelost.

Modem in bridge betekend dat het MAC adres van je nieuwe router bij Ziggo een lease krijgt ipv je modem, dus dat is inderdaad een logisch gevolg.

[me_moi]

Iemand met de nieuwste firmware gelukt om Pi-Hole aan de praat te krijgen op een CloudKey? Bij mij fails de install silently. Ik heb diverse handleidingen geprobeerd om de afzonderlijke packages van Pi-Hole te installeren, dat is allemaal gelukt op 'resolvconf' na (afzonderlijke installatie van resolvconf wordt geblokkeerd omdat systemd nog in gebruik is, ik heb van alles geprobeerd (o.a. apt-get remove) maar ik heb gewoon te weinig verstand van Debian/Linux).

Mijn hoop is namelijk dat als alle benodigde packages manual geinstalleerd worden, dat Pi-Hole uiteindelijk wél wordt geïnstalleerd.

[Prutsky]

Ik gebruik sinds gisteren de wifi van mijn Fritzbox 7490 niet meer en heb een UniFi AP-AC-Pro aangeschaft. Deze hangt via een switch nu in het midden van mijn huis. Dit lijkt op zich goed te werken al krijg ik af en toe een "Adoption Failed" error te zien.
Na de Unifi heb ik aan de secondaire poort een tweede switch hangen met daaraan een Raspberry Pi (met o.a. Pi-Hole), Synology, Hue bridge en (nu nog) een Airport Express die op de zolder staat.

Het rare is dat alles wat na de Unifi hangt ik niet kan bereiken als ik inlog op de wifi van de Unifi. Ingelogd op de Unifi zie ik de Raspberry dus niet. De Hue kan ik niet benaderen vanaf mijn telefoon (die gekoppeld is aan de Unifi). Als mijn PC aan het Unifi netwerk hangt, kan ik de Fritzbox niet mee benaden.

De Unifi hoef ik niet in bridge mode te zetten, aangezien het een accesspoint is. (zit dit er überhaupt op?)

Hoe kan dit? Waar gaat dit mis? IP-addressen zitten allemaal in de zelfde reeks wat de Fritzbox aan geeft.

[Laagheim]

@me_moi Wat bedoel je met 'systemd is nog in gebruik'? Wil je resolvconf stoppen? Het commando daarvoor is sudo systemctl stop resolvconf maar normaal gesproken doet de package manager dat voor je. Anyway post de foutmelding dan kunnen we met je meekijken

[Laagheim]

@Prutsky Ik heb het zo ook jaren gedraaid zonder problemen (met een simpel Tp link switchje op de tweede poort). Welke switch gebruik je en hoe ziet je netwerk er verder uit?

[me_moi]

Laagheim schreef op woensdag 25 september 2019 @ 19:46:
@me_moi Wat bedoel je met 'systemd is nog in gebruik'? Wil je resolvconf stoppen? Het commando daarvoor is sudo systemctl stop resolvconf maar normaal gesproken doet de package manager dat voor je. Anyway post de foutmelding dan kunnen we met je meekijken

De foutmelding na mijn poging om handmatig resolvconf te installeren:

root@UniFi-CloudKey:/# apt-get install resolvconf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
ifupdown
Suggested packages:
ppp rdnssd
The following packages will be REMOVED:
systemd
The following NEW packages will be installed:
ifupdown resolvconf
0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/141 kB of archives.
After this operation, 6020 kB disk space will be freed.
Do you want to continue? [Y/n] Y
Preconfiguring packages ...
/tmp/resolvconf.config.mkr8d0: 13: /tmp/resolvconf.config.mkr8d0: ifquery: not found
/tmp/resolvconf.config.mkr8d0: 13: /tmp/resolvconf.config.mkr8d0: ifquery: not found
(Reading database ... 24509 files and directories currently installed.)
Removing systemd (230-7~bpo8+2.ubnt+1) ...
systemd is the active init system, please switch to another before removing systemd.
dpkg: error processing package systemd (--remove):
subprocess installed pre-removal script returned error exit status 1
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Errors were encountered while processing:
systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@UniFi-CloudKey:/#


Aanvullende informatie (meldingen tijdens install via bash basic-install.sh, hij is gewoon gestopt):

[i] Existing PHP installation detected : PHP version 5.6.40-0+deb8u6
[✓] Disk space check
[✓] Update local cache of available packages

[✓] Checking apt-get for upgraded packages... up to date!

[i] Installer Dependency checks...
[✓] Checking for apt-utils
[✓] Checking for dialog
[✓] Checking for debconf
[✓] Checking for dhcpcd5
[✓] Checking for git
[✓] Checking for iproute2
[✓] Checking for whiptail

[i] Using interface: eth0
[i] Using [i] Using Cloudflare
[i] Static IP already configured
[i] Unable to find IPv6 ULA/GUA address, IPv6 adblocking will not be enabled
[i] IPv4 address: 192.168.1.10/24
[i] IPv6 address:
[i] Web Interface On [i] Web Interface On
[i] Web Server On [i] Web Server On
[i] Logging On.
[i] Logging On.
[✓] Check for existing repository in /etc/.pihole
[✓] Update repo in /etc/.pihole

[✓] Check for existing repository in /var/www/html/admin
[✓] Update repo in /var/www/html/admin

[i] Main Dependency checks...
[✓] Checking for cron
[✓] Checking for curl
[✓] Checking for dnsutils
[✓] Checking for iputils-ping
[✓] Checking for lsof
[✓] Checking for netcat
[✓] Checking for psmisc
[✓] Checking for sudo
[✓] Checking for unzip
[✓] Checking for wget
[✓] Checking for idn2
[✓] Checking for sqlite3
[✓] Checking for libcap2-bin
[✓] Checking for dns-root-data
[i] Checking for resolvconf (will be installed)
[✓] Checking for libcap2
[✓] Checking for lighttpd
[✓] Checking for php5-common
[✓] Checking for php5-cgi
[✓] Checking for php5-sqlite

[ Voor 34% gewijzigd door me_moi op 25-09-2019 20:08 ]

[Laagheim]

@me_moi In de foutmelding staat de oplossing: systemd is the active init system, please switch to another before removing systemd.

Niet makkelijk als je niet zo bekend bent met Linux maar een mooie uitdaging

[Prutsky]

Laagheim schreef op woensdag 25 september 2019 @ 19:50:
@Prutsky Ik heb het zo ook jaren gedraaid zonder problemen (met een simpel Tp link switchje op de tweede poort). Welke switch gebruik je en hoe ziet je netwerk er verder uit?

Zie hier mijn set-up:


De "Adoption Failed" is ook niet echt het probleem denk ik. Het is vooral irritant dat er nu twee afzonderlijke netwerken lijken te zijn die niet met elkaar praten.

[ Voor 14% gewijzigd door Prutsky op 25-09-2019 20:40 ]

[Laagheim]

@Prutsky Toevallig dezelfde tp link sg105 als jij hebt jaren gebruikt (de vorige plastic uitvoering dan) dus we kunnen wel uitsluiten dat het daar aan ligt. Ik zie voor de rest geen rare dingen in je setup dus probeer de gewone dingen: geef je router een reboot, zet overal de laatste firmware op, probeer je ap rechtstreeks aan te sluiten op je router, koppel alles los en sluit dan weer 1 voor 1 aan etcetc. Ergens moet dan een fout naar voren komen.

[Cujo74]

Laagheim schreef op woensdag 25 september 2019 @ 21:09:
@Prutsky Toevallig dezelfde tp link sg105 als jij hebt jaren gebruikt (de vorige plastic uitvoering dan) dus we kunnen wel uitsluiten dat het daar aan ligt. Ik zie voor de rest geen rare dingen in je setup dus probeer de gewone dingen: geef je router een reboot, zet overal de laatste firmware op, probeer je ap rechtstreeks aan te sluiten op je router, koppel alles los en sluit dan weer 1 voor 1 aan etcetc. Ergens moet dan een fout naar voren komen.

Zo zeker ben ik nog niet dat je die TP link al kunt uitsluiten.
Heb er hier ook een en geweldig ding echter 1 groot nadeel en dat is het standaard IP adres van die switch.
Dat is namelijk 192.168.0.1 zo even uit mijn hoofd en dat wil je nu net niet hebben.
Heb hier zelf ook mee lopen klooien in het begin.
Dus grote vraag aan @Prutsky is wat is het IP adres van die TP-link? Heb je die gewijzigd?

[me_moi]

Laagheim schreef op woensdag 25 september 2019 @ 20:32:
@me_moi In de foutmelding staat de oplossing: systemd is the active init system, please switch to another before removing systemd.

Niet makkelijk als je niet zo bekend bent met Linux maar een mooie uitdaging

Inderdaad, de oplossing had ik al gezien. Ik hoopte echter op een simpele manier om dit te omzeilen. Want googlen levert op dat ik sysvinit moet installeren en daarna rebooten. Zojuist gedaan. Dit resulteerde echter in een non rebootable cloudkey. Hard-reset werkt gelukkig nog, maar dan ben ik weer helemaal terug bij af. Later, als ik wat meer tijd heb, zal ik verder gaan proberen.

[Prutsky]

Cujo74 schreef op woensdag 25 september 2019 @ 21:37:
[...]
Dus grote vraag aan @Prutsky is wat is het IP adres van die TP-link? Heb je die gewijzigd?

Van de TL SG108e? Ik heb die niet aangepast.

[edit] Mijn SG108E heeft nog het default adres 192.168.0.1 In wat moet ik die wijzigen?

[ Voor 22% gewijzigd door Prutsky op 25-09-2019 23:14 ]

[Cujo74]

Prutsky schreef op woensdag 25 september 2019 @ 22:56:
[...]


Van de TL SG108e? Ik heb die niet aangepast.

[edit] Mijn SG108E heeft nog het default adres 192.168.0.1 In wat moet ik die wijzigen?

Ik doelde meer op de SG105, aangezien je die niet kunt benaderen en alle apparatuur die daar aan vast hangt niet kunt zien in je netwerk. Dus ik heb het idee dat je deels in een andere range zit met die switch en of dat ie dus nu hetzelfde nummer heeft als je SG108.

Dus als je netwerk range iets van 192.168.0.X is dan moet je de SG105 bijvoorbeeld 192.168.0.10 geven of zoiets. Als je hem nu in het netwerk niet kun benaderen dan kun je hem het beste heel even direct aan een pc knopen, dan instelling wijzigen en dan terug in netwerk hangen.

En voor volledigheid, ik neem aan dat je Fritzbox ook in de 192.168.0.X range zit?

[ Voor 5% gewijzigd door Cujo74 op 26-09-2019 02:03 ]

[Prutsky]

Cujo74 schreef op donderdag 26 september 2019 @ 01:37:
[...]


Ik doelde meer op de SG105, aangezien je die niet kunt benaderen en alle apparatuur die daar aan vast hangt niet kunt zien in je netwerk. Dus ik heb het idee dat je deels in een andere range zit met die switch en of dat ie dus nu hetzelfde nummer heeft als je SG108.

Dus als je netwerk range iets van 192.168.0.X is dan moet je de SG105 bijvoorbeeld 192.168.0.10 geven of zoiets. Als je hem nu in het netwerk niet kun benaderen dan kun je hem het beste heel even direct aan een pc knopen, dan instelling wijzigen en dan terug in netwerk hangen.

En voor volledigheid, ik neem aan dat je Fritzbox ook in de 192.168.0.X range zit?

Mijn FritzBox zit in de range 192.168.178.x.

Van de SG105 kan ik geen ip adres aanpassen (het is geen "E" versie).
Wat ik ook al geprobeerd heb is, is de Unifi tussen de SG108E en SG105 uit te halen en die met elkaar te verbinden en de Unifi aan de SG105 (secundaire poort niet te gebruiken. Dit gaf geen verbetering.
Wat ik ook gedaan heb is de SG108E rechtstreeks aan de SG105 en de Unifi aan de SG108E (zonder secundaire poort te gebruiken). Ook geen effect. ( had daar hoop op, want een extra UTP kabel trekken had ik nog wel willen doen om de Unifi toch de SG105 in de buurt te zetten (midden van het huis).
Ik kan dus nog wel spelen met het ip adres van de SG108E en die een ip adress te laten krijgen van door DHCP aan te zetten?

[Cujo74]

Prutsky schreef op donderdag 26 september 2019 @ 08:42:
[...]


Mijn FritzBox zit in de range 192.168.178.x.

Van de SG105 kan ik geen ip adres aanpassen (het is geen "E" versie).
Wat ik ook al geprobeerd heb is, is de Unifi tussen de SG108E en SG105 uit te halen en die met elkaar te verbinden en de Unifi aan de SG105 (secundaire poort niet te gebruiken. Dit gaf geen verbetering.
Wat ik ook gedaan heb is de SG108E rechtstreeks aan de SG105 en de Unifi aan de SG108E (zonder secundaire poort te gebruiken). Ook geen effect. ( had daar hoop op, want een extra UTP kabel trekken had ik nog wel willen doen om de Unifi toch de SG105 in de buurt te zetten (midden van het huis).
Ik kan dus nog wel spelen met het ip adres van de SG108E en die een ip adress te laten krijgen van door DHCP aan te zetten?

Je zit inderdaad nu in verschillende range(s) te werken.
Dit aangezien je Fritzbox dus op 192.168.178.X zit
Je zult je beide switches dus ook in de 192.168.178.XX range moeten zetten.
Bij voorkeur met vast IP adres, maar anders DHCP

Maar stuur anders even pm bericht of open apart topic aangezien we waarschijnlijk nu iets te veel off-topic beginnen te gaan.

[ Voor 5% gewijzigd door Cujo74 op 26-09-2019 09:31 ]

[nero355]

me_moi schreef op woensdag 25 september 2019 @ 19:03:
Iemand met de nieuwste firmware gelukt om Pi-Hole aan de praat te krijgen op een CloudKey? Bij mij fails de install silently. Ik heb diverse handleidingen geprobeerd om de afzonderlijke packages van Pi-Hole te installeren, dat is allemaal gelukt op 'resolvconf' na (afzonderlijke installatie van resolvconf wordt geblokkeerd omdat systemd nog in gebruik is, ik heb van alles geprobeerd (o.a. apt-get remove) maar ik heb gewoon te weinig verstand van Debian/Linux).

Mijn hoop is namelijk dat als alle benodigde packages manual geinstalleerd worden, dat Pi-Hole uiteindelijk wél wordt geïnstalleerd.

Ik zou eens effe rondneuzen op het Pi-Hole Forum en zoeken naar eerdere ervaringen daarmee : https://discourse.pi-hole.net/

Hoe je op het punt bent gekomen dat SystemD en Pi-Hole elkaar in de weg zitten snap ik niet echt, want die twee kunnen prima naast elkaar leven om één simpele reden : Alle nieuwere Linux Distro's gebruiken SystemD

Prutsky schreef op woensdag 25 september 2019 @ 20:37:
Zie hier mijn set-up:
[Afbeelding: Prutsky's netwerk set-up]

De "Adoption Failed" is ook niet echt het probleem denk ik. Het is vooral irritant dat er nu twee afzonderlijke netwerken lijken te zijn die niet met elkaar praten.

Je netwerk doet je nickname eer aan!

- Waarom gebruik je de accesspoint als een tussenstap naar een switch toe
- Wat doet die AirPort in het netwerk en hoe is die aangesloten : Als Client of als Router ?!
Zit daar geen DHCP Server op te draaien die je normale netwerk door de war gooit ?
- Blijkbaar heb je geen apart "Management VLAN" aangemaakt voor al je apparatuur : Waarom niet ?!
Heeft de Fritz!Box geen VLAN Support aan de LAN kant ?
- Heb je op de Managed TP-Link switch goed naar de VLAN settings per poort gekeken ?
- Draait er niet iets op de Synology modellen dat roet in het eten kan gooien, zoals een DHCP Server bijvoorbeeld ?!

Vragen... vragen... zoveel vragen! Er kan een hoop misgaan als je niet weet wat je aan het doen bent!

[RobbieB]

Ok, n00b vraagje.

Ik had een AP Pro in mijn netwerk hangen, direct aan mijn Ziggo modem. De controller draait op een RaspberryPi.

SInds gisteren heb ik een USG en een 8-poorts switch erbij en ik probeer het netwerk nu als volgt in te richten:

Ziggo -> USG -> Switch -> AP (waarbij de ziggo modem uiteindelijk in bridge modus moet komen te staan en de rPi dus direct aan de switch komt te hangen).

Ik heb alle apparaten uit mijn controller verwijdert en op dit moment zijn zowel de USG als de rPi aangesloten op de Ziggo modem en ben ik daar draadloos mee verbonden.

Nu kan ik de controller gewoon benaderen via het bestaande IP-adres en de USG wordt ook gezien, maar het is onmogelijk hem te adopten. Ik krijg de melding: "Adoption failed (Update required)". Maar updaten vanuit de controller lukt niet.

Verder mogelijk handig om te weten. In de controller staat de USG op 192.168.1.1, maar als ik een Lan Scan doe wordt hij als 192.168.178.37 weergegeven. Ik vermoed dat hier ergens iets misgaat, waardoor de controller niet naar het juiste adres gaat...

[ocmer]

RobbieB schreef op donderdag 26 september 2019 @ 20:04:
Nu kan ik de controller gewoon benaderen via het bestaande IP-adres en de USG wordt ook gezien, maar het is onmogelijk hem te adopten. Ik krijg de melding: "Adoption failed (Update required)". Maar updaten vanuit de controller lukt niet.

Ik heb dit ook gehad met het toevoegen van een nieuw AP aan een bestaand netwerk. Ik heb uiteindelijk via SSH de AP handmatig van de laatste firmware voorzien. Daarna kon ik hem adopten.

https://help.ubnt.com/hc/...irmware-image-via-SSH#SSH

[RobbieB]

ocmer schreef op donderdag 26 september 2019 @ 20:21:
[...]


Ik heb dit ook gehad met het toevoegen van een nieuw AP aan een bestaand netwerk. Ik heb uiteindelijk via SSH de AP handmatig van de laatste firmware voorzien. Daarna kon ik hem adopten.

https://help.ubnt.com/hc/...irmware-image-via-SSH#SSH

Ja, hier had ik al naar gekeken, maar bij beide IP addressen krijg ik een connectie time-out...

[rinkel]

RobbieB schreef op donderdag 26 september 2019 @ 20:04:
Ok, n00b vraagje.

Ik had een AP Pro in mijn netwerk hangen, direct aan mijn Ziggo modem. De controller draait op een RaspberryPi.

SInds gisteren heb ik een USG en een 8-poorts switch erbij en ik probeer het netwerk nu als volgt in te richten:

Ziggo -> USG -> Switch -> AP (waarbij de ziggo modem uiteindelijk in bridge modus moet komen te staan en de rPi dus direct aan de switch komt te hangen).

Ik heb alle apparaten uit mijn controller verwijdert en op dit moment zijn zowel de USG als de rPi aangesloten op de Ziggo modem en ben ik daar draadloos mee verbonden.

Nu kan ik de controller gewoon benaderen via het bestaande IP-adres en de USG wordt ook gezien, maar het is onmogelijk hem te adopten. Ik krijg de melding: "Adoption failed (Update required)". Maar updaten vanuit de controller lukt niet.

Verder mogelijk handig om te weten. In de controller staat de USG op 192.168.1.1, maar als ik een Lan Scan doe wordt hij als 192.168.178.37 weergegeven. Ik vermoed dat hier ergens iets misgaat, waardoor de controller niet naar het juiste adres gaat...

Staat het Ziggo modem in bridge?
Wat gebeurd er als je gaat naar https://192.168.1.1 ?
Het kan zijn dat het ziggo modem je een ipadres aan de WAN kant heeft gegeven (192.168.178.37). Of heb je de WAN kant nog niet aangesloten?

Ik had ook problemen met adopteren en updaten vanuit de controller.
Ik heb het updaten uiteindelijk gedaan via ssh:

code:

upgrade https://dl.ui.com/unifi/firmware/UGW3/4.4.44.5213844/UGW3.v4.4.44.5213844.tar

Pas na de update kon ik m adopten.

Anders de USG resetten en met een utp aan je laptop/pc hangen. Deze krijgt dan een ip van de USG. Dan heb je iig toegang tot de USG. Alleen nog geen internet om de USG te updaten. Dus dan aan de WAN kant een utp naar je Ziggo modem. Dan krijgt de WAN kant een ipadres van je Ziggo modem. (heb je wel even dubbel NAT)

[ Voor 15% gewijzigd door rinkel op 26-09-2019 22:51 ]

[nero355]

RobbieB schreef op donderdag 26 september 2019 @ 20:04:
Ziggo -> USG -> Switch -> AP (waarbij de ziggo modem uiteindelijk in bridge modus moet komen te staan en de rPi dus direct aan de switch komt te hangen).

Ik heb alle apparaten uit mijn controller verwijdert en op dit moment zijn zowel de USG als de rPi aangesloten op de Ziggo modem en ben ik daar draadloos mee verbonden.

Nu kan ik de controller gewoon benaderen via het bestaande IP-adres en de USG wordt ook gezien, maar het is onmogelijk hem te adopten. Ik krijg de melding: "Adoption failed (Update required)". Maar updaten vanuit de controller lukt niet.

Zet die Raspberry Pi gewoon achter de USG direkt op de UniFi Switch en verbind bekabeld met het netwerk = Done!

Zoals je het nu omschrijft probeer je alles vanaf de WAN kant van de USG te doen en dat is niet de bedoeling!

Toen ik alle UniFi spullen binnen had heb ik het ook zo gedaan :
Oude xDSL modem/router -> Switchje -> USG WAN 1 kant - USG LAN 1 kant <- UniFi Switch <- UniFi Accesspoints + Raspberry Pi als Controller + PC NIC #2 op het nieuwe netwerk aangesloten.

En dan gewoon alles stap voor stap opbouwen

[Oesie]

Om (Google) DNS verkeer altijd via de Pi-hole te laten lopen (i.v.m. o.a. Chromecasts) heb ik mijn inziens twee onderstaande opties met de USG:

• Firewall - LAN IN, een regel: Source (all), port 53 > Destination Pi-hole, port 53
• Static route aanbrengen van network 8.8.8.8 & 8.8.4.4 naar next hop IP Pi-hole

Echter zie ik bij de tweede optie elke minuut een query naar google.com en bij de eerste geen. Hierdoor heb ik het idee heb dat deze optie dus niet werkt. Zie ik iets over het hoofd?

[m3gA]

Oesie schreef op vrijdag 27 september 2019 @ 09:35:
Om (Google) DNS verkeer altijd via de Pi-hole te laten lopen (i.v.m. o.a. Chromecasts) heb ik mijn inziens twee onderstaande opties met de USG:

• Firewall - LAN IN, een regel: Source (all), port 53 > Destination Pi-hole, port 53
• Static route aanbrengen van network 8.8.8.8 & 8.8.4.4 naar next hop IP Pi-hole

Echter zie ik bij de tweede optie elke minuut een query naar google.com en bij de eerste geen. Hierdoor heb ik het idee heb dat deze optie dus niet werkt. Zie ik iets over het hoofd?

Wat ben je ingewikkeld bezig? Je kunt toch de pi-hole als dns server opgeven in je dhcp scope?

[Oesie]

m3gA schreef op vrijdag 27 september 2019 @ 09:39:
[...]

Wat ben je ingewikkeld bezig? Je kunt toch de pi-hole als dns server opgeven in je dhcp scope?

Klopt, echter hebben de Chromecasts een hardcoded DNS waardoor ze die niet van de DHCP server overnemen.

[m3gA]

Oesie schreef op vrijdag 27 september 2019 @ 09:42:
[...]

Klopt, echter hebben de Chromecasts een hardcoded DNS waardoor ze die niet van de DHCP server overnemen.

Ah dat is wel heel vies. Probeer eens de google dns te blokkeren op de firewall? Dan zou hij de normale dns server moeten gebruiken.

[ Voor 17% gewijzigd door m3gA op 27-09-2019 09:48 ]

[GeleFles]

Oesie schreef op vrijdag 27 september 2019 @ 09:35:
Om (Google) DNS verkeer altijd via de Pi-hole te laten lopen (i.v.m. o.a. Chromecasts) heb ik mijn inziens twee onderstaande opties met de USG:

• Firewall - LAN IN, een regel: Source (all), port 53 > Destination Pi-hole, port 53
• Static route aanbrengen van network 8.8.8.8 & 8.8.4.4 naar next hop IP Pi-hole

Echter zie ik bij de tweede optie elke minuut een query naar google.com en bij de eerste geen. Hierdoor heb ik het idee heb dat deze optie dus niet werkt. Zie ik iets over het hoofd?

Met die bovenste regel sta je alleen verkeer toe naar je pihole.
Een static route is alleen om verkeer te routeren, dat is niet wat je wilt. (verkeer voor 8.8.8.8 word naar de pi-hole gestuurt, maar de destination blijft 8.8.8.8, je pi-hole is geen router en gaat dat verkeer dus niet doorsturen en dropt het verkeer)

Je zal een NAT regel moeten maken waarmee je verkeer voor 8.8.8.8 en 8.8.4.4 naar het IP adres van je pi-hole stuurt.
NAT past het daadwerkelijke IP pakketje aan, zodat de destination voor het pakketje veranderd word.
een pakketje voor 8.8.8.8 krijgt dan als destination het IP adres van pi-hole, zodat deze het op de juiste manier kan afhandelen.

[RobertMe]

Oesie schreef op vrijdag 27 september 2019 @ 09:35:

• Firewall - LAN IN, een regel: Source (all), port 53 > Destination Pi-hole, port 53

Geen idee wat je verder hebt ingesteld, maar dit is een firewall regel die verkeer afkomstig is van poort 53 en gaat naar het je Pi-Hole op poort 53 matcht. Dit is dus geen 'redirect' maar de match regel.

De USG, of in ieder geval UniFi Controller, ondersteund ook niet het aanpassen van verkeer in de firewall. Via de config.gateway.json kun je dit volgens mij weer wel inregelen.

[ed1703]

RobertMe schreef op vrijdag 27 september 2019 @ 09:56:
[...]

Geen idee wat je verder hebt ingesteld, maar dit is een firewall regel die verkeer afkomstig is van poort 53 en gaat naar het je Pi-Hole op poort 53 matcht. Dit is dus geen 'redirect' maar de match regel.

De USG, of in ieder geval UniFi Controller, ondersteund ook niet het aanpassen van verkeer in de firewall. Via de config.gateway.json kun je dit volgens mij weer wel inregelen.

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "2001": {
                                        "description": "(10.10.20.0/24) Policy DNAT: Force DNS request from VLAN20 (guests) to Router",
                                        "destination": {
                                                "address": "!10.10.20.254",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1.20",
                                        "inside-address": {
                                                "address": "10.10.20.254"
                                        },
                                        "log": "disable",
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }

ofzo...dacht dat dit genoeg was..
Ik stuur het door naar de USG zelf (heeft dnsmasq met wat blacklists, maar een pihole werkt natuurlijk ook)

[Oesie]

GeleFles schreef op vrijdag 27 september 2019 @ 09:53:
[...]


Met die bovenste regel sta je alleen verkeer toe naar je pihole.
Een static route is alleen om verkeer te routeren, dat is niet wat je wilt. (verkeer voor 8.8.8.8 word naar de pi-hole gestuurt, maar de destination blijft 8.8.8.8, je pi-hole is geen router en gaat dat verkeer dus niet doorsturen en dropt het verkeer)

Klinkt logisch Op zich als je het wilt blocken is het dus een oplossing Heb de functionaliteit nog niet getest dus wellicht is het geen werkbare oplossing ;-)

Je zal een NAT regel moeten maken waarmee je verkeer voor 8.8.8.8 en 8.8.4.4 naar het IP adres van je pi-hole stuurt.
NAT past het daadwerkelijke IP pakketje aan, zodat de destination voor het pakketje veranderd word.
een pakketje voor 8.8.8.8 krijgt dan als destination het IP adres van pi-hole, zodat deze het op de juiste manier kan afhandelen.

Hier ga ik even naar kijken (nog geen kaas van gegeten momenteel). Ben benieuwd of dit dan ook kan op al het DNS verkeer op port 53. Daarmee heb ik gelijk mijn IOT apparaten te pakken mochten die nog een andere DNS hard coded hebben.

RobertMe schreef op vrijdag 27 september 2019 @ 09:56:
[...]

Geen idee wat je verder hebt ingesteld, maar dit is een firewall regel die verkeer afkomstig is van poort 53 en gaat naar het je Pi-Hole op poort 53 matcht. Dit is dus geen 'redirect' maar de match regel.

Dit was de eerste regel die gecheckt werd. Maar idd, logisch, een match regel.. af en toe raak je gewoon de draad kwijt

De USG, of in ieder geval UniFi Controller, ondersteund ook niet het aanpassen van verkeer in de firewall. Via de config.gateway.json kun je dit volgens mij weer wel inregelen.

Ik ga even neuzen.

ed1703 schreef op vrijdag 27 september 2019 @ 10:02:
[...]

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "2001": {
                                        "description": "(10.10.20.0/24) Policy DNAT: Force DNS request from VLAN20 (guests) to Router",
                                        "destination": {
                                                "address": "!10.10.20.254",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1.20",
                                        "inside-address": {
                                                "address": "10.10.20.254"
                                        },
                                        "log": "disable",
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }

ofzo...dacht dat dit genoeg was..
Ik stuur het door naar de USG zelf (heeft dnsmasq met wat blacklists, maar een pihole werkt natuurlijk ook)

Thanks! Gelijk even proberen. Doe je dit in de interface of via de cli? Via deze manier dus: https://help.ubnt.com/hc/...-Advanced-Configuration#2

[ Voor 28% gewijzigd door Oesie op 27-09-2019 10:15 ]

[ed1703]

Oesie schreef op vrijdag 27 september 2019 @ 10:08:

Thanks! Gelijk even proberen. Doe je dit in de interface of via de cli?

Je kunt dit via de CLI inkloppen om op die manier ook je config.gateway.json samen te stellen:

https://help.ubnt.com/hc/...SG-Advanced-Configuration

[Oesie]

ed1703 schreef op vrijdag 27 september 2019 @ 10:16:
[...]

Je kunt dit via de CLI inkloppen om op die manier ook je config.gateway.json samen te stellen:

https://help.ubnt.com/hc/...SG-Advanced-Configuration

Moet de entry uiteindelijk in de interface van de controller te zien zijn? Want hij staat er niet tussen (geen conflicterend nummer ook).

Per ongeluk mijn server.log verwijderd en nu krijg ik hier geen nieuwe entries meer in. Hoe staat bij jullie de permissie ingesteld op het bestand in /var/log/unifi/server.log?

code:

root@usgc:/var/log/unifi# ls -all
total 184
drwxr-x---  3 unifi unifi   4096 Sep 27 11:43 .
drwxr-xr-x 10 root  root    4096 Sep 27 00:00 ..
-rw-r-----  1 unifi unifi 164273 Sep 27 12:00 mongod.log
drwxr-x---  2 unifi unifi   4096 Sep 24 20:12 remote
-rw-r-----  1 unifi unifi   2203 Sep 27 11:34 server.log

[ed1703]

Oesie schreef op vrijdag 27 september 2019 @ 12:11:
[...]

Moet de entry uiteindelijk in de interface van de controller te zien zijn? Want hij staat er niet tussen (geen conflicterend nummer ook).

Nee, alleen te zien met een show configuration

Per ongeluk mijn server.log verwijderd en nu krijg ik hier geen nieuwe entries meer in. Hoe staat bij jullie de permissie ingesteld op het bestand in /var/log/unifi/server.log?

code:

root@usgc:/var/log/unifi# ls -all
total 184
drwxr-x---  3 unifi unifi   4096 Sep 27 11:43 .
drwxr-xr-x 10 root  root    4096 Sep 27 00:00 ..
-rw-r-----  1 unifi unifi 164273 Sep 27 12:00 mongod.log
drwxr-x---  2 unifi unifi   4096 Sep 24 20:12 remote
-rw-r-----  1 unifi unifi   2203 Sep 27 11:34 server.log

helpt een 'service rsyslog restart' niet?
edit: Zie dat je het over de CK hebt.. daar is mijn /var/log/unifi leeg. (CK1) Maar werkt verder probleemloos.

[ Voor 5% gewijzigd door ed1703 op 27-09-2019 12:26 ]

[mithras]

@Oesie ik zou gaan voor de oplossing in dit artikel gemeld. Wat jij doet is heel specifiek en enkel voor de Chromecast, zo kan je bezig blijven.

Je kan in de Unifi firewall aangeven dat alle DNS requests die niet vanuit pi-hole komen, teruggestuurd worden naar je pi-hole. De Chromecast houdt dat 8.8.8.8 als DNS hardcoded, en ontvangt daarvan ook een antwoord, maar feitelijk zit je pi-hole daar dan tussen.

Is ook nog een projectje wat ik graag zou willen configureren

[Oesie]

ed1703 schreef op vrijdag 27 september 2019 @ 12:14:
[...]

Nee, alleen te zien met een show configuration

En ik maar zoeken

helpt een 'service rsyslog restart' niet?
edit: Zie dat je het over de CK hebt.. daar is mijn /var/log/unifi leeg. (CK1) Maar werkt verder probleemloos.

Opgelost met een reboot

json aangemaakt, en ik zie gelijk een paar duizend request van de chromecast vandaan komen. Echter lag de rest van mijn internet verkeer eruit dus ergens heb ik nog iets wat elkaar in de weg zit.

mithras schreef op vrijdag 27 september 2019 @ 12:37:
@Oesie ik zou gaan voor de oplossing in dit artikel gemeld. Wat jij doet is heel specifiek en enkel voor de Chromecast, zo kan je bezig blijven.

Je kan in de Unifi firewall aangeven dat alle DNS requests die niet vanuit pi-hole komen, teruggestuurd worden naar je pi-hole. De Chromecast houdt dat 8.8.8.8 als DNS hardcoded, en ontvangt daarvan ook een antwoord, maar feitelijk zit je pi-hole daar dan tussen.

Is ook nog een projectje wat ik graag zou willen configureren

Klopt, dit laatste is ook waar ik nu naar aan het kijken ben. Thanks voor de link!

Volgens mij heb ik het nu juist ingesteld maar nu komt mijn Chromecast helemaal niet meer naar voren
Enfin nu eerst even pauze

[ Voor 12% gewijzigd door Oesie op 27-09-2019 14:18 ]

[geenwindows]

mithras schreef op vrijdag 27 september 2019 @ 12:37:
@Oesie ik zou gaan voor de oplossing in dit artikel gemeld. Wat jij doet is heel specifiek en enkel voor de Chromecast, zo kan je bezig blijven.

Je kan in de Unifi firewall aangeven dat alle DNS requests die niet vanuit pi-hole komen, teruggestuurd worden naar je pi-hole. De Chromecast houdt dat 8.8.8.8 als DNS hardcoded, en ontvangt daarvan ook een antwoord, maar feitelijk zit je pi-hole daar dan tussen.

Is ook nog een projectje wat ik graag zou willen configureren

thnx voor de artikel, zat al een tijdje te zoeken hoe je geforceerd dns kon door sturen naar pi-hole.
wil nog wel kijken hoe ik het gastennetwerk kan uitsluiten en de mogelijk blijven geven om eigen dns request te blijven doen. (deze gaan nu ook naar pi-hole, wat vreemd is want gasten netwerk heeft geen toegang tot prive netwerk )

[nero355]

GeleFles schreef op vrijdag 27 september 2019 @ 09:53:
Een static route is alleen om verkeer te routeren, dat is niet wat je wilt. (verkeer voor 8.8.8.8 word naar de pi-hole gestuurt, maar de destination blijft 8.8.8.8, je pi-hole is geen router en gaat dat verkeer dus niet doorsturen en dropt het verkeer)

Het is een dirty "hack" maar het zorgt er wel voor dat een Google apparaat ineens WEL je lokale DHCP Server respecteert en toch maar WEL de lokale DNS Server gebruikt!

Je zal een NAT regel moeten maken waarmee je verkeer voor 8.8.8.8 en 8.8.4.4 naar het IP adres van je pi-hole stuurt.
NAT past het daadwerkelijke IP pakketje aan, zodat de destination voor het pakketje veranderd word.
een pakketje voor 8.8.8.8 krijgt dan als destination het IP adres van pi-hole, zodat deze het op de juiste manier kan afhandelen.

Ik vind het echt irritant dat ze bij Ubiquiti nog steeds helemaal niks daarmee hebben gedaan, ondanks de request die nog steeds open staat : nero355 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"

Het zal wel in de nieuwe ui.com Community meuk verdwaald zijn geraakt ergens in een hoekje...

[m3gA]

nero355 schreef op vrijdag 27 september 2019 @ 15:09:
[...]

Het is een dirty "hack" maar het zorgt er wel voor dat een Google apparaat ineens WEL je lokale DHCP Server respecteert en toch maar WEL de lokale DNS Server gebruikt!


[...]

Ik vind het echt irritant dat ze bij Ubiquiti nog steeds helemaal niks daarmee hebben gedaan, ondanks de request die nog steeds open staat : nero355 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"

Het zal wel in de nieuwe ui.com Community meuk verdwaald zijn geraakt ergens in een hoekje...

Ze hebben het veel te druk met de UDM. Is een flinke klus. Verwacht dat dit soort dingen wel aangepakt worden maar later.

[nero355]

m3gA schreef op vrijdag 27 september 2019 @ 15:11:
Ze hebben het veel te druk met de UDM. Is een flinke klus. Verwacht dat dit soort dingen wel aangepakt worden maar later.

Nog later

Toen ik die reactie had geplaatst was het al een hele oude Request!

En zelfs zo'n flauwe ASUS Gaming Router schijnt het in de WebGUI te hebben... Kom op zeg!

[m3gA]

nero355 schreef op vrijdag 27 september 2019 @ 15:19:
[...]

Nog later

Toen ik die reactie had geplaatst was het al een hele oude Request!

En zelfs zo'n flauwe ASUS Gaming Router schijnt het in de WebGUI te hebben... Kom op zeg!

Mijn indruk is dat alle resources nu aan de UDM aan het werken zijn.
Ik ben ook nog aan het wachten op een simpele manier om een custom certificaat in de controller te krijgen. Ipv die afschuwelijke keystore.

[Ethirty]

nero355 schreef op vrijdag 27 september 2019 @ 15:19:
[...]

Nog later

Toen ik die reactie had geplaatst was het al een hele oude Request!

En zelfs zo'n flauwe ASUS Gaming Router schijnt het in de WebGUI te hebben... Kom op zeg!

Je weet toch ondertussen wel dat ze zich iedere keer volledig storten op een nieuw project en de rest een beetje vergeten.

Zou niet weten wie zo'n UDM straks moeten kopen. Veel mensen gebruiken het spul juist omdat het niet all-in-one is. En van all-in-one routers zijn er al een miljoen types in omloop.

[Oesie]

N.a.v. jullie tips zou ik denken dat het toch niet zo heel moeilijk zou moeten zijn om het DNS verkeer via de Pi-hole te laten lopen. Maar na een paar uurtjes proberen is het nog niet gelukt. Als ik de json provision dan heb ik geen internet meer. Zie hieronder:

De json code:

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "1": {
                                        "description": "Force DNS redirect to Pi-hole",
                                        "destination": {
                                                "address": "!192.168.1.1",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1",
                                        "inside-address": {
                                                "address": "192.168.1.2"
                                        },
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }
                        }
                }
        }
}

En die komt ook netjes terug in de USG met show configuration:

code:

    nat {
        rule 1 {
            description "Force DNS redirect to Pi-hole"
            destination {
                address !192.168.1.1
                port 53
            }
            inbound-interface eth1
            inside-address {
                address 192.168.1.2
            }
            protocol tcp_udp
            type destination
        }

192.168.1.1 is mijn router
192.168.1.2 is mijn Pi-hole

Iemand wellicht nog een gouden tip?

[ Voor 72% gewijzigd door Oesie op 27-09-2019 17:49 ]

[RobertMe]

Oesie schreef op vrijdag 27 september 2019 @ 16:42:
N.a.v. jullie tips zou ik denken dat het toch niet zo heel moeilijk zou moeten zijn om het DNS verkeer via de Pi-hole te laten lopen. Maar na een paar uurtjes proberen is het nog niet gelukt. Als ik de json provision dan heb ik geen internet meer. Zie hieronder:

De json code:

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "1": {
                                        "description": "Force DNS redirect to Pi-hole",
                                        "destination": {
                                                "address": "!192.168.1.1",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1",
                                        "inside-address": {
                                                "address": "192.168.1.2"
                                        },
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }
                        }
                }
        }
}

En die komt ook netjes terug in de USG met show configuration:

code:

    nat {
        rule 1 {
            description "Force DNS redirect to Pi-hole"
            destination {
                address !192.168.1.1
                port 53
            }
            inbound-interface eth1
            inside-address {
                address 192.168.1.2
            }
            protocol tcp_udp
            type destination
        }

192.168.1.1 is mijn router
192.168.1.2 is mijn Pi-hole

Iemand wellicht nog een gouden tip?

Wat ik me even afvraag, en ook niet zie in het voorbeeld van @ed1703 hierboven. Als dit alle verkeer naar poort 53 dat niet naar je Pi-Hole gaat redirect naar je Pi-Hole, hoe gaat Pi-Hole dan de DNS entries resolven? Want het uitgaande verkeer van Pi-Hole redirect je dan ook naar Pi-Hole? Oftewel een loop.

[nero355]

RobertMe schreef op vrijdag 27 september 2019 @ 17:00:
Wat ik me even afvraag, en ook niet zie in het voorbeeld van @ed1703 hierboven. Als dit alle verkeer naar poort 53 dat niet naar je Pi-Hole gaat redirect naar je Pi-Hole, hoe gaat Pi-Hole dan de DNS entries resolven? Want het uitgaande verkeer van Pi-Hole redirect je dan ook naar Pi-Hole? Oftewel een loop.

Nee, want dat doe je met de regel !192.168.1.2 wat dus betekent "that's not 192.168.1.2" en dat is ook wat @Oesie verkeerd doet : Er staat nu dat al het verkeer wat niet naar de router gaat naar de Pi-Hole moet...

[GeleFles]

Wat @RobertMe zegt inderdaad, nu krijg je helemaal geen DNS verkeer naar internet, omdat het dan naar je pihole gestuurd word.

Wat je kan doen, is het/de ip adres(sen) van de DNS servers op je pihole in de NAT regel opnemen in het destination deel. (ik heb al lang niks met json gedaan, ik kan even niet de juiste syntax uitschrijven als voorbeeld )

[ed1703]

RobertMe schreef op vrijdag 27 september 2019 @ 17:00:
[...]

Wat ik me even afvraag, en ook niet zie in het voorbeeld van @ed1703 hierboven. Als dit alle verkeer naar poort 53 dat niet naar je Pi-Hole gaat redirect naar je Pi-Hole, hoe gaat Pi-Hole dan de DNS entries resolven? Want het uitgaande verkeer van Pi-Hole redirect je dan ook naar Pi-Hole? Oftewel een loop.

Mijn verschil in deze is dat ik het adres van de USG ignore (dat is dus de !) en die stuurt het vervolgens door via eth0 naar buiten. Voor gastennetwerken is dat ook een prima oplossing. De ! in de config.gateway.json kan dus sowieso niet, want je ignored alles behalve de router en stuurt het vervolgens door naar de Pihole, die in de ignore-lijst zit. Maar je hebt hier wel een punt te pakken waar ik ook even niet aan gedacht heb, want dit is DNAT.. dus als de Pi-Hole nu over hetzelfde vlan iets gaat uitsturen naar 1.1.1.1, dan komt het dus inderdaad terug bij de PiHole.

[ Voor 7% gewijzigd door ed1703 op 27-09-2019 17:17 ]

[RobertMe]

@nero355 @ed1703 maar die !... staat binnen de destination. Dat lees ik dus als "alle verkeer dat niet naar Pi-Hole gaat", maar het verkeer afkomstig van Pi-Hole gaat (ook) niet naar Pi-Hole dus krijg je die loop?

[ed1703]

RobertMe schreef op vrijdag 27 september 2019 @ 17:16:
@nero355 @ed1703 maar die !... staat binnen de destination. Dat lees ik dus als "alle verkeer dat niet naar Pi-Hole gaat", maar het verkeer afkomstig van Pi-Hole gaat (ook) niet naar Pi-Hole dus krijg je die loop?

Ja.

[RobertMe]

ed1703 schreef op vrijdag 27 september 2019 @ 17:18:
[...]

Ja.

Maar dan is jouw voorbeeld toch ook fout? Tenzij in jouw voorbeeld dat .254 adres van de router is en de router DNS afhandelt (en daardoor dus dus over een andere interface naar buiten gaat waardoor je geen loop krijgt).

[ed1703]

RobertMe schreef op vrijdag 27 september 2019 @ 17:20:
[...]

Maar dan is jouw voorbeeld toch ook fout? Tenzij in jouw voorbeeld dat .254 adres van de router is en de router DNS afhandelt (en daardoor dus dus over een andere interface naar buiten gaat waardoor je geen loop krijgt).

Dat dus ja.. ik draai voor een gastennetwerk dnsmasq op de USG, zeg tegen de USG dat hij al het DNS verkeer moet sturen naar de guest laninterface en dnsmasq doet dan een vertaling naar het internet wat op een andere interface zit, dus dat boeit de USG niet, want die regel zet ik eigenlijk op het guest-vif, niet op het WAN..

"I'm still learning staat niet voor niets bij m'n avatar hoor "
Het zou wel moeten werken.. als je die PI-Hole multihomed in 2 VLANS maakt en dan je default routes over het vlan stuurt die niet naar het dns-filtering vlan wijst. Maar dat is misschien wat too much.. Ik ging hier even te voortvarend in mee

Andere mogelijkheid is vanaf je USG binnen dnsmasq (ook met 2 vlans) door te verwijzen naar je Pi-Hole die dus in dat andere vlan zit zodat deze geen last van het filter heeft.. als je perse een ad-blocker wilt..
Maargoed, dat is allemaal wel een beetje knutselen. "maar dit is wel tweakers"

[ Voor 31% gewijzigd door ed1703 op 27-09-2019 17:51 ]

[Oesie]

GeleFles schreef op vrijdag 27 september 2019 @ 17:12:
Wat @RobertMe zegt inderdaad, nu krijg je helemaal geen DNS verkeer naar internet, omdat het dan naar je pihole gestuurd word.

Wat je kan doen, is het/de ip adres(sen) van de DNS servers op je pihole in de NAT regel opnemen in het destination deel. (ik heb al lang niks met json gedaan, ik kan even niet de juiste syntax uitschrijven als voorbeeld )

Maar dan zou je alle DNS servers moeten weten van je devices.. nu is dat met de Chromecasts niet zo ingewikkeld.

nero355 schreef op vrijdag 27 september 2019 @ 17:11:
[...]

Nee, want dat doe je met de regel !192.168.1.2 wat dus betekent "that's not 192.168.1.2" en dat is ook wat @Oesie verkeerd doet : Er staat nu dat al het verkeer wat niet naar de router gaat naar de Pi-Hole moet...

Ok, die volg ik. Zou al het verkeer dan naar de router moeten en dan naar de Pi-hole.
Dan zouden de ip's moeten worden omgewisseld.

Einde avond maar is verder kijken. Nu tijd voor wat voedsel.

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "1": {
                                        "description": "Force DNS redirect to Pi-hole",
                                        "destination": {
                                                "address": "!192.168.1.2",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1",
                                        "inside-address": {
                                                "address": "192.168.1.1"
                                        },
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }
                        }
                }
        }
}

ed1703 schreef op vrijdag 27 september 2019 @ 17:24:
[...]
Het zou wel moeten werken.. als je die PI-Hole multihomed in 2 VLANS maakt en dan je default routes over het vlan stuurt die niet naar het dns-filtering vlan wijst. Maar dat is misschien wat too much.. Ik ging hier even te voortvarend in mee

Volgens deze (https://scotthelme.co.uk/...vices-on-my-home-network/) setup heeft iemand het ook werken. Mijn config is daar niet anders van

[ Voor 29% gewijzigd door Oesie op 27-09-2019 18:02 ]

[ed1703]

Oesie schreef op vrijdag 27 september 2019 @ 17:47:
[...]

Volgens deze (https://scotthelme.co.uk/...vices-on-my-home-network/) setup heeft iemand het ook werken. Mijn config is daar niet anders van

Zie ik ja.. ik vraag mij dan alleen even af hoe dat dan kan. Want hoe kan je een dns-request dan afvangen, doorsturen en dan via hetzelfde vlan naar buiten sturen, terwijl dat adres geen ! heeft?? Door de USG met DNSMASQ in je Pihole op te nemen misschien? En daar zet je dan je internet-resolving dns-servers in?
Het enige wat ik nog kan bedenken..

[ Voor 13% gewijzigd door ed1703 op 27-09-2019 17:58 ]

[Oesie]

ed1703 schreef op vrijdag 27 september 2019 @ 17:54:
[...]

Zie ik ja.. ik vraag mij dan alleen even af hoe dat dan kan. Want hoe kan je een dns-request dan afvangen, doorsturen en dan via hetzelfde vlan naar buiten sturen, terwijl dat adres geen ! heeft?? Door de USG met DNSMASQ in je Pihole op te nemen misschien?

Ik ben ook de weg kwijt. Een sudoku oplossen is makkelijker
Ga er nog wel even op broeden.

[nero355]

Oesie schreef op vrijdag 27 september 2019 @ 17:47:
Ok, die volg ik. Zou al het verkeer dan naar de router moeten en dan naar de Pi-hole.
Dan zouden de ip's moeten worden omgewisseld.

Einde avond maar is verder kijken. Nu tijd voor wat voedsel.

code:

{
        "service": {
                "nat": {
                        "rule": {
                                "1": {
                                        "description": "Force DNS redirect to Pi-hole",
                                        "destination": {
                                                "address": "!192.168.1.2",
                                                "port": "53"
                                        },
                                        "inbound-interface": "eth1",
                                        "inside-address": {
                                                "address": "192.168.1.1"
                                        },
                                        "protocol": "tcp_udp",
                                        "type": "destination"
                                }
                        }
                }
        }
}

Dat is ook fout!

Je moet gewoon je Pi-Hole toegang geven naar buiten op poort 53 voor DNS en niks met het IP van je Router doen!


@ed1703 : Voor Pi-Hole in meerdere VLAN's heb ik hier een post gemaakt : nero355 in "[Pi-Hole] Ervaringen & discussie"

[ Voor 5% gewijzigd door nero355 op 27-09-2019 18:34 ]

[geenwindows]

na even te zitten klooien om alle dns geforceerd naar pi-hole te sturen, het uiteindelijk opgegeven en de config te hebben verwijderd, ligt 't gasten gedeelte eruit. (dhcp timeout)
alles herstart, zowel via de controller als de stekker er uit. niks hielp. uiteindelijk naar de instellingen van gasten gegaan, Niks aangepast en enkel op opslaan geklikt, werkt het gasten gedeelte in eens weer ??? WTF ubnt!

[RobertMe]

Heren (@ed1703, @Oesie, @geenwindows, @nero355),
Ik heb nu even de tijd genomen om het zelf in te regelen, en deze werkt, voor mij:

JSON:

{
  "service": {
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect all DNS trafic",
          "destination": {
            "port": "53",
            "address": "!192.168.1.3"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "192.168.1.3",
            "port": "53"
          },
          "source": {
            "address": "!192.168.1.3"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        }
      }
    }
  }
}

Ik heb dus een extra source blok met daarop weer een uitzondering van het IP van Pi-Hole.

Overigenss moet ik wel nog kijken of ik dit blok nu moet herhalen voor elke interface, want naast deze .10 voor "prive" apparaten heb ik ook nog 20 voor IoT en .50 voor gasten.


Edit:
Proberen zonder inbound-interface was niet het slimste idee. Bleef provisionen, commit error, en had SSH sessie open en die kwam op gegeven moment met "going down for reboot" en duurde voor mijn gevoel erg lang voordat die weer up was. Vermoed dus dat het een kwestie van continu die blok vervangen met aangepaste interface wordt
Edit2: Zie dus hieronder. "inbound-interface": "eth1+" werkt ook en matcht alle interfaces waarbij de naam begint met "eth1".

[ Voor 27% gewijzigd door RobertMe op 27-09-2019 20:13 ]

[Jeroen_ae92]

RobertMe schreef op vrijdag 27 september 2019 @ 19:43:
Heren (@ed1703, @Oesie, @geenwindows, @nero355),
Ik heb nu even de tijd genomen om het zelf in te regelen, en deze werkt, voor mij:

JSON:

{
  "service": {
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect all DNS trafic",
          "destination": {
            "port": "53",
            "address": "!192.168.1.3"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "192.168.1.3",
            "port": "53"
          },
          "source": {
            "address": "!192.168.1.3"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        }
      }
    }
  }
}

Ik heb dus een extra source blok met daarop weer een uitzondering van het IP van Pi-Hole.

Overigenss moet ik wel nog kijken of ik dit blok nu moet herhalen voor elke interface, want naast deze .10 voor "prive" apparaten heb ik ook nog 20 voor IoT en .50 voor gasten.

Je kunt ipv eth1.10 ook eth+ gebruiken. Zie het als een soort wildcard op interface niveau. In jouw geval voldoende want ik neem aan dat de Pi maar 1 adres heeft en je vangt af op basis van source is niet Pi en destination is niet Pi.

[RobertMe]

Jeroen_ae92 schreef op vrijdag 27 september 2019 @ 20:00:
[...]


Je kunt ipv eth1.10 ook eth+ gebruiken. Zie het als een soort wildcard op interface niveau. In jouw geval voldoende want ik neem aan dat de Pi maar 1 adres heeft en je vangt af op basis van source is niet Pi en destination is niet Pi.

Just to be sure. Bedoel je dan eth+ wat ik neem aan "alle interfaces" is of eerder eth1+ wat mij dan eerder iets lijkt van "alle virtuele interfaces op eth1".

Alhoewel "alle interfaces" ook niet perse een probleem is, LAN2 poort is niet in gebruik en DNS requests die binnen komen aan de WAN kant zouden ook nogal raar zijn

[Jeroen_ae92]

RobertMe schreef op vrijdag 27 september 2019 @ 20:03:
[...]

Just to be sure. Bedoel je dan eth+ wat ik neem aan "alle interfaces" is of eerder eth1+ wat mij dan eerder iets lijkt van "alle virtuele interfaces op eth1".

Alhoewel "alle interfaces" ook niet perse een probleem is, LAN2 poort is niet in gebruik en DNS requests die binnen komen aan de WAN kant zouden ook nogal raar zijn

Inderdaad, letterlijk eth+. Hierdoor pakt de nat regel alle interfaces muv vti, pppoe en bridge. Op je wan kant hoef je je geen zorgen te maken want nat komt voor firewall. Dus als je poort 53 niet aan de buitenkant open hebt staan, dan is het geen issue.

[RobertMe]

Jeroen_ae92 schreef op vrijdag 27 september 2019 @ 20:06:
[...]

Inderdaad, letterlijk eth+. Hierdoor pakt de nat regel alle interfaces muv vti, pppoe en bridge. Op je wan kant hoef je je geen zorgen te maken want nat komt voor firewall. Dus als je poort 53 niet aan de buitenkant open hebt staan, dan is het geen issue.

Was intussen ook nog wat aan het "zoeken". Was al erachter dat dit direct wordt doorgezet naar iptables en daarin dus ook de eth+ verschijnt voor de "in-interface". Met een beetje Googlen bleek toen al uit officielere docs (Red Hat) dat het dus inderdaad een wildcard is en op Stack Overflow gaf iemand aan dat het eigenlijk gelijk is aan .* van regex en andere varianten ook werken. Dus nu eth1+ gedaan en ook dat werkt.

[xbeam]

Kan je dan geen Hairpin NAT maken.
https://help.ubnt.com/hc/...34-EdgeRouter-Hairpin-NAT

Edit:ik lees dat het al is opgelost.

[ Voor 208% gewijzigd door xbeam op 27-09-2019 21:19 ]

[ed1703]

RobertMe schreef op vrijdag 27 september 2019 @ 19:43:
Heren (@ed1703, @Oesie, @geenwindows, @nero355),
Ik heb nu even de tijd genomen om het zelf in te regelen, en deze werkt, voor mij:

vraag ik mij alleen nog af hoe die oplossing in die eerdere link werkt. Ik heb toch het vermoeden USG als extra tussen-upstream.

[RobertMe]

ed1703 schreef op vrijdag 27 september 2019 @ 21:27:
[...]
vraag ik mij alleen nog af hoe die oplossing in die eerdere link werkt. Ik heb toch het vermoeden USG als extra tussen-upstream.

Kan natuurlijk ook zijn dat Pi-Hole in een ander subnet en/of VLAN draait dan de rest van de apparaten. In mijn geval zou het in eerste instantie ook werken. De PCs etc draaien allemaal op 192.168.10.x en Pi-Hole op 192.168.1.3. Als ik dus de inbound-interface op eth1.10 zet zal die dus wel alle verkeer vanaf de PCs redirecten naar Pi-Hole, maar omdat Pi-Hole in een ander VLAN zit zal zijn verkeer wel gewoon naar buiten mogen gaan.

[nero355]

RobertMe schreef op vrijdag 27 september 2019 @ 19:43:
Heren (@ed1703, @Oesie, @geenwindows, @nero355),
Ik heb nu even de tijd genomen om het zelf in te regelen, en deze werkt, voor mij:

JSON:

{
  "service": {
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect all DNS trafic",
          "destination": {
            "port": "53",
            "address": "!192.168.1.3"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "192.168.1.3",
            "port": "53"
          },
          "source": {
            "address": "!192.168.1.3"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        }
      }
    }
  }
}

Ik heb dus een extra source blok met daarop weer een uitzondering van het IP van Pi-Hole.

Overigenss moet ik wel nog kijken of ik dit blok nu moet herhalen voor elke interface, want naast deze .10 voor "prive" apparaten heb ik ook nog 20 voor IoT en .50 voor gasten.

Ik zou gewoon meerdere regels per VLAN maken om eventuele rare problemen uit te sluiten!

Daarnaast vond ik dit ook erg interessant : https://scotthelme.co.uk/...twork/#comment-3862737092
Het "faken" van de DNS die antwoordt!

[ed1703]

nero355 schreef op zaterdag 28 september 2019 @ 00:18:
[...]

Ik zou gewoon meerdere regels per VLAN maken om eventuele rare problemen uit te sluiten!

Daarnaast vond ik dit ook erg interessant : https://scotthelme.co.uk/...twork/#comment-3862737092
Het "faken" van de DNS die antwoordt!

Zelf ook nog even getest:

code:

/etc/resolv.conf op de linuxlappert:
nameserver 10.10.200.134

/etc/dnsmasq.d/extra.conf op de pihole:

interface=vl200-134 #(10.10.200.134)
interface=lo
bind-interfaces
server=10.10.200.254 #usg-router

config.gateway.json:

<knip niet relevant>
{
    "service": {
        "nat": {
            "rule": {
                 "2002": {
                  "description": "(10.10.200.254) Policy DNAT: Force DNS request from VLAN200 (users) to Pi-Hole",
                         "destination": {
                          "address": "!10.10.200.254",
                           "port": "53"
                              },
                              "inbound-interface": "eth1.200",
                                "inside-address": {
                                  "address": "10.10.200.134"
                                    },
                   "source": {
                                    "address": "!10.10.200.134"
                                    },
                                  "log": "disable",
                                   "protocol": "tcp_udp",
                                   "type": "destination"
                               },
<knip niet relevant>

dig nu.nl @8.8.8.8
;; reply from unexpected source: 10.10.200.134#53, expected 8.8.8.8#53
;; reply from unexpected source: 10.10.200.134#53, expected 8.8.8.8#53
;; reply from unexpected source: 10.10.200.134#53, expected 8.8.8.8#53

Oplossing toevoegen aan json-file:

code:

                "6000": {
                    "description": "Translate DNS to Internal for fixing the source-errors",
                    "destination": {
                    "address": "10.10.200.134",
                    "port": "53"
                    },
                    "log": "disable",
                    "outbound-interface": "eth1.200",
                    "protocol": "tcp_udp",
                    "type": "masquerade"
                    }

root@edg-mint:~# dig nu.nl @8.8.8.8

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> nu.nl @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45747
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nu.nl. IN A

;; ANSWER SECTION:
nu.nl. 21 IN A 13.224.77.92
nu.nl. 21 IN A 13.224.77.58
nu.nl. 21 IN A 13.224.77.128
nu.nl. 21 IN A 13.224.77.66

;; Query time: 2 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Sep 28 09:57:45 CEST 2019
;; MSG SIZE rcvd: 98

host dns.lan 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

dns.lan has address 10.10.200.134

Voldoende nu voor @Oesie om te gaan knutselen

[robertwebbe]

Vraagje:

Ik heb een Ziggo Zakelijk (500/50) aansluiting met een zakelijk DOCSIS 3.1 modem zonder wifi (Ubee UBC1318ZG). Direct daarop heb ik een USG 3P aangesloten. Via een Linksys unmanaged switch zitten hierop een Cloud Key v1 en een AP-AC-Lite.

Als ik periodieke speedtesten via de UI in de controller (5.11.46) doe, dan krijg ik nooit meer dan 200 Mbps download. En als ik daarna via een kabel op mijn laptop een speedtest draai, dan haal ik wel de 500 Mbps download.

Heeft iemand enig idee waarom ik in de controller dan maar 200 Mbps haal?

[ed1703]

robertwebbe schreef op zaterdag 28 september 2019 @ 10:48:
Vraagje:

Ik heb een Ziggo Zakelijk (500/50) aansluiting met een zakelijk DOCSIS 3.1 modem zonder wifi (Ubee UBC1318ZG). Direct daarop heb ik een USG 3P aangesloten. Via een Linksys unmanaged switch zitten hierop een Cloud Key v1 en een AP-AC-Lite.

Als ik periodieke speedtesten via de UI in de controller (5.11.46) doe, dan krijg ik nooit meer dan 200 Mbps download. En als ik daarna via een kabel op mijn laptop een speedtest draai, dan haal ik wel de 500 Mbps download.

Heeft iemand enig idee waarom ik in de controller dan maar 200 Mbps haal?

Die speedtest doet unifi vanaf de USG voor zover ik weet. Dit doet de USG via het proces linkcheck, wat dus in de software afgehandeld moet worden en totaal niet geschikt is om vanaf router-hardware te testen.
Doe je zelf een plezier en test het gewoon vanaf een pc/laptop/tablet/smartphone. De waardes die je vanaf de controller krijgt zijn eigenlijk niet relevant en zeggen niet zoveel.. Om nog maar niet te spreken over het linkcheck proces wat regelmatig crashed als je de speedtest gebruikt. Het is allemaal nogal buggy.

Hier is de ISP-load Poor.. en ik haal gewoon de maximale snelheid vanaf m'n LAN.