[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[SyS_ErroR]

Ik kom er toch niet helemaal aan uit. Ik heb een EdgeRouter Lite, dat is dus een Cavium-based model. Volgens hun website werkt hardware offloading dan via het commando

code:

set system offload ipv4 forwarding enable

en is de setting

code:

set system offload hwnat enable

alleen voor de Mediatek-modellen.

Vandaar dat ik dus ook die foutmelding krijg als ik hwnat probeer in te stellen op mijn Cavium-model.

[Will_M]

SyS_ErroR schreef op woensdag 10 juli 2019 @ 19:42:
Ik kom er toch niet helemaal aan uit. Ik heb een EdgeRouter Lite, dat is dus een Cavium-based model. Volgens hun website werkt hardware offloading dan via het commando

code:

set system offload ipv4 forwarding enable

en is de setting

code:

set system offload hwnat enable

alleen voor de Mediatek-modellen.

Vandaar dat ik dus ook die foutmelding krijg als ik hwnat probeer in te stellen op mijn Cavium-model.

Misschien dat je 't "?" óf "/help" eens kunt gebruiken ná 't ingevoerde commando op die switch (SSH)? Willekeurige commandlines van andere (hét Internet) in een config kopieëren is meestal niet de béste oplossing

[Frank-NL]

nero355 schreef op woensdag 10 juli 2019 @ 19:17:
[...]

[...]

Koop dan ook een Raspberry Pi gewoon, zoals het hoort!

- pricewatch: Raspberry Pi 3 Model B 1GB
- pricewatch: Raspberry Pi universal power supply Wit
- https://www.dataio.nl/san...-pro-a1-u3-geheugenkaart/
- https://www.banggood.com/...odel-Bplus-p-1322542.html
- https://downloads.raspberrypi.org/raspbian_lite_latest
- https://rufus.ie/
- https://help.ubnt.com/hc/...a-APT-on-Debian-or-Ubuntu
- En voor het mooie nog dit prachtig stukje software erbij : https://pi-hole.net/

Als je alles eenmaal binnen hebt ben je grofweg een uurtje aan het knutselen, maar dan heb je ook wat!

Of host je controller op een VPS via AWS Lightsail of soortgelijks? Voor $3.50 per maand heb je bij AWS je eigen Ubuntu met vast IP adres, snapshots en de mogelijkheid later op te schalen. Voor de totale kosten van een RPI oplossing kan je zo 1,5 jaar vooruit. Voor de kosten van een nieuwe CC ben je bijna 5 jaar verder voordat je break-even draait, maar die VPS gaat in ieder geval nooit stuk.

[MAZZA]

Wat kan er mis zijn als de unifi controller niet wil starten op mijn mac? Ik heb java geüpdatet, de controller verwijderd en opnieuw geïnstalleerd maar het helpt niet.

De app start op maar hij blijft op starting unifi controller hangen. Daarna gebeurt er niets meer. Iemand ervaring hiermee?

De search hielp me ook niet verder helaas..

[zeroday]

MAZZA schreef op woensdag 10 juli 2019 @ 21:37:
Wat kan er mis zijn als de unifi controller niet wil starten op mijn mac? Ik heb java geüpdatet, de controller verwijderd en opnieuw geïnstalleerd maar het helpt niet.

De app start op maar hij blijft op starting unifi controller hangen. Daarna gebeurt er niets meer. Iemand ervaring hiermee?

De search hielp me ook niet verder helaas..

logfiles even uitpluizen. Daar staat vaak wel waar die op crashed.
/usr/lib/unifi/log of /var/log/unifi . even zoeken
server.log mongdb.log ..

[SyS_ErroR]

wimmel_1 schreef op woensdag 10 juli 2019 @ 19:48:
[...]


Misschien dat je 't "?" óf "/help" eens kunt gebruiken ná 't ingevoerde commando op die switch (SSH)? Willekeurige commandlines van andere (hét Internet) in een config kopieëren is meestal niet de béste oplossing

Zoals ik in mijn eerdere post al vermoedde, is de optie offload hwnat alleen voor het EdgeRouter X-platform (MediaTek dus). Dit kan dus niet het issue zijn van mijn 100% CPU-load van mijn EdgeRouter 3. Want ik heb de module IPv4 forwarding (dus de juiste setting voor mijn Cavium-model) reeds geactiveerd.

[MAZZA]

zeroday schreef op woensdag 10 juli 2019 @ 21:51:
[...]


logfiles even uitpluizen. Daar staat vaak wel waar die op crashed.
/usr/lib/unifi/log of /var/log/unifi . even zoeken
server.log mongdb.log ..

Thanks. Ik was uit verveling maar een softwareupdate gaan doen van de hele mac en na de bijbehorende reboot werkte het spontaan wel

[The Eagle]

Gisteren toch maar een firmware downgrade van mijn AP's naar de voorlaatste versie uitgevoerd. iPad en telefoon lijken nu een stukje snappyer te reageren allemaal.
USG en switch draaien wel laatste FW overigens

benieuwd wanneer er nou weer eens een goede FW voor de AP's uitkomt want dit schiet zo niet op

[nero355]

Frank-NL schreef op woensdag 10 juli 2019 @ 20:14:
Of host je controller op een VPS via AWS Lightsail of soortgelijks? Voor $3.50 per maand heb je bij AWS je eigen Ubuntu met vast IP adres, snapshots en de mogelijkheid later op te schalen. Voor de totale kosten van een RPI oplossing kan je zo 1,5 jaar vooruit. Voor de kosten van een nieuwe CC ben je bijna 5 jaar verder voordat je break-even draait, maar die VPS gaat in ieder geval nooit stuk.

Dat is leuk, maar heel veel mensen zitten met een PPPoE gebaseerde verbinding thuis en, zolang die niet werkt valt er ook niks te adopteren of te provisioneren richting het internet!

Daarnaast vind ik het gewoon fijner om lokaal volledige controle over alles te hebben.

SyS_ErroR schreef op woensdag 10 juli 2019 @ 22:11:
Zoals ik in mijn eerdere post al vermoedde, is de optie offload hwnat alleen voor het EdgeRouter X-platform (MediaTek dus). Dit kan dus niet het issue zijn van mijn 100% CPU-load van mijn EdgeRouter 3. Want ik heb de module IPv4 forwarding (dus de juiste setting voor mijn Cavium-model) reeds geactiveerd.

Maar heb je ook gecheckt of alle benodigde modules ook echt geactiveerd zijn ?

Daarnaast kan het ook met de versleuteling van de VPN te maken hebben, want de link die ik eerder heb gepost lijkt te suggereren dat niet alles offloaded kan worden ?!

MAZZA schreef op woensdag 10 juli 2019 @ 21:37:
Wat kan er mis zijn als de unifi controller niet wil starten op mijn mac? Ik heb java geüpdatet, de controller verwijderd en opnieuw geïnstalleerd maar het helpt niet.

De app start op maar hij blijft op starting unifi controller hangen. Daarna gebeurt er niets meer. Iemand ervaring hiermee?

De search hielp me ook niet verder helaas..

Ik weet niet hoe het met Java versies op de Mac staat, maar onlangs moest men op de Raspberry Pi de officiële Oracle Java repository toevoegen om naar de laatste Java versie toe te kunnen dus kijk daar ook even naar

[marco282]

lier schreef op woensdag 10 juli 2019 @ 09:08:
[...]

Heb je de nieuwe accesspoints al gereset? Mijn eerste idee is IP conflict...

Ja, in de reset modus werkt alles prima, zodra hij geprovisioned wordt ligt alles plat, maakt niet uit welke van de 3 nieuwe accesspoints ik provision.

[marco282]

nero355 schreef op woensdag 10 juli 2019 @ 17:43:


[...]

Gokje : Wireless Uplink die een loop maakt

Welke switches heb je verder ? Die zouden namelijk zoiets in principe moeten kunnen voorkomen!

Indien mogelijk zou ik dus effe de (R)STP settings nakijken


Verder willen Sonos apparaten zulke rare dingen ook weleens veroorzaken dus kijk daar ook effe naar!

Hmm, wireless uplink zou eventueel een goede kunnen zijn, de switches zijn vrij domme tplink switches. vanuit de controller wireless uplink even uitschakelen en dan proberen.

[Quad]

Vandaag een UniFi AC In-Wall gemonteerd bij m'n ouders. De UAP Pro had z'n beste tijd gehad, en na de verhuizing kon hij 't huis niet voldoende dekking geven.

Beneden hadden m'n ouders 2x 2 outlets en elektra liggen, welke nu toch niet benut werd.
Dus de meest linker outlet opgeofferd, afdekraam iets aangepast zodat boutjes door 't montageplaat op het afdekraam rechtstreeks de inbouwdoos in kon. M3 boutje, 40mm lengte (30mm had ook net gekund denk ik).

Resultaat is dikke prima!



De AC In-Wall werkt ook erg goed, veel beter dan de UAP Pro, maar daar zit alweer een jaar of 5 verschil in..
Beneden verdieping ruim 100Mb/s minimaal, zolder haal ik de 20Mb/s nog. Dus deze is ruim voldoende voor standaard gebruik.

Wel een PoE adapter met AF nodig.. En geen passieve.

[Frank-NL]

nero355 schreef op donderdag 11 juli 2019 @ 17:03:
[...]

Dat is leuk, maar heel veel mensen zitten met een PPPoE gebaseerde verbinding thuis en, zolang die niet werkt valt er ook niks te adopteren of te provisioneren richting het internet!

Daarnaast vind ik het gewoon fijner om lokaal volledige controle over alles te hebben.

Dat laatste snap ik nog wel, hoewel er niks onveiligs of minder controle is aan een controller via internet. Misschien niet ieder zijn ding maar ik zou een remote controller wel als alternatief beschouwen.

Er zijn maar liefst zes methoden om te adopten naar een controller op internet beschreven in de documentatie:

https://help.ubnt.com/hc/...-Remote-UniFi-Controllers

En zeker als je al een lokale controller had is het nog simpeler te wijzigen via set-inform. Dat heb ik ook recent gedaan.

[SmokingCrop]

nero355 schreef op donderdag 11 juli 2019 @ 17:03:
[...]
Dat is leuk, maar heel veel mensen zitten met een PPPoE gebaseerde verbinding thuis en, zolang die niet werkt valt er ook niks te adopteren of te provisioneren richting het internet!

Kan je dat niet gewoon aanpassen via de USG's web-interface alvorens hem te willen koppelen aan een remote controller? Daar heb je dezelfde WAN settings die je later in de controller ook hebt.

Bij provisioneren, neemt die deze lokale WAN settings gewoon over in de controller.

[ed1703]

SmokingCrop schreef op donderdag 11 juli 2019 @ 23:36:
[...]


Kan je dat niet gewoon aanpassen via de USG's web-interface alvorens hem te willen koppelen aan een remote controller? Daar heb je dezelfde WAN settings die je later in de controller ook hebt.

Bij provisioneren, neemt die deze lokale WAN settings gewoon over in de controller.

Klopt helemaal, die settings zijn al gewoon aanwezig, ook zonder controller. Dus dat werkt gewoon.

[Snoeiman]

Tammesp schreef op dinsdag 9 april 2019 @ 17:01:
[...]


Bedankt!

Inmiddels heb ik de KPN gegevens binnen. De aansluiting gaat middels een IPoE connectie en geen PPPoE. Hopelijk gaat dat werken met een Unifi USG Pro.

Hoi Tammesp/community, heb je al enige ervaringen kunnen opdoen met de zakelijke IPoE aansluiting van de KPN? Ik loop tegen het volgende probleem aan:
Ik maak via een Edgerouter de verbinding maak met de KPN modem aan de KPN zijde (eth0) op eth1 zet ik dan het IP adres /29 blok wat ik van de KPN heb gekregen (ik offer hiervan 1 adres op als gateway). als ik op eth1 dan m'n computer hang met een IP adres uit de /29 reeks en als gateway het opgeofferde adres dan werkt dit probleemloos. Ook als ik de Unifi USG Pro erachter hang met een adres uit 't /29 blok werkt dit perfect. Tot hier dus geen problemen...
In het netwerk heb ik een paar servers die ik van buitenaf wil benaderen (DNAT/SNAT/Hairpin), met mijn huidige verbinding (PPPoE) lukt dit perfect (mede omdat ik de Edgerouter dan niet nodig heb). De USG Pro handelt dit allemaal perfect af in de PPPoE situatie (WAN poort van de USG Pro is als PPPoE geconfigureerd).
Als ik de WAN poort van de USG Pro nu configureer met 't IP /29 blok dan werk het wel maar de DNAT(/SNAT/Hairpin) functioneert niet meer. Ik vraag me af of dit ligt aan de config van de Edgeouter of aan de USG Pro?
ALs ik een "simpele" portforwarding doe (op de Egderouter) van eth0 naar eth1 dan functioneert dit wel maar deze gaat dan niet verder tot aan de USG Pro, de DNAT op de USG Pro lijkt dan niet te werken...

Wie kan mij meer inzicht geven bij mijn probleem

[Typhone]

nero355 schreef op woensdag 10 juli 2019 @ 19:17:
[...]

Als je alles eenmaal binnen hebt ben je grofweg een uurtje aan het knutselen, maar dan heb je ook wat!

Als je wat verstand hebt van Linux wel . Als je een hobby'ist bent zoals ik, die uit pure frustratie die kant op is gegaan dan ben je wel even bezig. Probleem zit hem niet zozeer in de tutorials volgen die je her en der kunt vinden maar wat er gebeurt als iets niet werkt zoals het zou moeten. Dan moet je opeens allerlei commando's gaan zoeken die je helemaal niet kent of waar je niet bekend mee bent. Reken per geval maar op minimaal 30 minuten extra .

[nero355]

SmokingCrop schreef op donderdag 11 juli 2019 @ 23:36:
Kan je dat niet gewoon aanpassen via de USG's web-interface alvorens hem te willen koppelen aan een remote controller? Daar heb je dezelfde WAN settings die je later in de controller ook hebt.

Bij provisioneren, neemt die deze lokale WAN settings gewoon over in de controller.

ed1703 schreef op donderdag 11 juli 2019 @ 23:40:
Klopt helemaal, die settings zijn al gewoon aanwezig, ook zonder controller. Dus dat werkt gewoon.

Dus een KPN PPPoE verbinding (Alleen Internet uiteraard) is gewoon te configureren door meteen direkt de USG te benaderen en alles in te stellen

En daarna neemt de UniFi Controller die ook correct over, nadat deze geadopteerd is ?!

Ik dacht dus dat je altijd met het JSON verhaal aan de slag moest... Weer wat geleerd

Typhone schreef op vrijdag 12 juli 2019 @ 10:32:
Als je wat verstand hebt van Linux wel . Als je een hobby'ist bent zoals ik, die uit pure frustratie die kant op is gegaan dan ben je wel even bezig. Probleem zit hem niet zozeer in de tutorials volgen die je her en der kunt vinden maar wat er gebeurt als iets niet werkt zoals het zou moeten. Dan moet je opeens allerlei commando's gaan zoeken die je helemaal niet kent of waar je niet bekend mee bent. Reken per geval maar op minimaal 30 minuten extra .

Een tijdje geleden bleek het belangrijkste onderdeel een snel microSDXC kaartje te zijn en dan gaat het allemaal rap genoeg, tenzij je inderdaad pech hebt!

Maar dan kan je natuurlijk altijd om hulp vragen in dit topic

Verder heeft @SmokingCrop een heel mooi topic ervoor gemaakt : [handleiding] Raspberry Pi met UniFi controller en Pi-hole dus dat kan je ook nog proberen!

[RobertMe]

nero355 schreef op vrijdag 12 juli 2019 @ 17:01:
[...]


[...]

Dus een KPN PPPoE verbinding (Alleen Internet uiteraard) is gewoon te configureren door meteen direkt de USG te benaderen en alles in te stellen

En daarna neemt de UniFi Controller die ook correct over, nadat deze geadopteerd is ?!

Ik dacht dus dat je altijd met het JSON verhaal aan de slag moest... Weer wat geleerd

De exacte details weet ik niet (want heb zelf Ziggo dus dit niet nodig), maar volgens mij is dat allemaal wel nog relatief nieuw. Echt maximaal een jaar dat dat in de firmware zelf zit. Daarnaast is het dus alleen PPPoE wat je kunt configureren. Het hele VLAN gebeuren blijft volgens mij wel een issue lees: JSON voor nodig.

[SmokingCrop]

nero355 schreef op vrijdag 12 juli 2019 @ 17:01:
[...]


[...]

Dus een KPN PPPoE verbinding (Alleen Internet uiteraard) is gewoon te configureren door meteen direkt de USG te benaderen en alles in te stellen

En daarna neemt de UniFi Controller die ook correct over, nadat deze geadopteerd is ?!

Ik dacht dus dat je altijd met het JSON verhaal aan de slag moest... Weer wat geleerd


[...]

Een tijdje geleden bleek het belangrijkste onderdeel een snel microSDXC kaartje te zijn en dan gaat het allemaal rap genoeg, tenzij je inderdaad pech hebt!

Maar dan kan je natuurlijk altijd om hulp vragen in dit topic

Verder heeft @SmokingCrop een heel mooi topic ervoor gemaakt : [handleiding] Raspberry Pi met UniFi controller en Pi-hole dus dat kan je ook nog proberen!

Hoe het in Nederland zit met die PPPoE weet ik niet, daar het in België erg simpel is.
Ofwel gewoon via DHCP (Telenet EMTA) ofwel via een simpele username en wachtwoord voor PPPoE (Proximus in bridge-mode) zonder VLAN configuratie.

Als je het in de controller kan instellen via de GUI, dan lukt het ook op voorhand.
Indien niet, dan wordt het wellicht inderdaad wat moeilijker.

[ed1703]

nero355 schreef op vrijdag 12 juli 2019 @ 17:01:
[...]


[...]

Dus een KPN PPPoE verbinding (Alleen Internet uiteraard) is gewoon te configureren door meteen direkt de USG te benaderen en alles in te stellen

En daarna neemt de UniFi Controller die ook correct over, nadat deze geadopteerd is ?!

Hoe lang dat al werkt weet ik niet, maar er is al een bedrijf die er brood in wil verdienen.
https://hostifi.net/
Zou er alleen nooit een plan nemen, maar dat terzijde. Spin ik liever wat op in de EU of zelfs beperkt tot NL.

[nero355]

ed1703 schreef op vrijdag 12 juli 2019 @ 17:21:
Hoe lang dat al werkt weet ik niet, maar er is al een bedrijf die er brood in wil verdienen.
https://hostifi.net/
Zou er alleen nooit een plan nemen, maar dat terzijde. Spin ik liever wat op in de EU of zelfs beperkt tot NL.

Dat kwam inderdaad al eerder voorbij, maar dat boeit me verder niet : Lokaal beheer FTW!!!

En anders pak ik wel een VPS'je bij TransIP of zo...


Maar vooral het los configureren en daarna adopteren met behoud van settings vond ik erg apart, omdat de USG zelf een melding geeft iets in de trant van "Alle aanpassingen die je hier maakt zullen door de UniFi Controller worden overschreven bij de volgende Provisioning actie!" op het moment dat je in de WebGUI inlogt

[ed1703]

nero355 schreef op vrijdag 12 juli 2019 @ 17:31:
[...]

Dat kwam inderdaad al eerder voorbij, maar dat boeit me verder niet : Lokaal beheer FTW!!!

En anders pak ik wel een VPS'je bij TransIP of zo...


Maar vooral het los configureren en daarna adopteren met behoud van settings vond ik erg apart, omdat de USG zelf een melding geeft iets in de trant van "Alle aanpassingen die je hier maakt zullen door de UniFi Controller worden overschreven bij de volgende Provisioning actie!" op het moment dat je in de WebGUI inlogt

Ik denk dat je de SSH-banner bedoelt?

Want de info in de webinterface klopt namelijk wel:

Please note that because this Gateway is managed the LAN settings here are only temporary and will be overwritten with the settings from the UniFi Controller when the Gateway is next provisioned.

********************** WARNING! **********************
* Configuration changes made here are not persistent. *
* They will be overwritten by the controller on next *
* provision. Configuration must be done in controller. *
********************************************************

Het is namelijk een beetje ja en nee.. tot op bepaalde hoogte kun je namelijk via scripts in /config/scripts/post-config.d wat zaken bij een reload inregelen. Zo heb ik daar wat extra iptables forward regels in staan voor m'n openvpn vanuit m'n transip vps.. en dat script blijft ook bij een upgrade gewoon staan en voert de usg automatisch uit bij een reload..

[Typhone]

@nero355
Haha ja gelijk heb je. Ik heb de controller in de cloud gehost met ssl certificaat en de ramsamsam erbij. Maar ook daarvoor moet je veel handelingen doen die lichtelijk buiten scope van dit topic vallen. Maar goed daar zijn we Tweakers voor nietwaar?

[Cartman!]

ed1703 schreef op vrijdag 12 juli 2019 @ 17:21:
[...]

Hoe lang dat al werkt weet ik niet, maar er is al een bedrijf die er brood in wil verdienen.
https://hostifi.net/
Zou er alleen nooit een plan nemen, maar dat terzijde. Spin ik liever wat op in de EU of zelfs beperkt tot NL.

Hebben ook een gratis plan zo te zien maar vind het toch tricky om die poorten zomaar open te gooien. Draai zelf de controller op m'n Synology NAS met Docker.

[Tylen]

ed1703 schreef op vrijdag 12 juli 2019 @ 17:21:
[...]

Hoe lang dat al werkt weet ik niet, maar er is al een bedrijf die er brood in wil verdienen.
https://hostifi.net/
Zou er alleen nooit een plan nemen, maar dat terzijde. Spin ik liever wat op in de EU of zelfs beperkt tot NL.

Hmm dat is business. Zelf draai ik ook wat hosting en dit kan er nog wel bij. Toch eens in verdiepen hahaha

[Jeroen_ae92]

SyS_ErroR schreef op dinsdag 9 juli 2019 @ 21:01:
Kan iemand eens meekijken op de config-file van mijn Ubiquiti EdgeRouter Lite? Ik heb twee units draaien op twee locaties, met daartussen een IPSec-VPN tunnel. Beide EdgeRouters zijn gekoppeld aan een Ziggo 250/25Mbit verbinding (met de router in bridge-mode). De VPN tunnel werkt prima.

Nu is het issue dat de CPU-load op beide modellen erg hoog (100%) als er veel regulier verkeer overheen gaat (dus geen VPN-verkeer). Bijvoorbeeld, als ik van http://speed.transip.nl de 1GB.bin-file download, piekt de EdgeRouter op 100% CPU en haal ik ongeveer 200Mbit.

Ik heb het issue kunnen reproduceren op beide locaties (en ik weet dus niet of de VPN tunnel daar ook maar iets mee te maken heeft). Volgens mij is offloading al geactiveerd

code:

set system offload ipsec enable
The specified configuration node already exists

.

Hierbij de config file van één van de twee locaties (sanitized).

code:

firewall {
    all-ping enable
    broadcast-ping disable
    group {
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN to internal"
        rule 1 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 2 {
            action accept
            description "VPN_Tunnel NAAM"
            log disable
            protocol all
            source {
                address 192.168.1.0/24
                group {
                }
            }
        }
        rule 4 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        rule 1 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 2 {
            action accept
            description "VPN_Tunnel NAAM"
            log disable
            protocol all
            source {
                address 192.168.1.0/24
                group {
                }
            }
        }
        rule 5 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        address dhcp
        description Internet
        duplex auto
        firewall {
            in {
                name WAN_IN
            }
            local {
                name WAN_LOCAL
            }
        }
        speed auto
    }
    ethernet eth1 {
        address 192.168.0.1/24
        description Local
        duplex auto
        ip {
        }
        speed auto
    }
    ethernet eth2 {
        address 192.168.3.1/24
        description "Local 2"
        disable
        duplex auto
        ip {
        }
        speed auto
    }
    loopback lo {
    }
    vti vti0 {
        address 192.168.100.2/24
        ip {
        }
        mtu 1436
    }
}
port-forward {
    auto-firewall enable
    hairpin-nat enable
    lan-interface eth1
    rule 1 {
        description APPLICATIE
        forward-to {
            address 192.168.0.5
        }
        original-port 53121
        protocol tcp
    }
    wan-interface eth0
}
protocols {
    ospf {
        area 0.0.0.0 {
            area-type {
                normal
            }
            network 192.168.0.0/24
            network 192.168.100.0/24
        }
        parameters {
            abr-type cisco
            router-id 192.168.0.1
        }
    }
    static {
    }
}
service {
    dhcp-server {
        disabled false
        hostfile-update disable
        shared-network-name LAN1 {
            authoritative disable
            subnet 192.168.0.0/24 {
                default-router 192.168.0.1
                dns-server 192.168.0.1
                lease 86400
                start 192.168.0.100 {
                    stop 192.168.0.199
                }
            }
        }
        static-arp disable
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth1
            listen-on eth2
        }
    }
    gui {
        http-port 80
        https-port 443
        older-ciphers enable
    }
    mdns {
        repeater {
            interface eth1
            interface vti0
        }
    }
    nat {
        rule 5001 {
            outbound-interface eth0
            type masquerade
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
}
system {
    domain-name router-naam.local
    host-name router-naam
    login {
        user username {
            authentication {
                encrypted-password BLA
                plaintext-password
            }
            level admin
        }
    }
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    offload {
        hwnat disable
        ipsec enable
        ipv4 {
            forwarding enable
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone Europe/Amsterdam
    traffic-analysis {
        dpi disable
        export disable
    }
}
traffic-control {
}
vpn {
    ipsec {
        auto-firewall-nat-exclude enable
        esp-group FOO0 {
            compression disable
            lifetime 3600
            mode tunnel
            pfs enable
            proposal 1 {
                encryption aes256
                hash sha256
            }
        }
        ike-group FOO0 {
            ikev2-reauth no
            key-exchange ikev1
            lifetime 28800
            proposal 1 {
                dh-group 14
                encryption aes256
                hash sha256
            }
        }
        ipsec-interfaces {
            interface eth0
        }
        nat-networks {
            allowed-network 0.0.0.0/0 {
            }
        }
        nat-traversal enable
        site-to-site {
            peer ANDER-IP {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret BLA
                }
                connection-type initiate
                description ""
                ike-group FOO0
                ikev2-reauth inherit
                local-address MIJN-IP
                vti {
                    bind vti0
                    esp-group FOO0
                }
            }
        }
    }
}


/* Warning: Do not remove the following line. */
/* === vyatta-config-version: "config-management@1:conntrack@1:cron@1:dhcp-relay@1:dhcp-server@4:firewall@5:ipsec@5:nat@3:qos@1:quagga@2:suspend@1:system@4:ubnt-pptp@1:ubnt-udapi-server@1:ubnt-unms@1:ubnt-util@1:vrrp@1:webgui@1:webproxy@1:zone-policy@1" === */
/* Release version: v1.10.8.5142440.181120.1645 */

Zie je hetzelfde gedrag als je de mdns repeater uitzet?

[Eddo-79]

RobertMe schreef op vrijdag 12 juli 2019 @ 17:03:
[...]

De exacte details weet ik niet (want heb zelf Ziggo dus dit niet nodig), maar volgens mij is dat allemaal wel nog relatief nieuw. Echt maximaal een jaar dat dat in de firmware zelf zit. Daarnaast is het dus alleen PPPoE wat je kunt configureren. Het hele VLAN gebeuren blijft volgens mij wel een issue lees: JSON voor nodig.

Bij KPN en XS4ALL is het simpel:
- Alleen pppoe internet is standaard te configureren in de Ubiquiti controller.
- Pppoe internet + iptv moet met een json file, waarbij je in de controller gui dan niet meer je public ip adres kan zien.
- Pppoe internet + iptv + voip moet met een json file.

KPN gebruikt voip via een apart vlan (4 iptv, 6 internet, 7 voip meen ik te herinneren), xs4all doet voip over het internet vlan en heeft dus alleen vlan 4 en 6.

Ubiquiti zou dit volgens mij eenvoudig in de gui kunnen oplossen...maar of t prio voor ze heeft betwijfel ik.

[insomniac]

Ik wil m'n 48p 500w graag met fiber gaan verbinden met o.a. de 8p 150w.
Is het mogelijk om de sfp+ poorten met een UF-MM-10G SFP+ module te laten communiceren met de sfp poort met een UF-MM-1G SFP? Waarbij uiteraard de snelheid op 1Gb ingesteld staat.

Ik heb namelijk alle 4 de SFP poorten nodig van de 48p, maar heb verder nog geen sfp+ in m'n hardware zitten. Ik vind het zonde om nu sfp modules te kopen om ze later weer om te ruilen voor sfp+ .

[marco282]

nero355 schreef op woensdag 10 juli 2019 @ 17:43:

[...]

Gokje : Wireless Uplink die een loop maakt

Welke switches heb je verder ? Die zouden namelijk zoiets in principe moeten kunnen voorkomen!

Indien mogelijk zou ik dus effe de (R)STP settings nakijken


Verder willen Sonos apparaten zulke rare dingen ook weleens veroorzaken dus kijk daar ook effe naar!

Even een update, het was inderdaad de wireless uplink!

[The Eagle]

OK, ik heb nu een vreemde.
Vorige week mijn AP AC Pro's teruggezet naar FW 4.0.21.9965 Sindsdien op alle AP's zeer hoge retry rates (66-100%)
Unify switch 8 POE 60W draait op FW 4.0.42.10433 en mijn USG op 4.4.41.5193700 (die zitten wel laatste versie). Ook controller draait op laatste versie (5.10.25, was een bitch om te upgraden ivm java issues).

1. Is dit een bekend issue / bug met een van de FW's en is dit te fixen?
2. Kan ik ergens de historie zien van de FW's van de devices? Het zou kunnen zijn dat ik me vergist heb en eerder een nog wat oudere maar stuk stabielere FW draaide en ik dus nog verder terug zou moeten.

[TheNephilim]

The Eagle schreef op dinsdag 16 juli 2019 @ 10:04:
OK, ik heb nu een vreemde.
Vorige week mijn AP AC Pro's teruggezet naar FW 4.0.21.9965 Sindsdien op alle AP's zeer hoge retry rates (66-100%)
Unify switch 8 POE 60W draait op FW 4.0.42.10433 en mijn USG op 4.4.41.5193700 (die zitten wel laatste versie). Ook controller draait op laatste versie (5.10.25, was een bitch om te upgraden ivm java issues).

1. Is dit een bekend issue / bug met een van de FW's en is dit te fixen?
2. Kan ik ergens de historie zien van de FW's van de devices? Het zou kunnen zijn dat ik me vergist heb en eerder een nog wat oudere maar stuk stabielere FW draaide en ik dus nog verder terug zou moeten.

Forums staan er vol mee: https://community.ui.com/...-8167-8d0b4925b4eb?page=1

Hoe heb je die downgrade uitgevoerd? Ik heb de URL in de controller bij de AP ingevoerd, maar er gebeurd niks... ook geen foutmelding . Wil ook graag downgraden namelijk, draadloos internet is een stukje minder stabiel, de vorige versie was perfect eigenlijk.

[The Eagle]

TheNephilim schreef op dinsdag 16 juli 2019 @ 10:11:
[...]


Forums staan er vol mee: https://community.ui.com/...-8167-8d0b4925b4eb?page=1

Hoe heb je die downgrade uitgevoerd? Ik heb de URL in de controller bij de AP ingevoerd, maar er gebeurd niks... ook geen foutmelding . Wil ook graag downgraden namelijk, draadloos internet is een stukje minder stabiel, de vorige versie was perfect eigenlijk.

Volgens mij zoals jij beschrijft. In de controller het AP openen, en dan cutom firmware upgrade juiste URL er in. Kreeg een popup, moest ik bevestigen en het ding ging aan de slag. Ik ga er vanuit dat het AP daar zelf voor op internet moet kunnen (juiste gateway en DNS ingevuld) en dat je evt popups disabled moet hebben in je bworser, zou je nog naar kunnen kijken.

En dat die forums vol staan met die buggy laatste firmware wee ik, daarom ben ik juist terug gegaan. Alleen dus niet met de switch, maar lijkt me stug dat dat iets met de retryrates van de AP's te maken heeft. Vandaar ook mijn vragen of ik iets over het hoofd zie

[Remco Tr]

Ik forceer al het DNS verkeer naar mn pihole dmv NAT rule. Alleen als mn pihole weg valt pakken mn clients niet de sec dns server(1.1.1.1) Dit komt natuurlijk omdat alles qua dns naar de pihole gaat ook als deze offline is.

Is hier nog iets van safety in te maken dat als de pihole offline gaat toch de sec dns server word gebruikt?

Edit: Edge router X

[ Voor 3% gewijzigd door Remco Tr op 16-07-2019 13:38 ]

[ed1703]

Remco Tr schreef op dinsdag 16 juli 2019 @ 13:30:
Ik forceer al het DNS verkeer naar mn pihole dmv NAT rule. Alleen als mn pihole weg valt pakken mn clients niet de sec dns server(1.1.1.1) Dit komt natuurlijk omdat alles qua dns naar de pihole gaat ook als deze offline is.

Is hier nog iets van safety in te maken dat als de pihole offline gaat toch de sec dns server word gebruikt?

Edit: Edge router X

1.1.1.1 moet dan in de uitzonderingenlijst (zie ook https://community.ui.com/...a4-4a05-a18a-48fd90f12ab0)
Echter, dan heb je wel nog steeds wachttijd voor zover mijn DNS-kennis up-to-date is?
Als je dat niet wilt zal je iets met een 2e pi hole moeten doen en daarop VRRP/Unicast (keepalived) of OSPF-ZEBRA/Anycast via een extra loopback of eth0-subinterface moeten bouwen...
Zelf knutsel ik liever met Anycast (ipconflicten zijn dan uitgesloten).. 10.1.1.53 bijvoorbeeld
Voor mijzelf is dit wel een "omdat het kan" ding, want wanneer gaat een Pi nu down?

[Broodro0ster]

The Eagle schreef op dinsdag 16 juli 2019 @ 10:04:
OK, ik heb nu een vreemde.
Vorige week mijn AP AC Pro's teruggezet naar FW 4.0.21.9965 Sindsdien op alle AP's zeer hoge retry rates (66-100%)
Unify switch 8 POE 60W draait op FW 4.0.42.10433 en mijn USG op 4.4.41.5193700 (die zitten wel laatste versie). Ook controller draait op laatste versie (5.10.25, was een bitch om te upgraden ivm java issues).

1. Is dit een bekend issue / bug met een van de FW's en is dit te fixen?
2. Kan ik ergens de historie zien van de FW's van de devices? Het zou kunnen zijn dat ik me vergist heb en eerder een nog wat oudere maar stuk stabielere FW draaide en ik dus nog verder terug zou moeten.

Exact hetzelfde probleem hier. Ben terug naar 4.0.42 gegaan en toen was het terug over.
Ik wou de downgrade doen omdat ik opeens last kreeg met m'n Sonos devices en een versterker met Spotify connect. De toestellen hadden nog verbinding met internet, maar de broadcasting in huis werkte niet meer.

Door een setting in de controller te veranderen werken ze nu terug met 4.0.42, maar downgraden had ik fijner gevonden...

[Remco Tr]

ed1703 schreef op dinsdag 16 juli 2019 @ 15:33:
[...]

1.1.1.1 moet dan in de uitzonderingenlijst (zie ook https://community.ui.com/...a4-4a05-a18a-48fd90f12ab0)
Echter, dan heb je wel nog steeds wachttijd voor zover mijn DNS-kennis up-to-date is?
Als je dat niet wilt zal je iets met een 2e pi hole moeten doen en daarop VRRP/Unicast (keepalived) of OSPF-ZEBRA/Anycast via een extra loopback of eth0-subinterface moeten bouwen...
Zelf knutsel ik liever met Anycast (ipconflicten zijn dan uitgesloten).. 10.1.1.53 bijvoorbeeld
Voor mijzelf is dit wel een "omdat het kan" ding, want wanneer gaat een Pi nu down?

Top hier ga ik uitkomen!

[Yoshimi]

The Eagle schreef op dinsdag 16 juli 2019 @ 10:04:
OK, ik heb nu een vreemde.
Vorige week mijn AP AC Pro's teruggezet naar FW 4.0.21.9965 Sindsdien op alle AP's zeer hoge retry rates (66-100%)
Unify switch 8 POE 60W draait op FW 4.0.42.10433 en mijn USG op 4.4.41.5193700 (die zitten wel laatste versie). Ook controller draait op laatste versie (5.10.25, was een bitch om te upgraden ivm java issues).

1. Is dit een bekend issue / bug met een van de FW's en is dit te fixen?
2. Kan ik ergens de historie zien van de FW's van de devices? Het zou kunnen zijn dat ik me vergist heb en eerder een nog wat oudere maar stuk stabielere FW draaide en ik dus nog verder terug zou moeten.

Dat is een bekend probleem in de configuratie zoals jij (en ook ik thuis) draai. In de laatste versie van de controller (5.10.25) hebben ze die hoge retry rates ‘getweaked’ (lees verdoezeld), en is dat visueel in de statistieken pas opgelost als je ook firmware 4.0.42 installeert. Die twee versienummers zijn aan elkaar gebonden om het euvel van high retries op te lossen. Ik zou me er niet teveel zorgen over maken zolang je verbinding stabiel is .

[edit] heb je Auto-Optimize Network of High Performance Devices on 5G aan staan? Op de ubnt community wordt doorgaans geadviseerd dit uit te schakelen (feature nog niet productierijp).

Daarnaast kun je via SSH op je access point middels ifconfig ook zelf eventuele hoge retries inzichtelijk maken. Als je een excessief hoge waarde bij RX/TX dropped packets ziet, dan wijst dat in veel gevallen op daadwerkelijke retries en packet loss. Maar je zult in jouw setup zien dat dat reuze meevalt .

[ Voor 17% gewijzigd door Yoshimi op 16-07-2019 18:23 ]

[nero355]

Remco Tr schreef op dinsdag 16 juli 2019 @ 13:30:
Ik forceer al het DNS verkeer naar mn pihole dmv NAT rule. Alleen als mn pihole weg valt pakken mn clients niet de sec dns server(1.1.1.1) Dit komt natuurlijk omdat alles qua dns naar de pihole gaat ook als deze offline is.

Is hier nog iets van safety in te maken dat als de pihole offline gaat toch de sec dns server word gebruikt?

Edit: Edge router X

Zoals al eerder vaker verteld : Dat moet je anders oplossen, want Primary en Secondary DNS Server bestaan niet!

En eigenlijk is dit gewoon de beste manier : https://discourse.pi-hole...-pihole-ive-done-it/12716

[The Eagle]

Yoshimi schreef op dinsdag 16 juli 2019 @ 18:15:
[...]


Dat is een bekend probleem in de configuratie zoals jij (en ook ik thuis) draai. In de laatste versie van de controller (5.10.25) hebben ze die hoge retry rates ‘getweaked’ (lees verdoezeld), en is dat visueel in de statistieken pas opgelost als je ook firmware 4.0.42 installeert. Die twee versienummers zijn aan elkaar gebonden om het euvel van high retries op te lossen. Ik zou me er niet teveel zorgen over maken zolang je verbinding stabiel is .

Laat ze eerts maar eens een stabiele versie uitbrengen van de AP firmware dan, kijken we dan verder

[edit] heb je Auto-Optimize Network of High Performance Devices on 5G aan staan? Op de ubnt community wordt doorgaans geadviseerd dit uit te schakelen (feature nog niet productierijp).

Nope, nooit aan staan gehad ook. Zat nog wel met een schuin oog naar DTIM settings (default 1) te loeren, maar dat lijkt ook niet relevant et zijn in deze. Het is niet dat ik 1001 devices heb ofzo, wireless zijn er max 3 telefoons, een ipad en een laptop verbonden.

Daarnaast kun je via SSH op je access point middels ifconfig ook zelf eventuele hoge retries inzichtelijk maken. Als je een excessief hoge waarde bij RX/TX dropped packets ziet, dan wijst dat in veel gevallen op daadwerkelijke retries en packet loss. Maar je zult in jouw setup zien dat dat reuze meevalt .

Ga ik ff naar kijken, thanks

* The Eagle zit nu te balen dat ie een vrije avond van 8 tot half 12 die controller heeft zitten upgraden (die java, die ) terwijl dat niet nodig was.

[Yoshimi]

The Eagle schreef op dinsdag 16 juli 2019 @ 18:47:
[...]

Laat ze eerts maar eens een stabiele versie uitbrengen van de AP firmware dan, kijken we dan verder

[...]

Nope, nooit aan staan gehad ook. Zat nog wel met een schuin oog naar DTIM settings (default 1) te loeren, maar dat lijkt ook niet relevant et zijn in deze. Het is niet dat ik 1001 devices heb ofzo, wireless zijn er max 3 telefoons, een ipad en een laptop verbonden.

[...]

Ga ik ff naar kijken, thanks

* The Eagle zit nu te balen dat ie een vrije avond van 8 tot half 12 die controller heeft zitten upgraden (die java, die ) terwijl dat niet nodig was.

Je hebt exact dezelfde setup (qua firmware revisies) als hier thuis. Mij viel dat ook op, maar ik heb het genegeerd. 4.0.21 vind ik persoonlijk nog steeds de meest stabiele versie. Updaten doe ik pas als er geen 10+ pagina's aan feedback op de releasepost komen . Wanneer je veel Apple producten in gebruik hebt, is het advies de DTIM waarde naar 3 te zetten (heb ik thuis ook gedaan).

[The Eagle]

Yoshimi schreef op dinsdag 16 juli 2019 @ 18:53:
[...]


Je hebt exact dezelfde setup (qua firmware revisies) als hier thuis. Mij viel dat ook op, maar ik heb het genegeerd. 4.0.21 vind ik persoonlijk nog steeds de meest stabiele versie. Updaten doe ik pas als er geen 10+ pagina's aan feedback op de releasepost komen . Wanneer je veel Apple producten in gebruik hebt, is het advies de DTIM waarde naar 3 te zetten (heb ik thuis ook gedaan).

Zag je daar direct effect van dan? Wil best die DTIM aanpassen, maar de enige die dat gaat merken ben ik op de ipad en Mrs Eagle op dr iPhone. Nou wordt die ipad vnl voor GoT gebruikt dus das een goede reden an sich Maar moet wel hout snijden en daar lees ik wat gemengde verhalen zo lijkt het. Iets met wat makkelijker in en uit sleep mode gaan ofzo
Als je een goede bron hebt, graag

Edit: overigens verder nog 2 androids, die lijken het vrij goed te doen.

Edit2: https://www.sniffwifi.com...to-sleep-go-to-sleep.html
Dit lijkt eea aardig te onderbouwen. Gaan we proberen, baat het niet dan schaadt het niet. Keep u posted

[ Voor 16% gewijzigd door The Eagle op 16-07-2019 21:30 ]

[Yoshimi]

The Eagle schreef op dinsdag 16 juli 2019 @ 20:50:
[...]

Zag je daar direct effect van dan? Wil best die DTIM aanpassen, maar de enige die dat gaat merken ben ik op de ipad en Mrs Eagle op dr iPhone. Nou wordt die ipad vnl voor GoT gebruikt dus das een goede reden an sich Maar moet wel hout snijden en daar lees ik wat gemengde verhalen zo lijkt het. Iets met wat makkelijker in en uit sleep mode gaan ofzo
Als je een goede bron hebt, graag

Edit: overigens verder nog 2 androids, die lijken het vrij goed te doen.

Edit2: https://www.sniffwifi.com...to-sleep-go-to-sleep.html
Dit lijkt eea aardig te onderbouwen. Gaan we proberen, baat het niet dan schaadt het niet. Keep u posted

Yes, die link had ik net weer teruggevonden. Weliswaar al iets ouder, maar nog steeds relevant en inderdaad goed onderbouwd. Ben benieuwd of het je helpt

[Broodro0ster]

Yoshimi schreef op dinsdag 16 juli 2019 @ 18:15:
[...]


Dat is een bekend probleem in de configuratie zoals jij (en ook ik thuis) draai. In de laatste versie van de controller (5.10.25) hebben ze die hoge retry rates ‘getweaked’ (lees verdoezeld), en is dat visueel in de statistieken pas opgelost als je ook firmware 4.0.42 installeert. Die twee versienummers zijn aan elkaar gebonden om het euvel van high retries op te lossen. Ik zou me er niet teveel zorgen over maken zolang je verbinding stabiel is .

[edit] heb je Auto-Optimize Network of High Performance Devices on 5G aan staan? Op de ubnt community wordt doorgaans geadviseerd dit uit te schakelen (feature nog niet productierijp).

Daarnaast kun je via SSH op je access point middels ifconfig ook zelf eventuele hoge retries inzichtelijk maken. Als je een excessief hoge waarde bij RX/TX dropped packets ziet, dan wijst dat in veel gevallen op daadwerkelijke retries en packet loss. Maar je zult in jouw setup zien dat dat reuze meevalt .

Wil je daarmee zeggen dat als we terug downgraden naar 4.0.21, we ook de controller ook moeten downgraden naar 5.10.24?
Bij mij bleven de retry rates echt op 99 of 100% na de downgrade van de firmware, maar aan de verbinding was er eigenlijk niks te merken.

EDIT: Volgens dit draadje moet je controller downgraden naar 5.10.23 als je terug naar 4.0.21 wilt op de AP's om het correcte grafiekje te zien. Ofwel de controller op .25 laten en je niks aantrekken van de verkeerde retry rates, want het is enkel de visualisatie die niet goed gaat.
https://community.ui.com/...73-465c-845e-c7782583522f

[ Voor 12% gewijzigd door Broodro0ster op 17-07-2019 10:43 ]

[The Eagle]

Zo heb ik zijn post wel geinterpreteerd iig. En dat ga ik niet doen, los van het feit of dat niet gewoon een reinstall is of niet. Die nieuwste versie had zoals gezegd ook een andere java versie nodig bij mij, geen zin om ook al de dependencies op linux niveau weer aan te passen. Dr draait nog meer op die pi

---

Overigens heb ik nog steeds de vraag of ik ergens de firmwarehistory van de devices kan zien (ie wanneer stond ie op welke firmware en heb ik geupgrade / downgrade)

[ Voor 22% gewijzigd door The Eagle op 17-07-2019 11:15 ]

[Broodro0ster]

The Eagle schreef op woensdag 17 juli 2019 @ 11:12:
Zo heb ik zijn post wel geinterpreteerd iig. En dat ga ik niet doen, los van het feit of dat niet gewoon een reinstall is of niet. Die nieuwste versie had zoals gezegd ook een andere java versie nodig bij mij, geen zin om ook al de dependencies op linux niveau weer aan te passen. Dr draait nog meer op die pi

In dat geval snap ik het. Ik draai mijn controller als Docker container en ik hou altijd een backup bij voor ik een upgrade doe. Zo kan ik makkelijk terug in het geval dat het nodig is.

[Yoshimi]

Broodro0ster schreef op woensdag 17 juli 2019 @ 10:38:
EDIT: Volgens dit draadje moet je controller downgraden naar 5.10.23 als je terug naar 4.0.21 wilt op de AP's om het correcte grafiekje te zien. Ofwel de controller op .25 laten en je niks aantrekken van de verkeerde retry rates, want het is enkel de visualisatie die niet goed gaat.
https://community.ui.com/...73-465c-845e-c7782583522f

Precies dat! Mijn antwoord was achteraf gezien niet heel duidelijk omschreven (was te snel ).
Ik draai gewoon de laatste stable controller, maar kijk niet meer naar die retry rates. Bij een toekomstige stable firmware hoger dan 4.0.21 zal dat dan sowieso vanzelf opgelost zijn.

The Eagle schreef op woensdag 17 juli 2019 @ 11:12:
Overigens heb ik nog steeds de vraag of ik ergens de firmwarehistory van de devices kan zien (ie wanneer stond ie op welke firmware en heb ik geupgrade / downgrade)

In "Events" in het linker menu kun je wel zien wanneer veranderingen in firmware versies toegepast zijn, op welke devices en welke versie dat betrof. Afhankelijk van je retentie die je ingesteld hebt, kun je historische data raadplegen. Wellicht als je syslog kan forwarden, dat je deze events ook voor langere duur kunt opslaan. Heb ik zelf nog niet geprobeerd .

[Vliegvlug]

Ik heb vandaag mijn Ubiquiti EdgeRouter 4 binnen gekregen.

Doel is hier een OpenVPN server op te draaien die ik middels port-forwarding vanuit internet moet kunnen benaderen.

Heb verder nog geen ervaring met Ubiquiti apparatuur, wel met Cisco en Juniper overigens, en heb tot nu toe twee vraagjes.

1. Er stond firmware versie 1.10.7 op en kwam er achter dat er twee versies zijn op de ui.com website; v1.10.9 en v2.0.6. Welke kan ik het beste nemen?
   (ik heb voor nu de v1 erop gezet omdat ik niet weet of ik nog makkelijk kan downgraden van de v2 en omdat ik sommig commentaar las dat die versie 2 nog redelijk beta overkwam.)
2. Ik volg de handleiding EdgeRouter - OpenVPN server op ubnt.com en bij het commando om de Diffie-Hellman key file te maken krijg ik wel de melding “This is going to take a long time”. Maar hoe lang is lang?
   Ik heb 4096 als key size gebruikt en wacht nu al meer dan een uur en zit te kijken naar regels vol met puntjes en soms een +. Wat geeft die + eigenlijk aan?

[nero355]

Vliegvlug schreef op woensdag 17 juli 2019 @ 20:32:

1. Er stond firmware versie 1.10.7 op en kwam er achter dat er twee versies zijn op de ui.com website; v1.10.9 en v2.0.6. Welke kan ik het beste nemen?
   (ik heb voor nu de v1 erop gezet omdat ik niet weet of ik nog makkelijk kan downgraden van de v2 en omdat ik sommig commentaar las dat die versie 2 nog redelijk beta overkwam.)
2. Ik volg de handleiding EdgeRouter - OpenVPN server op ubnt.com en bij het commando om de Diffie-Hellman key file te maken krijg ik wel de melding “This is going to take a long time”. Maar hoe lang is lang?
   Ik heb 4096 als key size gebruikt en wacht nu al meer dan een uur en zit te kijken naar regels vol met puntjes en soms een +. Wat geeft die + eigenlijk aan?

- Ik zou bij Versie 1.x.x blijven op basis van de ervaringen van anderen in dit topic!
- Je router is nu met zijn kleine slome SoC iets aan het doen wat makkelijk de volgende dag pas klaar zou kunnen zijn : Mijn Raspberry Pi 3B was er 3 dagen mee bezig in een screen sessie

Wat ook misschien handig is om te weten : Smartphones hebben liever dat je maximaal 2048 i.p.v. 4096 gebruikt, maar misschien is wat dat betreft het een en ander ondertussen veranderd!

Gevalletje "Now we wait!" dus...

The Eagle schreef op woensdag 17 juli 2019 @ 11:12:
Zo heb ik zijn post wel geinterpreteerd iig. En dat ga ik niet doen, los van het feit of dat niet gewoon een reinstall is of niet. Die nieuwste versie had zoals gezegd ook een andere java versie nodig bij mij, geen zin om ook al de dependencies op linux niveau weer aan te passen. Dr draait nog meer op die pi

Als je eenmaal op de officiële Oracle versie zit dan komt het wel goed!

En anders zou je eens met Docker kunnen experimenteren...

Overigens heb ik nog steeds de vraag of ik ergens de firmwarehistory van de devices kan zien (ie wanneer stond ie op welke firmware en heb ik geupgrade / downgrade)

Helaas niet... Veel te handig! En daar doet Ubiquiti niet aan bij produkten die zogenaamd Enterprise grade zouden moeten zijn


En nog effe over het DTIM op 3 zetten verhaal : Ik doe niet anders de afgelopen 7 maanden ongeveer en dat werkt gewoon prima!

Toen ik nog de oude UAP's had stond die setting ook altijd zo een jaar of 2 a 3 lang geloof ik
De Default setting is 1 en dat schijnt een soort Legacy Hardware Compatible setting te zijn...

[Vliegvlug]

nero355 schreef op woensdag 17 juli 2019 @ 22:20:
[...]

- Ik zou bij Versie 1.x.x blijven op basis van de ervaringen van anderen in dit topic!
- Je router is nu met zijn kleine slome SoC iets aan het doen wat makkelijk de volgende dag pas klaar zou kunnen zijn : Mijn Raspberry Pi 3B was er 3 dagen mee bezig in een screen sessie

Dan houdt ik het gewoon op v1.

mijn ssh sessie is eruit geklapt en ik zie niets in /config/auth staan dus dat wachten was voor niets.

Had ook geen screen gebruikt of zoiets.
Doe dit soort dingen nog het liefst via de console poort maar kan mijn usb-com dongle helaas nergens vinden.

Wat ook misschien handig is om te weten : Smartphones hebben liever dat je maximaal 2048 i.p.v. 4096 gebruikt, maar misschien is wat dat betreft het een en ander ondertussen veranderd!

[...]

Dank voor de tip, niet bij stil gestaan, dacht simpelweg ‘hoger is veiliger’, maar dan pakken we 2048 wel. Is ook minder lang wachten.

[To_Tall]

Mijn ervaaring is dat het zomaar kan afhangen van je device, ene keer ben ik met 30 min klaar andere keer staat de machine een dag te stampen om een 2048 bit key te genereren.

[borft]

Vliegvlug schreef op woensdag 17 juli 2019 @ 20:32:
Ik heb vandaag mijn Ubiquiti EdgeRouter 4 binnen gekregen.

Doel is hier een OpenVPN server op te draaien die ik middels port-forwarding vanuit internet moet kunnen benaderen.

Waarom een port forward op een router? Hangt ie niet gewoon direct aan Internet? Keys genereren zou ik op je laptop doen en dan copieren, dat gaat ongeveer 100000000x sneller

[burne]

borft schreef op donderdag 18 juli 2019 @ 10:22:
[...]


Waarom een port forward op een router? Hangt ie niet gewoon direct aan Internet? Keys genereren zou ik op je laptop doen en dan copieren, dat gaat ongeveer 100000000x sneller

Voor een Diffie Hellman-key maakt de lengte niet heel veel uit. Een 1024 bits key valt nog binnen de mogelijkheden van een Logjam-attack, maar het kost je ongeveer 100 miljoen dollar aan rekentijd. Voor een veelgebruikte standaard key die je met apparaten meelevert is dat voor iets als de NSA misschien nog te overwegen, maar als jij een eigen 1024 bits key genereert gaat iemand echt niet 100 miljoen uitgeven om mee te kunnen kijken met jouw vakantiefotos.

[posttoast]

Iemand ervaring met een Ring Floodlight Camera in combinatie met Unifi? Ik heb, na goede ervaringen bij mij thuis en op mijn kantoor, bij een familielid ook een Unifi netwerk aangelegd; 3 AC AP Lite's, een USG en een Cloud Key. Werkt allemaal prima, op één ding na: zijn Ring Floodlight Camera wil gewoon niet verbinden met het wifi netwerk.

Ik ben gaan Googlen en kwam meerdere posts tegen over dit probleem, bijvoorbeeld dit verhaal op Reddit. Conclusie: auto optimize network moet uitgezet worden. Heb ik gedaan, maar... geen succes.

Na verder graven kwam ik erachter dat de Ring Floodlight Camera geen 5ghz netwerken ondersteunt. Je zou verwachten dat dit geen issue zou moeten zijn (ik heb thuis ook wat domotica die enkel op 2.4ghz werkt, en die verbinden dan ook gewoon goed), maar blijkbaar is dat niet altijd het geval. De aangedragen oplossing: een extra SSID aanmaken en dan per accesspoint instellen dat op deze SSID enkel de 2.4ghz radio werkt. Dat is gelukt (heb het getest met een iPad), maar: de camera wil nog steeds niet verbinden.

De camera verbindt prima met een hotspot vanaf de telefoon. En buiten (waar de camera hangt) is er genoeg bereik. Er is dus echt iets anders aan de hand, maar wat? Mijn ideeën beginnen een beetje op te raken

[Anoniem: 1063705]

Quad schreef op donderdag 11 juli 2019 @ 19:57:
Vandaag een UniFi AC In-Wall gemonteerd bij m'n ouders. De UAP Pro had z'n beste tijd gehad, en na de verhuizing kon hij 't huis niet voldoende dekking geven.

Beneden hadden m'n ouders 2x 2 outlets en elektra liggen, welke nu toch niet benut werd.
Dus de meest linker outlet opgeofferd, afdekraam iets aangepast zodat boutjes door 't montageplaat op het afdekraam rechtstreeks de inbouwdoos in kon. M3 boutje, 40mm lengte (30mm had ook net gekund denk ik).

Resultaat is dikke prima!

[Afbeelding]

De AC In-Wall werkt ook erg goed.

Zou je een foto van het frame kunnen nemen, maar één probleem met me hebben, het past gewoon niet in een rij stopcontacten, bedankt

[Broodro0ster]

posttoast schreef op donderdag 18 juli 2019 @ 11:21:
Iemand ervaring met een Ring Floodlight Camera in combinatie met Unifi? Ik heb, na goede ervaringen bij mij thuis en op mijn kantoor, bij een familielid ook een Unifi netwerk aangelegd; 3 AC AP Lite's, een USG en een Cloud Key. Werkt allemaal prima, op één ding na: zijn Ring Floodlight Camera wil gewoon niet verbinden met het wifi netwerk.

Ik ben gaan Googlen en kwam meerdere posts tegen over dit probleem, bijvoorbeeld dit verhaal op Reddit. Conclusie: auto optimize network moet uitgezet worden. Heb ik gedaan, maar... geen succes.

Na verder graven kwam ik erachter dat de Ring Floodlight Camera geen 5ghz netwerken ondersteunt. Je zou verwachten dat dit geen issue zou moeten zijn (ik heb thuis ook wat domotica die enkel op 2.4ghz werkt, en die verbinden dan ook gewoon goed), maar blijkbaar is dat niet altijd het geval. De aangedragen oplossing: een extra SSID aanmaken en dan per accesspoint instellen dat op deze SSID enkel de 2.4ghz radio werkt. Dat is gelukt (heb het getest met een iPad), maar: de camera wil nog steeds niet verbinden.

De camera verbindt prima met een hotspot vanaf de telefoon. En buiten (waar de camera hangt) is er genoeg bereik. Er is dus echt iets anders aan de hand, maar wat? Mijn ideeën beginnen een beetje op te raken

Welke firmware draai je? Ik heb ook enkele issues met bepaalde apparaten en 4.0.42.
4.0.21 was stabiel dus ben ik terug gedowngrade. Downgraden is best makkelijk mocht je het willen proberen.

[robertwebbe]

posttoast schreef op donderdag 18 juli 2019 @ 11:21:
[...]
Er is dus echt iets anders aan de hand, maar wat? Mijn ideeën beginnen een beetje op te raken

Heb je al eens gespeeld met de channel with (HT20 of HT40), Security (WEP, WPA), WPA modes (WPA1/WPA2 en AES/Auto) en mogelijk een andere security key, eentje zonder bijzonder tekens?

[posttoast]

Broodro0ster schreef op donderdag 18 juli 2019 @ 12:17:
[...]


Welke firmware draai je? Ik heb ook enkele issues met bepaalde apparaten en 4.0.42.
4.0.21 was stabiel dus ben ik terug gedowngrade. Downgraden is best makkelijk mocht je het willen proberen.

Het is de nieuwste firmware, heb van het weekend daar alles opgehangen en direct geupdate. Downgraden is misschien wel een optie ja.

robertwebbe schreef op donderdag 18 juli 2019 @ 12:20:
[...]

Heb je al eens gespeeld met de channel with (HT20 of HT40), Security (WEP, WPA), WPA modes (WPA1/WPA2 en AES/Auto) en mogelijk een andere security key, eentje zonder bijzonder tekens?

Channel heb ik al mee gespeeld, dat mocht niet baten. WPA modes kan ik nog wel even naar kijken inderdaad. security key is vrij eenvoudig, het "gekste" wat daar in zit is één hoofdletter.

Tnx voor het meedenken alvast. Mocht er nog iemand zijn die hier zelf ook ervaring mee heeft dan hoor ik dat uiteraard graag

[The Eagle]

Gistern ook nog wat leuks. had dus die DTIM aangepast naar 3, dacht weet je wat, ik doe even een RF scan op alledrie mijn AP's, dan weten ze ook weer wat ze wel en niet kunnen doen. Gevolg: Heel 5ghz down omdat ze alledrie bedacht hadden een DFS kanaal te pakken en er een DFS waiting optrad. Dat zou na 10 minuten opgelost moeten zijn (of na een restart), maar het waren toch echt een paar restarts voordat ze weer gewoon op een normaal 5Ghz kanaal zaten

[nero355]

The Eagle schreef op donderdag 18 juli 2019 @ 13:38:
Gistern ook nog wat leuks. had dus die DTIM aangepast naar 3, dacht weet je wat, ik doe even een RF scan op alledrie mijn AP's, dan weten ze ook weer wat ze wel en niet kunnen doen. Gevolg: Heel 5ghz down omdat ze alledrie bedacht hadden een DFS kanaal te pakken en er een DFS waiting optrad. Dat zou na 10 minuten opgelost moeten zijn (of na een restart), maar het waren toch echt een paar restarts voordat ze weer gewoon op een normaal 5Ghz kanaal zaten

Dat stel je toch zelf handmatig in
En je had nog steeds 2.4 GHz ontvangst neem ik aan ?!

Hier totaal geen problemen mee gelukkig, ondanks dat er twee accesspoints op DFS kanalen zitten

EDIT :

posttoast schreef op donderdag 18 juli 2019 @ 15:02:
[...]


Ik heb zojuist de firmware gedowngrade naar de 21 versie. No dice. Ik heb alle mogelijke security configs geprobeerd, zelfs zónder wachtwoord. Werkte niet. Channels aangepast. Werkte ook niet. Bij elke poging de Ring Floodlight Cam een volledige factory reset gegeven, dus dat kan het ook niet zijn.

Inmiddels begin ik wel wat wanhopig te worden...

Misschien wordt het dan tijd om een bug te submitten bij Ubiquiti en dat merk tegelijk!

[ Voor 27% gewijzigd door nero355 op 18-07-2019 15:19 ]

[posttoast]

posttoast schreef op donderdag 18 juli 2019 @ 12:48:
[...]

Het is de nieuwste firmware, heb van het weekend daar alles opgehangen en direct geupdate. Downgraden is misschien wel een optie ja.


[...]

Channel heb ik al mee gespeeld, dat mocht niet baten. WPA modes kan ik nog wel even naar kijken inderdaad. security key is vrij eenvoudig, het "gekste" wat daar in zit is één hoofdletter.

Tnx voor het meedenken alvast. Mocht er nog iemand zijn die hier zelf ook ervaring mee heeft dan hoor ik dat uiteraard graag

Ik heb zojuist de firmware gedowngrade naar de 21 versie. No dice. Ik heb alle mogelijke security configs geprobeerd, zelfs zónder wachtwoord. Werkte niet. Channels aangepast. Werkte ook niet. Bij elke poging de Ring Floodlight Cam een volledige factory reset gegeven, dus dat kan het ook niet zijn.

Inmiddels begin ik wel wat wanhopig te worden...

[JeeEs]

posttoast schreef op donderdag 18 juli 2019 @ 15:02:
[...]


Ik heb zojuist de firmware gedowngrade naar de 21 versie. No dice. Ik heb alle mogelijke security configs geprobeerd, zelfs zónder wachtwoord. Werkte niet. Channels aangepast. Werkte ook niet. Bij elke poging de Ring Floodlight Cam een volledige factory reset gegeven, dus dat kan het ook niet zijn.

Inmiddels begin ik wel wat wanhopig te worden...

Ik heb een keer hetzelfde issue gehad met een Honeywell Econome thermostaat. Bleek dat als je de setting "Block LAN to WAN Multicast and Broadcast data" uitvinkte, het wel weer werkte...

Zie: https://community.ui.com/...0b-4faa-9fb9-43f049a61efc

[m3gA]

posttoast schreef op donderdag 18 juli 2019 @ 11:21:
Iemand ervaring met een Ring Floodlight Camera in combinatie met Unifi? Ik heb, na goede ervaringen bij mij thuis en op mijn kantoor, bij een familielid ook een Unifi netwerk aangelegd; 3 AC AP Lite's, een USG en een Cloud Key. Werkt allemaal prima, op één ding na: zijn Ring Floodlight Camera wil gewoon niet verbinden met het wifi netwerk.

Ik ben gaan Googlen en kwam meerdere posts tegen over dit probleem, bijvoorbeeld dit verhaal op Reddit. Conclusie: auto optimize network moet uitgezet worden. Heb ik gedaan, maar... geen succes.

Na verder graven kwam ik erachter dat de Ring Floodlight Camera geen 5ghz netwerken ondersteunt. Je zou verwachten dat dit geen issue zou moeten zijn (ik heb thuis ook wat domotica die enkel op 2.4ghz werkt, en die verbinden dan ook gewoon goed), maar blijkbaar is dat niet altijd het geval. De aangedragen oplossing: een extra SSID aanmaken en dan per accesspoint instellen dat op deze SSID enkel de 2.4ghz radio werkt. Dat is gelukt (heb het getest met een iPad), maar: de camera wil nog steeds niet verbinden.

De camera verbindt prima met een hotspot vanaf de telefoon. En buiten (waar de camera hangt) is er genoeg bereik. Er is dus echt iets anders aan de hand, maar wat? Mijn ideeën beginnen een beetje op te raken

Heb je auto optimize network aanstaan onder Site? Zet deze dan eens uit. Weet dat sommige ring producten onterecht melden dat ze 5Ghz ondersteunen en de Access Points zullen dan proberen deze naar de 5Ghz te pushen.

[Sjalabert]

m3gA schreef op donderdag 18 juli 2019 @ 15:48:
[...]

Heb je auto optimize network aanstaan onder Site? Zet deze dan eens uit. Weet dat sommige ring producten onterecht melden dat ze 5Ghz ondersteunen en de Access Points zullen dan proberen deze naar de 5Ghz te pushen.

100% correct. Ik heb auto optimize moeten uitschakelen voordat je daar achter komt.

[lier]

Laatste firmware versie (Release Candidate) is 4.0.49. Zou je je config eens willen posten, @posttoast?

[m3gA]

Sjalabert schreef op donderdag 18 juli 2019 @ 16:16:
[...]

100% correct. Ik heb auto optimize moeten uitschakelen voordat je daar achter komt.

Ik weet dat ze een blacklist bijhouden met devices maar geen idee hoe je daar iets op moet melden. Had toevallig deze week hetzelfde probleem met een firetv stick.

[posttoast]

JeeEs schreef op donderdag 18 juli 2019 @ 15:37:
[...]


Ik heb een keer hetzelfde issue gehad met een Honeywell Econome thermostaat. Bleek dat als je de setting "Block LAN to WAN Multicast and Broadcast data" uitvinkte, het wel weer werkte...

Zie: https://community.ui.com/...0b-4faa-9fb9-43f049a61efc

Die heb ik al zowel aan als uit gehad, maar het werkte helaas beiden niet.

m3gA schreef op donderdag 18 juli 2019 @ 15:48:
[...]

Heb je auto optimize network aanstaan onder Site? Zet deze dan eens uit. Weet dat sommige ring producten onterecht melden dat ze 5Ghz ondersteunen en de Access Points zullen dan proberen deze naar de 5Ghz te pushen.

Die heb ik al uitgezet, die kwam ik tegen op de Reddit post die ik hierboven zette. Dat was een moment van euforie toen ik het vond, maar helaas was het niet zo simpel en hielp het niet...

lier schreef op donderdag 18 juli 2019 @ 16:25:
Laatste firmware versie (Release Candidate) is 4.0.49. Zou je je config eens willen posten, @posttoast?

Ga ik doen, even uitzoeken hoe. Geef me een momentje

Nogmaals bedankt voor het meedenken allemaal, waardeer ik enorm!

Edit @lier doel je op een json bestand? Die kan ik gewoon uit de webinterface van de controller trekken toch? Ik ben niet bij dat familielid thuis nu, dus ik heb geen SSH toegang tot devices op het moment.

[ Voor 6% gewijzigd door posttoast op 18-07-2019 17:46 ]

[Quad]

Anoniem: 1063705 schreef op donderdag 18 juli 2019 @ 11:22:
[...]


Zou je een foto van het frame kunnen nemen, maar één probleem met me hebben, het past gewoon niet in een rij stopcontacten, bedankt

Hoe bedoel je dit? Ik kan voorlopig de AP niet weer demonteren.

[Laagheim]

@posttoast Tsja dan zou je bijna beginnen te denken dat het aan de Ring ligt. Misschien zit de antenne niet lekker voor een verbinding met de ap's. Ik weet niet of je een ap makkelijk op een andere plek kan krijgen? Probeer anders of je nog steeds verbinding met de hotspot op de telefoon kan krijgen als je de telefoon op dezelfde locatie houd als je ap's. (ter info: ik gebruik zelf nog een ouwe foscam die steeds zijn verbinding verliest als ie geen directe line of sight heeft met de ap en ook met zwave clients antenne problemen gehad)

[The Eagle]

nero355 schreef op donderdag 18 juli 2019 @ 15:01:
[...]

Dat stel je toch zelf handmatig in
En je had nog steeds 2.4 GHz ontvangst neem ik aan ?!

Hier totaal geen problemen mee gelukkig, ondanks dat er twee accesspoints op DFS kanalen zitten

EDIT :

[...]

Misschien wordt het dan tijd om een bug te submitten bij Ubiquiti en dat merk tegelijk!

Kanaal voor de 5Ghz staat op auto, dus die pakt DFS als ie kan. Of ie dat mag en hoe lang is afhankelijk van de landinstellingen heb ik me laten vertellen. Sec DFS kanalen uitsluiten kan niet, alleen handmatig een vast kanaal instellen. En dat wil ik niet
Had idd nog wel 2,4Ghz ontvangst, maar das bewust een ander SSID. Had geen zin in handover perikelen en heb welgeteld twee devices in huis die geen 5ghz ondersteunen, en die staan nauwelijks aan.
Hoe het gekomen is weet ik ook niet. Dr is gisteravond een luchballon geland, maar dat was volgens mij eerder. Zit wel pal tussen Gilze Rijen en Volkel in, hebben hier regelmatig apaches en andere militaire helis vliegen, plus vrij vaak een traumaheli. Dus op DFS vertrouwen wil ik niet. Maar dat ie vast bleef hangen had ik ook niet verwacht, eerder dat ie terug zou schakelen.

[posttoast]

Laagheim schreef op donderdag 18 juli 2019 @ 19:10:
@posttoast Tsja dan zou je bijna beginnen te denken dat het aan de Ring ligt. Misschien zit de antenne niet lekker voor een verbinding met de ap's. Ik weet niet of je een ap makkelijk op een andere plek kan krijgen? Probeer anders of je nog steeds verbinding met de hotspot op de telefoon kan krijgen als je de telefoon op dezelfde locatie houd als je ap's. (ter info: ik gebruik zelf nog een ouwe foscam die steeds zijn verbinding verliest als ie geen directe line of sight heeft met de ap en ook met zwave clients antenne problemen gehad)

Mijn oom (de eigenaar van die camera en het netwerk) heeft inmiddels wéér contact gehad met Ring, en ze gaan hem nu een nieuwe camera sturen. Tijdens het bellen met de helpdesk lukte het hem ook niet meer om de camera met zijn telefoon hotspot te verbinden. De Ring medewerker gaf aan dat de camera waarschijnlijk "dermate vaak een factory reset heeft gehad, dat hij het nu helemaal niet meer doet". Nu is mijn oom bepaald geen tweaker, dus de ridiculiteit van die opmerking had hij zelf niet zo in de gaten Ik heb er eerlijk gezegd een hard hoofd in dat dat het oplost, maar ik heb in ieder geval aan hem gevraagd of hij de camera los wil halen en aan mij mee wil geven. Dan kan ik hem hier in huis (ook met Unifi) testen en weer wat zaken uitsluiten.

Mocht iemand nog een gouden tip hebben, dan hoor ik dat uiteraard graag.

[nero355]

The Eagle schreef op donderdag 18 juli 2019 @ 20:10:
Kanaal voor de 5Ghz staat op auto, dus die pakt DFS als ie kan. Of ie dat mag en hoe lang is afhankelijk van de landinstellingen heb ik me laten vertellen. Sec DFS kanalen uitsluiten kan niet, alleen handmatig een vast kanaal instellen. En dat wil ik niet

Dan maar geen werkende WiFi hé!

Had idd nog wel 2,4Ghz ontvangst, maar das bewust een ander SSID. Had geen zin in handover perikelen en heb welgeteld twee devices in huis die geen 5ghz ondersteunen, en die staan nauwelijks aan.

2.4 GHz Low en 5 GHz High werkt hier prima!

Hoe het gekomen is weet ik ook niet. Dr is gisteravond een luchballon geland, maar dat was volgens mij eerder. Zit wel pal tussen Gilze Rijen en Volkel in, hebben hier regelmatig apaches en andere militaire helis vliegen, plus vrij vaak een traumaheli. Dus op DFS vertrouwen wil ik niet. Maar dat ie vast bleef hangen had ik ook niet verwacht, eerder dat ie terug zou schakelen.

Hier vliegen ook regelmatig vliegtuigen en helikopters over het huis heen of in de buurt, maar ik krijg bijna geen DFS Warnings en zie toevallig deze twee staan op het moment :

code:

detected radar on channel 100 (5500 MHz) 7:53 am 05/24/2019
detected radar on channel 52 (5260 MHz) 5:17 pm 04/28/2019

Normaal gesproken zijn het er nog minder en de huidige uptime is 93 dagen zonder ook maar één keer de UAP IW's te hebben reboot

[burne]

nero355 schreef op donderdag 18 juli 2019 @ 20:38:
[...]

Hier vliegen ook regelmatig vliegtuigen en helikopters over het huis heen of in de buurt, maar ik krijg bijna geen DFS Warnings en zie toevallig deze twee staan op het moment :

code:

detected radar on channel 100 (5500 MHz) 7:53 am 05/24/2019
detected radar on channel 52 (5260 MHz) 5:17 pm 04/28/2019

Als je iets ziet is het doppler weerradar. Weerradar aan boord van vliegtuigen is X-band, 8-12GHz. In Nederland staan er doppler weerradar-stations in Herwijnen en Den Helder.

[BushWhacker]

Vliegvlug schreef op woensdag 17 juli 2019 @ 20:32:
Ik heb vandaag mijn Ubiquiti EdgeRouter 4 binnen gekregen.

Doel is hier een OpenVPN server op te draaien die ik middels port-forwarding vanuit internet moet kunnen benaderen.

Heb verder nog geen ervaring met Ubiquiti apparatuur, wel met Cisco en Juniper overigens, en heb tot nu toe twee vraagjes.

1. Er stond firmware versie 1.10.7 op en kwam er achter dat er twee versies zijn op de ui.com website; v1.10.9 en v2.0.6. Welke kan ik het beste nemen?
   (ik heb voor nu de v1 erop gezet omdat ik niet weet of ik nog makkelijk kan downgraden van de v2 en omdat ik sommig commentaar las dat die versie 2 nog redelijk beta overkwam.)
2. Ik volg de handleiding EdgeRouter - OpenVPN server op ubnt.com en bij het commando om de Diffie-Hellman key file te maken krijg ik wel de melding “This is going to take a long time”. Maar hoe lang is lang?
   Ik heb 4096 als key size gebruikt en wacht nu al meer dan een uur en zit te kijken naar regels vol met puntjes en soms een +. Wat geeft die + eigenlijk aan?

Ik heb al meer dan een jaar een ER4, met daarin een SFP die direct aan de glasvezel hangt (Xs4all FTTH).
Hij bevalt erg goed.

Ik heb de laatste firmware (v2.0.3) erop staan en heb er geen probleem mee.
De uptime is nu meer dan 10 weken. Ook de PPPoE verbinding is niet een keer onderbroken in die tijd.
Dus stabiel is hij in mijn situatie iig wel.

OpenVPN draai ik op de ER4. Werkt stabiel en snel genoeg. Ik haal iig iets van 50Mbps.
Alle keys/certificaten heb ik op mijn Linux PC aangemaakt. Daar is het een eitje.
Op de ER4 die dingen aanmaken is erg omslachtig en traag.

Je moet aanmaken:
- CA
- Server Certificate
- DH Key
- Extra SSL key (optioneel)
- Client certificaat voor elk device dat gaat connecten.

[The Eagle]

Ah, dat verklaart. Herwijnen is hier met de auto 27km vandaan, en das een haakse hoek. Hemelsbreed ca 20 km. Daar Wikipedia: Herwijnen blijken twee torens te staan waarvan de ene weerradar is en de andere van defensie voor luchtverkeersleiding. Just my luck.
Naja, zolang ie er niet in blijft vind ik het best.

[familyman]

Hmmm voor het eerst in een tijd weer eens gekeken in mijn router en cloudkey. Speedtest bij KPN laat snelheid van 100mb/s zien. Heb echter een 500mb abonnement

de config is xbeam, voor iptv en internet alleen. Op zich wel lage ping en jitter.

Het betreft hier een 3p.

Zijn er dingen die ik zou moeten bekijken?

[Step]

familyman schreef op vrijdag 19 juli 2019 @ 08:00:
Hmmm voor het eerst in een tijd weer eens gekeken in mijn router en cloudkey. Speedtest bij KPN laat snelheid van 100mb/s zien. Heb echter een 500mb abonnement

de config is xbeam, voor iptv en internet alleen. Op zich wel lage ping en jitter.

Het betreft hier een 3p.

Zijn er dingen die ik zou moeten bekijken?

IPS/IDS uit? Dit kon je natuurlijk even opzoeken. Het internet staat er vol mee.

[familyman]

Step schreef op vrijdag 19 juli 2019 @ 08:27:
[...]


IPS/IDS uit? Dit kon je natuurlijk even opzoeken. Het internet staat er vol mee.

Het internet staat barstensvol. Gelukkig ook met veel te oude informatie. Was er al druk mee omdat mijn cloudkey corrupted was geraakt. Dat is inmiddels bijgesteld.

IPS/IDS staan uit.

Zit nu te dubben om de iptv eraf te gooien, en via canal digital te kijken, zodat de routing nog simpeler wordt. Werd op voorhand alleen _iets_ minder gelukkig van de beeldkwaliteit....

[RUFFNECK]

familyman schreef op vrijdag 19 juli 2019 @ 08:00:
Hmmm voor het eerst in een tijd weer eens gekeken in mijn router en cloudkey. Speedtest bij KPN laat snelheid van 100mb/s zien. Heb echter een 500mb abonnement

de config is xbeam, voor iptv en internet alleen. Op zich wel lage ping en jitter.

Het betreft hier een 3p.

Zijn er dingen die ik zou moeten bekijken?

Hoe doe je de speedtest? Op je laptop draadloos? Via de Unifi/controller dashboard? bekabeld aan de switch? De meting via je controller dashboard zelf, klopt niet, daar is ook idd genoeg over te vinden. In het begin had ik ook hetzelfde, maar speedtests die ik initiate vanuit m'n bedrade ubuntu server, geven netjes 500mb snelheden aan

[familyman]

RUFFNECK schreef op vrijdag 19 juli 2019 @ 09:05:
[...]

Hoe doe je de speedtest? Op je laptop draadloos? Via de Unifi/controller dashboard? bekabeld aan de switch? De meting via je controller dashboard zelf, klopt niet, daar is ook idd genoeg over te vinden. In het begin had ik ook hetzelfde, maar speedtests die ik initiate vanuit m'n bedrade ubuntu server, geven netjes 500mb snelheden aan

Speedtest via xbox levert 521 down en 873 up, schijnbaar heb ik geen issues dus - sorry guys.

[JB]

Geen idee of ik de vraag hier kan stellen maar ik heb een "UHD" tv UE40NU7110 op de slaapkamer sinds kort en deze is elke ochtend zijn Wifi verbinding kwijt. Apps starten dan niet op omdat de tv vind dat ie geen verbinding met internet heeft. Inmiddels een nieuwe firmware eroverheen kunnen zetten maar biedt geen soelaas. Enige wat helpt is, de tv van de stroom (of de powerknop lang indrukken) zodat ie "herstart".

Nu heb ik nog een Samsung tv UE40MU6100 in de keuken hangen met (volgens mij) hetzelfde platform draaiend maar deze is nooit zijn WiFi verbinding kwijt.

Alles zit op Ubiquiti APs (2x AC-LR). Heb verder met geen enkel ander apparaat op WiFi problemen. Zodra ik verbinding heb, werkt het ook zonder enkel probleem maar het uit standby komen gaat gewoon elke ochtend mis.

Iemand die dit herkent Vrij vervelend

Enige wat ik me kan bedenken is, dat ik ooit heb ingesteld dat de AP op de bovenverdieping vanaf 23:00 uur tot 7:00 uur uit gaat alleen kan ik nergens vinden waar ik dat ingesteld heb, want dit zou ik dan eens tijdelijk uit willen zetten als test. Dit heb ik in ieder geval niet met een losse WLAN group gedaan, maar volgens mij ergens direct op de AP, alleen vind ik die setting nergens terug. Zou dit de boosdoener kunnen zijn? Toch ook vreemd want vaak genoeg, dat we al voor 23 uur de tv aan hebben staan met Netflix en rond 23 uur heb ik ook geen issues als de AP "uit" gaat want de AP beneden voorziet dan van voldoende dekking.

Wat me verder opvalt is door het uitgaan van transmitten, is dat bepaalde clients ook gewoon op de AP beneden blijven zitten, de dag erop als de AP weer in de lucht is. Een webcam zit lekkerlijk op 1m afstand en blijft toch op de AP beneden. Schakelt het spul niet automatisch naar de AP die dichterbij cq. sterker signaal geeft? Ik gebruik de AC inrichting dus een gecombineerde 2.4/5GHz, ik krijg niet gevonden op de site van Samsung of deze tv ook 5GHz doet. Signaalsterkte heb ik mee gespeeld maar biedt geen soelaas. Staat op AUTO.

[ Voor 5% gewijzigd door JB op 19-07-2019 11:48 ]

[MisteRMeesteR]

familyman schreef op vrijdag 19 juli 2019 @ 08:00:
Hmmm voor het eerst in een tijd weer eens gekeken in mijn router en cloudkey. Speedtest bij KPN laat snelheid van 100mb/s zien. Heb echter een 500mb abonnement

de config is xbeam, voor iptv en internet alleen. Op zich wel lage ping en jitter.

Het betreft hier een 3p.

Zijn er dingen die ik zou moeten bekijken?

familyman schreef op vrijdag 19 juli 2019 @ 09:22:
[...]


Speedtest via xbox levert 521 down en 873 up, schijnbaar heb ik geen issues dus - sorry guys.

Even je netwerkbekabeling / switches controleren. Lijkt alsof er een poort op 100mbps draait

[The Eagle]

JB schreef op vrijdag 19 juli 2019 @ 09:41:
Geen idee of ik de vraag hier kan stellen maar ik heb een "UHD" tv UE40NU7110 op de slaapkamer sinds kort en deze is elke ochtend zijn Wifi verbinding kwijt. Apps starten dan niet op omdat de tv vind dat ie geen verbinding met internet heeft. Inmiddels een nieuwe firmware eroverheen kunnen zetten maar biedt geen soelaas. Enige wat helpt is, de tv van de stroom (of de powerknop lang indrukken) zodat ie "herstart".

Nu heb ik nog een Samsung tv UE40MU6100 in de keuken hangen met (volgens mij) hetzelfde platform draaiend maar deze is nooit zijn WiFi verbinding kwijt.

Alles zit op Ubiquiti APs (2x AC-LR). Heb verder met geen enkel ander apparaat op WiFi problemen. Zodra ik verbinding heb, werkt het ook zonder enkel probleem maar het uit standby komen gaat gewoon elke ochtend mis.

Iemand die dit herkent Vrij vervelend

Enige wat ik me kan bedenken is, dat ik ooit heb ingesteld dat de AP op de bovenverdieping vanaf 23:00 uur tot 7:00 uur uit gaat alleen kan ik nergens vinden waar ik dat ingesteld heb, want dit zou ik dan eens tijdelijk uit willen zetten als test. Dit heb ik in ieder geval niet met een losse WLAN group gedaan, maar volgens mij ergens direct op de AP, alleen vind ik die setting nergens terug. Zou dit de boosdoener kunnen zijn? Toch ook vreemd want vaak genoeg, dat we al voor 23 uur de tv aan hebben staan met Netflix en rond 23 uur heb ik ook geen issues als de AP "uit" gaat want de AP beneden voorziet dan van voldoende dekking.

Wat me verder opvalt is door het uitgaan van transmitten, is dat bepaalde clients ook gewoon op de AP beneden blijven zitten, de dag erop als de AP weer in de lucht is. Een webcam zit lekkerlijk op 1m afstand en blijft toch op de AP beneden. Schakelt het spul niet automatisch naar de AP die dichterbij cq. sterker signaal geeft?

Als het signaal sterk genoeg is hoeft dat roamen niet plaate te vinden natuurlijk.
Verder is het ook de vraag hoe de rest van je config er uit ziet. Heb je bijvoorbeeld een gedeeld SSID voor 2Ghz en 5Ghz of apart, en hoe sterk staan beide banden te zenden en heb je auto handover etc ingesteld? 5Ghz signaal is meestal niet zo sterk, daar zie je sneller dat ie gaat roamen.
En welke banden ondersteunen je TV's? Kan me zomaar voorstellen dat dat alleen een 2,4Ghz band is.

[Vliegvlug]

To_Tall schreef op donderdag 18 juli 2019 @ 00:25:
Mijn ervaaring is dat het zomaar kan afhangen van je device, ene keer ben ik met 30 min klaar andere keer staat de machine een dag te stampen om een 2048 bit key te genereren.

Het lijkt vrij willekeurig ja.
Heb een tweede poging gedaan een 2048 key te genereren die er na een half uur uitklapte vanwege ssh problemen en de volgende dag hetzelfde nog een keer gedaan en die was binnen het kwartier klaar.
Een vriend zei dat dit kon liggen aan de hoeveelheid entropie die het systeem heeft opgebouwd. Zou best kunnen aangezien ik de cpu belasting in de webinterface niet boven de 30% kwam dus het lijkt er niet op dat het ding zwaar staat te rekenen.

borft schreef op donderdag 18 juli 2019 @ 10:22:
[...]

Waarom een port forward op een router? Hangt ie niet gewoon direct aan Internet? Keys genereren zou ik op je laptop doen en dan copieren, dat gaat ongeveer 100000000x sneller

Zou misschien wel beter zijn maar heb nu geen zin om mijn provider modem in bridge modus te laten zetten en als port forward ook werkt is dat minder moeite.

BushWhacker schreef op donderdag 18 juli 2019 @ 21:16:
[...]

Ik heb al meer dan een jaar een ER4, met daarin een SFP die direct aan de glasvezel hangt (Xs4all FTTH).
Hij bevalt erg goed.

Ik heb de laatste firmware (v2.0.3) erop staan en heb er geen probleem mee.
De uptime is nu meer dan 10 weken. Ook de PPPoE verbinding is niet een keer onderbroken in die tijd.
Dus stabiel is hij in mijn situatie iig wel.

OpenVPN draai ik op de ER4. Werkt stabiel en snel genoeg. Ik haal iig iets van 50Mbps.
Alle keys/certificaten heb ik op mijn Linux PC aangemaakt. Daar is het een eitje.
Op de ER4 die dingen aanmaken is erg omslachtig en traag.

Je moet aanmaken:
- CA
- Server Certificate
- DH Key
- Extra SSL key (optioneel)
- Client certificaat voor elk device dat gaat connecten.

Goed te horen dat de v2 firmware ook stabiel is, dan kan ik tzt over als dat voordelen biedt.
En 50mbps voor OpenVPN is ook niet verkeerd, kwam meerdere cijfers tegen op internet maar deze waarde zit wel aan de bovenkant.
Altijd handig om wat marge te hebben aangezien mijn upload momenteel de 50 bij lange na niet haalt.

Certificaten aanmaken op een andere machine is wel een goed idee alleen is mijn enige andere linux bak een Raspberry Pi, dus dat schiet niet echt op.

[Will_M]

@JB & @The Eagle

Ik heb hier sinds een aantal weken ongeveer hetzelfde 'issue' sinds een OS update van m'n TV en ga dus even mee 'lezen'. Ik ben normaliter meer van 't zélf uitpluizen (Wireshark FTW) maar heb daar de laatste tijd géén tijd voor gehad en voorzie er ook geen mogelijkheid toe in de komende maanden.

wimmel_1 in "Philips TV's - 2015 en nieuwer"

Ik heb hier overigens een 4-tal NANO-HD's in huis hangen waarbij alle SSID's ook op beide banden gehost worden. TV kán ook AC aan en is ook hier de énige 'ellendeling' op m'n netwerk (en tevens het énige Android device in huis).

[ Voor 27% gewijzigd door Will_M op 19-07-2019 11:47 ]

[JB]

The Eagle schreef op vrijdag 19 juli 2019 @ 11:26:
[...]

Als het signaal sterk genoeg is hoeft dat roamen niet plaate te vinden natuurlijk.
Verder is het ook de vraag hoe de rest van je config er uit ziet. Heb je bijvoorbeeld een gedeeld SSID voor 2Ghz en 5Ghz of apart, en hoe sterk staan beide banden te zenden en heb je auto handover etc ingesteld? 5Ghz signaal is meestal niet zo sterk, daar zie je sneller dat ie gaat roamen.
En welke banden ondersteunen je TV's? Kan me zomaar voorstellen dat dat alleen een 2,4Ghz band is.

Ik gebruik de AC inrichting dus een gecombineerde 2.4/5GHz. Zal dat ook nog even verduidelijken.

Signaalsterkte heb ik mee gespeeld maar biedt geen soelaas. Staat nu weer op AUTO. Auto handover is nieuw voor mij, zal eens kijken maar volgens mij doen mijn oudjes (AC-LR) dat niet ondersteunen. Dan nog, ik heb zoals aangeven een 2e tv zonder issues en genoeg andere apparaten die zonder problemen werken. Dit is de enige/laatste die vervelend doet in mijn netwerk.

[ Voor 11% gewijzigd door JB op 19-07-2019 11:57 ]

[nero355]

wimmel_1 schreef op vrijdag 19 juli 2019 @ 11:30:
@JB & @The Eagle

Ik heb hier sinds een aantal weken ongeveer hetzelfde 'issue' sinds een OS update van m'n TV en ga dus even mee 'lezen'. Ik ben normaliter meer van 't zélf uitpluizen (Wireshark FTW) maar heb daar de laatste tijd géén tijd voor gehad en voorzie er ook geen mogelijkheid toe in de komende maanden.

wimmel_1 in "Philips TV's - 2015 en nieuwer"

Ik heb hier overigens een 4-tal NANO-HD's in huis hangen waarbij alle SSID's ook op beide banden gehost worden. TV kán ook AC aan en is ook hier de énige 'ellendeling' op m'n netwerk (en tevens het énige Android device in huis).

Android of niet : Al die oh zo slimme TV's hebben over het algemeen 2 grote problemen =>

1. De SoC die erin zit is echt het minimale van het minimale!
Geef die ietsje meer te doen dan dat die voor bedoeld was en het hele ding flipt meteen

2. Heel veel TV's zitten constant de hele dag door connecties naar buiten op te bouwen, terwijl jij de TV niet eens gebruikt!

En dan krijg je dit soort leuke resultaten als je Pi-Hole gebruikt :
https://discourse.pi-hole...ke-with-a-samsung-tv/3165

Sony TV's kunnen er ook wat van trouwens net als de Samsung TV die wordt genoemd in dat topic!


Kortom : Indien mogelijk prop er een kabel in en zo niet... tja... de hele meuk uitschakelen en een Chromecast of nVidia Shield TV kopen of zo
_{Die ook naar huis toe bellen... vooral de Chromecast!}

[Will_M]

nero355 schreef op vrijdag 19 juli 2019 @ 14:51:
[...]

Android of niet : Al die oh zo slimme TV's hebben over het algemeen 2 grote problemen =>

1. De SoC die erin zit is echt het minimale van het minimale!
Geef die ietsje meer te doen dan dat die voor bedoeld was en het hele ding flipt meteen

2. Heel veel TV's zitten constant de hele dag door connecties naar buiten op te bouwen, terwijl jij de TV niet eens gebruikt!

En dan krijg je dit soort leuke resultaten als je Pi-Hole gebruikt :
https://discourse.pi-hole...ke-with-a-samsung-tv/3165

Sony TV's kunnen er ook wat van trouwens net als de Samsung TV die wordt genoemd in dat topic!


Kortom : Indien mogelijk prop er een kabel in en zo niet... tja... de hele meuk uitschakelen en een Chromecast of nVidia Shield TV kopen of zo
_{Die ook naar huis toe bellen... vooral de Chromecast!}

De Philips TV's mogen hier al sinds 2008 (éérste NET-TV oplossing van Philips) niet zomaar 'zelfstandig' 't Internet op.... Philips heeft me met zo'n 2008 TV destijds tot 3 keer toe van een nieuw moederbord voorzien doordat 't spel niet werkte zoals verwacht. Als de monteur kwam en ging testen dan gebruikte 'ie een 3G UMTS module om te connecten en dan werkte alles wél..... Dus maar weer een nieuw moederbord er in want de NIC zal wel stuque zijn....

Dat 'Android' OS wat er op m'n huidige TV draait ligt onder een nog véél groter vergrootglas

Het enige waarbij ik een "IP" connectie nodig heb op m'n TV is het "Ziggo On-Demand" deel. De sturing van dat 'spel' loopt over TCP/IP en niet over de COAX kabel. Ik heb géén internet via Ziggo.... Om 't nog makkelijker te maken

Kortom: Ik zit dus met smacht te wachten op de "Ziggo-Go" -App voor op de AppleTV 4 / 4K

[ Voor 9% gewijzigd door Will_M op 19-07-2019 15:34 ]

[JB]

@nero355 Nou bij mij gaat 2. niet op anders kon ik de tv ook "smart" gebruiken zonder eerst een herstart nodig te hebben

[Vliegvlug]

Vandaag wat bezig geweest om een OpenVPN server op mijn EdgeRouter 4 aan de praat te krijgen.

Best ver gekomen op basis van een aantal handleidingen:

• MdBruin in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 2"
• How to setup an OpenVPN server on the Edgerouter:
  https://medium.com/server...e-edgerouter-de343f262e6e
• EdgeRouter - OpenVPN Server:
  https://help.ubnt.com/hc/...EdgeRouter-OpenVPN-Server
• EdgeRouter OpenVPN Setup:
  https://www.robinvanbrugg...edgerouter-openvpn-setup/

Overal gaan ze er vanuit dat de EdgeRouter ook het externe IP heeft maar ik wilde gebruik maken van port forwarding vanuit de router van de provider.

Lokaal binnen mijn LAN kan ik wel een OpenVPN tunnel opgezet krijgen maar ondanks het instellen van de port forward wil het maar niet van buitenaf lukken.
Achteraf op zich niet een heel groot probleem aangezien ik er intussen ook achter ben dat de Ubee EVW3200 blijkbaar geen statische routes ondersteund dus dan gaat het sowieso niet werken.
Zal dus Ziggo moeten vragen mijn modem in bridge modus te zetten om het externe IP op de Ubiquiti te laten landen.
Op zich ook niet verkeerd want is natuurlijk stuk beter dan die ziggo router.

Nog wel een vraag met betrekking tot de OpenVPN tunnel en het pingen van de edgerouter op het interne tunnel IP: Dat lukte niet.

De VPN client kreeg IP 192.168.200.2 en de Edgerouter heeft IP 192.168.200.1 maar toch kon ik het .1 adres niet pingen vanaf de client.

Dat zou toch gewoon moeten kunnen?
Heb alle aanwezige firewall policies al op default accept gezet maar dat maakte niets uit.

[Freeaqingme]

Vliegvlug schreef op vrijdag 19 juli 2019 @ 22:37:
De VPN client kreeg IP 192.168.200.2 en de Edgerouter heeft IP 192.168.200.1 maar toch kon ik het .1 adres niet pingen vanaf de client.

Dat zou toch gewoon moeten kunnen?
Heb alle aanwezige firewall policies al op default accept gezet maar dat maakte niets uit.

Nee, dat kan niet. Dat wil zeggen, in mijn OpenVPN setup werkt dat ook niet, en volgens mij werkt dat doorgaans nooit. Is wel iets OpenVPN-eigens, networking-wise zou het inderdaad gewoon moeten kunnen.

$ ip -4 r s dev tun0
172.31.0.0/16 via 172.31.249.5
172.31.249.5 proto kernel scope link src 172.31.249.6

$ ip -4 a s tun0
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
inet 172.31.249.6 peer 172.31.249.5/32 scope global tun0
valid_lft forever preferred_lft forever

$ ping -c5 172.31.249.5
PING 172.31.249.5 (172.31.249.5) 56(84) bytes of data.

--- 172.31.249.5 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4094ms

$ ping -c5 172.31.249.1
PING 172.31.249.1 (172.31.249.1) 56(84) bytes of data.
64 bytes from 172.31.249.1: icmp_seq=1 ttl=64 time=11.9 ms
^C
--- 172.31.249.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 11.930/11.930/11.930/0.000 ms

Die 172.31.249.5 is dus het point-to-point ip op de server, .6 op de client. De .1 is het ip wat ik zie als ik 'ip -4 a s dev tunUdp' doe op de server.

Snippet uit de Openvpn serverconfig:

tls-server
proto udp6
port 1194
persist-key
persist-tun
persist-local-ip
persist-remote-ip

server 172.31.249.0 255.255.255.128
push "route 172.31.0.0 255.255.0.0"

Als je problemen ervaart met je NAT-forwards zou je eens kunnen proberen of het over TCP beter werkt. UDP werkt soms net niet altijd even lekker (Ziggo's DDOS apparatuur, Vodafone die 't op 4g verbindingen gewoon helemaal blokkeerde een paar jaar terug, etc...).

offtopic:
Ik heb de output van m'n console wat opgeschoond voordat ik 't paste. Denk dat alle relevante dingen er in zitten, maar het is niet 1:1 overgenomen.

[BushWhacker]

Vliegvlug schreef op vrijdag 19 juli 2019 @ 22:37:
Vandaag wat bezig geweest om een OpenVPN server op mijn EdgeRouter 4 aan de praat te krijgen.

Best ver gekomen op basis van een aantal handleidingen:

• MdBruin in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 2"
• How to setup an OpenVPN server on the Edgerouter:
  https://medium.com/server...e-edgerouter-de343f262e6e
• EdgeRouter - OpenVPN Server:
  https://help.ubnt.com/hc/...EdgeRouter-OpenVPN-Server
• EdgeRouter OpenVPN Setup:
  https://www.robinvanbrugg...edgerouter-openvpn-setup/

Overal gaan ze er vanuit dat de EdgeRouter ook het externe IP heeft maar ik wilde gebruik maken van port forwarding vanuit de router van de provider.

Lokaal binnen mijn LAN kan ik wel een OpenVPN tunnel opgezet krijgen maar ondanks het instellen van de port forward wil het maar niet van buitenaf lukken.
Achteraf op zich niet een heel groot probleem aangezien ik er intussen ook achter ben dat de Ubee EVW3200 blijkbaar geen statische routes ondersteund dus dan gaat het sowieso niet werken.
Zal dus Ziggo moeten vragen mijn modem in bridge modus te zetten om het externe IP op de Ubiquiti te laten landen.
Op zich ook niet verkeerd want is natuurlijk stuk beter dan die ziggo router.

Nog wel een vraag met betrekking tot de OpenVPN tunnel en het pingen van de edgerouter op het interne tunnel IP: Dat lukte niet.

De VPN client kreeg IP 192.168.200.2 en de Edgerouter heeft IP 192.168.200.1 maar toch kon ik het .1 adres niet pingen vanaf de client.

Dat zou toch gewoon moeten kunnen?
Heb alle aanwezige firewall policies al op default accept gezet maar dat maakte niets uit.

Als je een port-forward maakt udp1194 naar de er4, tenminste als je de standaard gebruikt, zou het moeten werken.
Behalve..... Heb je van Ziggo een IPv6 adres? Dan is de kans groot dat je achter een CGNAT zit en heb je geen publiek ipv4 adres.
Dan is de enige oplossing bridge mode, maar dan verlies je je IPv6 prefix.

Openvpn moet een eigen subnet hebben.
Bv. Gewone lan 192.168.200.0/24, openvpn bv 192.168.201.0/24

[Workaholic]

Hi! Wat is in jullie ogen de beste aanpak om wifi te krijgen in een B&B als het internet alleen beschikbaar is in het woonhuis op +-40 meter afstand?



Momenteel is het zo ingeregeld:

Pfsense met 3 interfaces. 1 WAN, LAN (prive) en Guest (B&B).

Guest netwerk is direct verbonden met Engenius ecb350 wireless bridge in AP mode. Engenius heeft een directe kabel verbinding met straal antenne die naar B&B het signaal stuurt met daar achter nog een linksys AP.

LAN wifi netwerk is allemaal linksys AP's. 11Ghz.

Dit werkt niet helemaal lekker (B&B) en wifi netwerk is verouderd/te langzaam en willen we dus verbeteren en direct alle WIFI accesspoints vervangen voor Ubiquiti. LAN is niet zo lastig - maar wat zouden we toepassen voor B&B connectie? Antenne vervangen voor Beam setup van Ubiquiti?

[ Voor 31% gewijzigd door Workaholic op 20-07-2019 12:42 ]

[lier]

posttoast schreef op donderdag 18 juli 2019 @ 17:43:
Edit @lier doel je op een json bestand? Die kan ik gewoon uit de webinterface van de controller trekken toch? Ik ben niet bij dat familielid thuis nu, dus ik heb geen SSH toegang tot devices op het moment.

'Show System Config', onderdeel van Settings, Maintenance

[m3gA]

Workaholic schreef op zaterdag 20 juli 2019 @ 12:09:
Hi! Wat is in jullie ogen de beste aanpak om wifi te krijgen in een B&B als het internet alleen beschikbaar is in het woonhuis op +-40 meter afstand?

[Afbeelding]

Momenteel is het zo ingeregeld:

Pfsense met 3 interfaces. 1 WAN, LAN (prive) en Guest (B&B).

Guest netwerk is direct verbonden met Engenius ecb350 wireless bridge in AP mode. Engenius heeft een directe kabel verbinding met straal antenne die naar B&B het signaal stuurt met daar achter nog een linksys AP.

LAN wifi netwerk is allemaal linksys AP's. 11Ghz.

Dit werkt niet helemaal lekker (B&B) en wifi netwerk is verouderd/te langzaam en willen we dus verbeteren en direct alle WIFI accesspoints vervangen voor Ubiquiti. LAN is niet zo lastig - maar wat zouden we toepassen voor B&B connectie? Antenne vervangen voor Beam setup van Ubiquiti?

[Afbeelding] [Afbeelding] [Afbeelding] [Afbeelding] [Afbeelding]

Ik zou het oplossen met inderdaad een beam oplossing en op de lokatie zelf een paar normale AP's inzetten.
Beetje lastig in te schatten welke de juiste zijn voor jullie aangezien ik de situatie niet ken.

[Workaholic]

m3gA schreef op zaterdag 20 juli 2019 @ 12:47:
[...]

Ik zou het oplossen met inderdaad een beam oplossing en op de lokatie zelf een paar normale AP's inzetten.
Beetje lastig in te schatten welke de juiste zijn voor jullie aangezien ik de situatie niet ken.

En welke zou je dan adviseren? 2 stuks die naar elkaar toe wijzen (ivm retour signaal)? 1 B&B en 1 Woonhuis? 40 meter afstand lijkt me niet zo veel als je ze buiten de woning(en) hebt hangen.

[ Voor 8% gewijzigd door Workaholic op 20-07-2019 13:03 ]

[Vliegvlug]

Freeaqingme schreef op vrijdag 19 juli 2019 @ 22:57:
[...]

Nee, dat kan niet. Dat wil zeggen, in mijn OpenVPN setup werkt dat ook niet, en volgens mij werkt dat doorgaans nooit. Is wel iets OpenVPN-eigens, networking-wise zou het inderdaad gewoon moeten kunnen.

[...]

Goed om te weten!
Hoef ik me daar niet druk om te maken, wel vreemd dat het niet kan, vraag me af waarom eigenlijk.

Is het wel mogelijk dat VPN clients elkaar onderling kunnen pingen?
(Er vanuitgaande dat de firewalls op die clients ping toestaan natuurlijk.)

BushWhacker schreef op zaterdag 20 juli 2019 @ 10:12:
[...]

Als je een port-forward maakt udp1194 naar de er4, tenminste als je de standaard gebruikt, zou het moeten werken.
Behalve..... Heb je van Ziggo een IPv6 adres? Dan is de kans groot dat je achter een CGNAT zit en heb je geen publiek ipv4 adres.
Dan is de enige oplossing bridge mode, maar dan verlies je je IPv6 prefix.

Openvpn moet een eigen subnet hebben.
Bv. Gewone lan 192.168.200.0/24, openvpn bv 192.168.201.0/24

Volgens mij heb ik geen IPv6 adres van Ziggo, ik gebruik het in elk geval niet. Heb wel een regulier extern IPv4 adres.

En ben met je eens dat de port forward zou moeten werken maar zelfs als dat werkt heb ik er niets aan.
Het subnet dat ik voor de OpenVPN heb geconfigureerd is 192.168.200.0/24 en mijn reguliere LAN is 172.16.16.0/24 waarbij de ziggo modem 172.16.16.1 is en de Edgerouter 172.16.16.4.
Aangezien ik de Ziggo modem niet kan vertellen dat 192.168.200.0/24 achter 172.16.16.4 ligt kunnen OpenVPN clients wel verkeer richting het LAN sturen maar nooit verkeer ontvangen vanaf het LAN.

Zo ziet de port forward in de Ubee eruit:

Maar dit werkt dus niet. En toen stond de forward uiteraard wel aan
Misschien dat ik mijn externe IP moet invullen ipv 0.0.0.0 zoals nu maar dat heb ik verder niet getest.

[Alsjemenou]

Workaholic schreef op zaterdag 20 juli 2019 @ 12:09:
Hi! Wat is in jullie ogen de beste aanpak om wifi te krijgen in een B&B als het internet alleen beschikbaar is in het woonhuis op +-40 meter afstand?

Natuurlijk zou je iets kunnen doen met twee NanoBeam 5AC Gen2 antenne's of iets soortgelijks, maar om eerlijk te zijn vind ik dat een beetje overdreven voor zo'n korte afstand. Als je honderden meters wilt overbruggen is dat prima, maar ik zou het eerder oplossen met iets eenvoudigs:

https://www.allekabels.nl...el-op-rol/grondkabel.html

Het kost je iets meer werk om de kabel in de grond te leggen, maar het scheelt je wel wat centen en je zit niet met een overgecompliceerde setup. CAT5E is prima hiervoor.

[Workaholic]

Alsjemenou schreef op zaterdag 20 juli 2019 @ 13:22:
[...]


Natuurlijk zou je iets kunnen doen met twee NanoBeam 5AC Gen2 antenne's of iets soortgelijks, maar om eerlijk te zijn vind ik dat een beetje overdreven voor zo'n korte afstand. Als je honderden meters wilt overbruggen is dat prima, maar ik zou het eerder oplossen met iets eenvoudigs:

https://www.allekabels.nl...el-op-rol/grondkabel.html

Het kost je iets meer werk om de kabel in de grond te leggen, maar het scheelt je wel wat centen en je zit niet met een overgecompliceerde setup. CAT5E is prima hiervoor.

Dat had ook mijn voorkeur maar mijn ouders willen niet gaan graven helaas.. 2x Nano beam 5ac Gen2 dus. Is het hierbij verstandig om nog een AC te plaatsen aan de B&B kant? Of is de Nano direct voldoende ?

[Alsjemenou]

Workaholic schreef op zaterdag 20 juli 2019 @ 13:27:
[...]


Dat had ook mijn voorkeur maar mijn ouders willen niet gaan graven helaas.. 2x Nano beam 5ac Gen2 dus. Is het hierbij verstandig om nog een AC te plaatsen aan de B&B kant? Of is de Nano direct voldoende ?

Het is een PTP verbinding, dus daarachter zou ik weer een switch plaatsen met een access point. Hier ga je het wel mee redden: YouTube: Simple PTP Wireless Bridge