Port forwarding. Waarom onveilig?

[keroner]

Ola Tweakers,

Ik ben recent met Home Assistant gestart en wil mij Home Assistant natuurlijk ook vanaf buitenaf kunnen benaderen.
De meest makkelijke manier hiervoor is om in mijn router via port forwarding dit toe te wijzen.
Ik lees echter veel dat dit onveilig is, maar kan iemand uitleggen waarom dit zo onveilig is?
Als ik achter mijn WAN IP adres een volledig willekeurige port (288, ik roep maar wat) laat forwarden naar mijn Home Assistant interne IP/port en de toegang tot Home Assistant ook nog om credentials vraagt lijkt mij (maar hier schiet mijn kennis waarschijnlijk tekort) dit toch behoorlijk veilig?

Voor een aanvaller is de volgende info nodig lijkt mij,
- WAN IP (makkelijk te achterhalen als ze eenmaal weten wie ik ben)
- Geforwarde port (er zijn geloof ik 65.535 porten beschikbaar, dus niet voor de hand liggend te vinden)
- Mijn Home Assistant credentials (ik gebruik altijd strong passwords)

Het lijkt mij dan ook ontzettend veilig om bovenstaande situatie op te zetten, maar toch wordt dit afgeraden.
Er wordt echter nergens duidelijk uitgelegd waarom dit nou zo onveilig is.
Ik wil niet eigenwijs bovenstaande doordrukken/verdedigen. Dit is gewoon een vraag om mijn kennis uit te breiden. Uiteraard zal ik in de DNS/VPN optie duiken als dat aangeraden wordt.

Alvast bedankt om deze netwerk leek wat wijzer te maken......

[Craven]

Een aanvaller target niet jou persoonlijk. Maar zoekt gewoon op random ip's volledig automatisch alle poorten af om te kijken of er iets open staat. Dat weerlegt jouw 1e en 2e punt al.

Dat je een strong password gebruikt is mooi. Maar gebruik je die op meerdere plekken? Zo ja, dan kan die buit gemaakt zijn en kan hij er alsnog in.

Los daarvan is home assistant geen product ontworpen om exposed te zijn aan het internet. Hoe goed ze hun best ook doen er kan altijd een security hole in zitten. Zelfs als je netjes patched kan het een zero day zijn.

Je bent beter af met je lokale netwerk ontsluiten via een daarvoor bedoeld product. Denk bvb een VPN server. Waarop draai je home assistant? Daarnaast kan je mogelijk openvpn of iets vergelijkbaars draaien.

[Orion84]

keroner schreef op zondag 22 januari 2023 @ 21:52:
Voor een aanvaller is de volgende info nodig lijkt mij,
- WAN IP (makkelijk te achterhalen als ze eenmaal weten wie ik ben)
- Geforwarde port (er zijn geloof ik 65.535 porten beschikbaar, dus niet voor de hand liggend te vinden)

Het is niet zo heel moeilijk voor aanvallers om grote reeksen IPs te scannen op openstaande poorten (en evt. wat tests te doen op wat er op die poort luistert). Deze twee punten kan je dus niet echt beschouwen als onderdeel van je beveiliging.

- Mijn Home Assistant credentials (ik gebruik altijd strong passwords)

Sterke wachtwoorden is goed. Gebruik je HTTPS om home assistant te benaderen? Zoniet, dan is dat wachtwoord te onderscheppen (bijvoorbeeld op onveilige publieke hotspots en dergelijke).

En met de wachtwoord login als enige echte beveiligingslaag zit je dus ook nog met het scenario dat er een keer een kwetsbaarheid in Home Assistant zit waardoor die login omzeild kan worden. En zodra dat zo is wordt het ook aantrekkelijk voor aanvallers om, zoals hierboven genoemd, te gaan scannen op toegankelijke HA installaties.

[ Voor 6% gewijzigd door Orion84 op 22-01-2023 22:00 ]

[pennywiser]

Het is niet direct onveilig als je een sterk ww gebruikt. Gebruik HTTPS. Zelfs een self signed is veiliger dan geen HTTPS.

[c-nan]

Er is niks onveiligs aan port forwarding. Wat onveilig is dat je apps direct aan het internet exposed. Je kan wel een sterk wachtwoord hebben, maar wat als er een bug aanwezig is in de software?

[keroner]

Zo blij met Tweakers In 15 minuten meer geleerd dan in de afgelopen uren in tutorials en faqs.
Ontzettend bedankt voor deze basale (maar toch moeilijk te vinden) info.

Hoewel de kans klein is (op basis van deze info) is hij toch te groot
Ik ga mij verdiepen in alternatieve oplossingen.

Craven schreef op zondag 22 januari 2023 @ 21:57:
Je bent beter af met je lokale netwerk ontsluiten via een daarvoor bedoeld product. Denk bvb een VPN server. Waarop draai je home assistant? Daarnaast kan je mogelijk openvpn of iets vergelijkbaars draaien.

HASS draait op een W11 mini pc (host) in een vm. Heb nog niet veel kennis van VPN en VPN servers (behalve dat het voor virtual private network staat en m'n werkgevers het ook gebruiken), maar ga mij hier nu wel in verdiepen.

Thanks!!

[keroner]

Voor de duidelijkheid.
SSL en HTTPS zijn om 'sniffing' te voorkomen toch? Als je wachtwoord elders al in een datalek naar voren is gekomen heb je hier niets aan, correct?

[Flans]

keroner schreef op zondag 22 januari 2023 @ 22:17:
Voor de duidelijkheid.
SSL en HTTPS zijn om 'sniffing' te voorkomen toch? Als je wachtwoord elders al in een datalek naar voren is gekomen heb je hier niets aan, correct?

Correct.

[sypie]

En daarom: Wachtwoordmanager/methode om al je wachtwoorden te bewaren én te kiezen voor lange unieke wachtwoorden. Je moet je wachtwoorden net zo gebruiken als je ondergoed: niet laten slingeren, niet delen, niet meerdere keren gebruiken en regelmatig verversen.

[ZatarraNL]

sypie schreef op maandag 23 januari 2023 @ 06:55:
En daarom: Wachtwoordmanager/methode om al je wachtwoorden te bewaren én te kiezen voor lange unieke wachtwoorden. Je moet je wachtwoorden net zo gebruiken als je ondergoed: niet laten slingeren, niet delen, niet meerdere keren gebruiken en regelmatig verversen.

Prachtige vergelijking! Maarre, jij gooit je onderbroeken na één keer gebruiken altijd weg? 😋

[Archie_T]

Ik heb MFA aangezet op mijn HomeAssistant, dat helpt ook weer het hele "gebruik een sterk wachtwoord" discussie.

[Kabouterplop01]

keroner schreef op zondag 22 januari 2023 @ 22:14:

Hoewel de kans klein is (op basis van deze info) is hij toch te groot

Dat is nou exact de misvatting; je weet niet in hoeverre de applicatie hardened is.
Oftewel zo secure geprogrammeerd dat er geen bugs zitten die leiden tot compromittatie.

Er werd al even geroepen dat het makkelijk is om grote ipreeksen af te scannen. Welnu het internet wordt meerdere keren per dag door dezelfde lui helemaal doorgeharkt.
En dat zijn beroepscybercriminelen tot kwetsbaarheden scanners van security researchers die je willen informeren dat je (goedbedoeld) een kwetsbaarheid in jouw <zet hier je internet exposed applicatie neer> hebt.

De misvatting komt door je aanname; nooit iets klakkeloos aannemen!

[ Voor 0% gewijzigd door Kabouterplop01 op 23-01-2023 08:52 . Reden: typo's ]

[D4NG3R]

Ik probeer zelf altijd een of andere auto-analogie te maken, laatst vroeg iemand mij iets vergelijkbaars:

Stel jij hebt een garage aan je woning zitten en daar staat een auto in. Als jij de garage van het slot haalt
(= open poort) kan je bij de auto komen.

Dat kan op zich weinig kwaad mits de auto zelf nog wel goed op slot zit (= veilige applicatie).

Stel nu dat het achterraampje van de auto op een kiertje staat (= onveilige applicatie) en ze daar de sleutel van de deur naar de keuken aantreffen (= de rest van je systeem ligt bloot).

Gezien de gevoeligheid van wat er op HASS kan draaien raden veel mensen inderdaad aan om een reverse proxy en/of VPN op te zetten. Let wel op dat ook dat een vals gevoel van veiligheid kan opleveren, het blijft belangrijk om de server kant goed op slot te zetten, en het blijft belangrijk om niet met onveilige clients met je server te verbinden.

[ Voor 15% gewijzigd door D4NG3R op 23-01-2023 09:09 ]

[jay123]

Bijkomende vraag; Maakt het dan een verschil om een Reverse Proxy zoals Nginx (in combo met duckdns vb) te gebruiken voor de ports achter te verstoppen?

(Volgende stukje is volgens mijn beperkte kennis, dus neem met een korrel zout:) Op zich worden de poorten dan toch niet exposed, maar verloopt alles via een subdomain.
Is dat dan een extra laag beveiliging, of is dit maar enkel in gevoel?

[Ben(V)]

Als je een port forward doet naar een bepaalde poort moet je er zeker van zijn dat er op dat device iets draait dat alles wat op die poort binnenkomt afvangt en alleen wat de juiste credentials heeft gaat verwerken.
Het probleem is dat bijna alle applicaties niet hardend genoeg zijn om alle trucjes die hackers tot hun beschikking hebben tegen te houden.
Tevens kan zo'n applicatie wel eens down gaan en dan is er niets meer wat die poort beschermt.

De focus ligt bij dit soort applicaties op functionaliteit en niet op security.
Zoals je weet krijg je regelmatig security updates van je OS (Windows, Linux) en die hebben een hele sterke focus op security en hacks, dat ligt bij dit soort applicaties heel anders.

De beste oplossing is een VPN server gebruiken en vanaf het internet met een VPN client in te loggen.
Een VPN server is gebouwd om die poort te beschermen en alleen verkeer met de juiste credential (username, password en certificate) door te laten.
En een proxy is ook tamelijk nutteloos om je te beschermen tegen hacker, dat is alleen maar verstoppertje spelen en hackers zijn daar veel beter in dan jij.

[Freekers]

Craven schreef op zondag 22 januari 2023 @ 21:57:
Los daarvan is home assistant geen product ontworpen om exposed te zijn aan het internet. Hoe goed ze hun best ook doen er kan altijd een security hole in zitten. Zelfs als je netjes patched kan het een zero day zijn.

Laat ik voorop stellen; ik ben het met je eens maar.... volgens diezelfde redenatie kun je geen enkel stukje software open zetten voor de buitenwereld. Er kan immers in elk software pakket een zero day zijn. En ja, dat is de afgelopen jaren vaker voorgekomen bij grote pakketten zoals apache.

[Craven]

@Freekers klopt. Je loopt altijd een bepaald risico. Het is maar net hoe ver je hierin wilt gaan. Ik vertrouw een openvpn of wireguard hier een stuk meer mee dan een home assistant. Security is bij de eerste core business en bij HA 1 van de vele zaken die belangrijk is.

Los daarvan ben je met 1 keer VPN klaar. Als je meer zaken wilt ontsluiten moet je ze allemaal een port forward geven en zo maak je je attack surface en risico op potentiele breach steeds groter.

[D4NG3R]

jay123 schreef op maandag 23 januari 2023 @ 09:26:
Bijkomende vraag; Maakt het dan een verschil om een Reverse Proxy zoals Nginx (in combo met duckdns vb) te gebruiken voor de ports achter te verstoppen?

(Volgende stukje is volgens mijn beperkte kennis, dus neem met een korrel zout:) Op zich worden de poorten dan toch niet exposed, maar verloopt alles via een subdomain.
Is dat dan een extra laag beveiliging, of is dit maar enkel in gevoel?

Combinatie van SSL en het feit dat (als je het goed doet) het IP van de bronserver niet achterhaald kan worden maakt het absoluut wel veiliger.

[Ben(V)]

@Freekers
Nee dat is de laatste jaren vaker ontdekt in grote pakketten.
Dat is heel wat anders.

Met name applicaties die met iot bezig zijn focussen zich enkel op functionaliteit en niet op security.

@D4NG3R
En ssl maakt natuurlijk alleen het transport onderweg veiliger en niet de applicatie zelf.
En IP-adressen verstoppen kan helemaal niet.

Ik blijf erbij gewoon een VPN server gebruiken is het veiligst.

[ Voor 4% gewijzigd door Ben(V) op 23-01-2023 10:04 ]

[D4NG3R]

Ben(V) schreef op maandag 23 januari 2023 @ 10:03:
@D4NG3R
En ssl maakt natuurlijk alleen het transport onderweg veiliger en niet de applicatie zelf.

Klopt, maar de vraag ging over reverse proxies.

En IP-adressen verstoppen kan helemaal niet.

Zeer zeker kan dat wel. De communicatie van en naar de server verloopt via de reverse proxy, niet direct tussen de client en server.

Client <> ( reverse proxy <> server. )

De meeste mensen hosten hun reverse proxy echter op dezelfde bronserver, en ja dan gaat die vlieger niet op.

Een VPN gebruiken is absoluut wel het veiligst ja.

[ Voor 4% gewijzigd door D4NG3R op 23-01-2023 10:09 ]

[Thijsmans]

Waarom heeft nog niemand gewezen op de Wireguard add-on? Vergt nog steeds een port-forward, maar dan naar een applicatie die ervoor is bedoeld

[laurens0619]

jay123 schreef op maandag 23 januari 2023 @ 09:26:
Bijkomende vraag; Maakt het dan een verschil om een Reverse Proxy zoals Nginx (in combo met duckdns vb) te gebruiken voor de ports achter te verstoppen?

(Volgende stukje is volgens mijn beperkte kennis, dus neem met een korrel zout:) Op zich worden de poorten dan toch niet exposed, maar verloopt alles via een subdomain.
Is dat dan een extra laag beveiliging, of is dit maar enkel in gevoel?

Niet perse, kan wel
Encryptie TLS toevoegen is ook beperkt, alleen bij MITM maar dat zie je in de praktijk niet als oorzaak bij bepaalde aanvallen.

Wat je wel kunt doen is met die reverse proxy eerste een authenticatie af te dwingen (op ngingx laag) voordat je bij de applicatie kan. Dat is een soort VPN in de browser.
Een hacker kan echt pas bij iets als homeassistant.php nadat een (MFA) sessie is goedgekeurd.

Best briljant stukje techniek want je kunt dus iedere web applicatie achter een stukje techniek leggen die ontworpen is op remote toegang (net als vpn) zonder dat je er "last" van hebt. Voordeel is ook dat (bijna) iedere web app hiermee werkt, alleen smartphone apps kunnen wat dwars liggen


https://learn.microsoft.c...p-proxy/application-proxy

Geen idee of dit bestaat voor nginx trouwens

[ Voor 11% gewijzigd door laurens0619 op 23-01-2023 10:14 ]

[Ben(V)]

Snap dat iedereen gecompliceerde oplossingen wil aandragen met al dan niet toegevoegde beveiligingen, maar VPN server is gewoon het simpelste en het velligste.

@Thijsmans
Wireguard is een VPN net als OpenVpn

[Thijsmans]

@Ben(V) ...maar dan beter presterend (lagere ping, hogere throughput) en verkrijgbaar als add-on. Niet om een discussie "wireguard vs openvpn" uit te lokken, maar dit zijn punten die in elk geval een eigen vermelding van WG rechtvaardigen

[thunder8]

Zou alles zo dicht mogelijk laten.

Onlangs is een website gehacked die in mijn beheer was. Spam Link Injection. Simpele wordpress site met een paar plugins en slechts 3 gebruik logins. Website verwijderd, opnieuw opgebouwd. Nieuwe admin user aangemaakt met sterk wachtwoord en een security programma met firewall. Als ik zie wat er aan pogingen gedaan worden per dag om de site in te komen, zal je versteld van staan. En deze komen van elk denkbaar land op de wereld. Ingesteld dat elk ip adres dat probeert op de oude accounts in te loggen meteen permanent worden geblocked.

Als je dan persé van buitenaf er bij wil, zou ik alleen een VPN in overweging nemen. En als het niet strikt noodzakelijk is, gewoon lekker niet van buitenaf beschikbaar laten zijn. Vroeger of later is er altijd een hacker die binnenkomt.

[RCBL]

Was ook zo iemand die dacht dat portforwarding met een exotische poort en een sterk wachtwoord afdoende zou moeten zijn. Na wat ingelezen te hebben was het oog al snel gevallen op openvpn.

Vele routers hebben de mogelijkheid tot het draaien van een openserver dienst. Deze gebruik ik dus nu ook om vanaf buiten verbinding te maken met mijn netwerk en alles via de telefoon [waar de client op draait] te doen wat ik wil doen in dat netwerk. De router maakt ook zelf een .opvn aan met certificaat die je kan gebruiken om je client mee te configureren

Op dit moment voel ik mij toch wat veiliger dan met alleen het open zetten van poorten

[Drardollan]

sypie schreef op maandag 23 januari 2023 @ 06:55:
En daarom: Wachtwoordmanager/methode om al je wachtwoorden te bewaren én te kiezen voor lange unieke wachtwoorden. Je moet je wachtwoorden net zo gebruiken als je ondergoed: niet laten slingeren, niet delen, niet meerdere keren gebruiken en regelmatig verversen.

Het grootste deel van je advies is correct, op het regelmatig verversen na. Dat is echt achterhaald. Als je overal een uniek en sterk wachtwoord gebruikt dan is deze vandaag net zo kwetsbaar als morgen als over 3 maanden als over 2 jaar. Tijd is geen factor die van belang is vanuit veiligheidsoogpunt van unieke en sterke wachtwoorden.

Tenzij je wachtwoord gelekt is of bijvoorbeeld zoals laatst bij LastPass de wachtwoord databases ontvreemd zijn. Dan worden tijd en verversen ineens een groot punt.

Maar preventief, dus zonder reden, veranderen van unieke en sterke wachtwoorden levert geen enkele extra veiligheid op.

[PhilipsFan]

HomeAssistant is er niet op gemaakt om direct aan internet te worden gehangen. Sowieso is alleen een wachtwoord tegenwoordig niet meer genoeg beveiliging, maar HomeAssistant is niet genoeg getest op alle aanvalsscenario's. En dan heb je nog alle plugins van HomeAssistant die lekken kunnen veroorzaken. Niet verstandig dus om rechtstreeks aan internet te hangen. Je IP-adres en poort hebben ze binnen notime gevonden, daarvoor gebruiken ze speciale scansoftware.

Een VPN server is WEL bedoeld om vanaf internet toegankelijk te zijn. Je moet dan ook een poort forwarden, maar de VPN server bevat allerlei waarborgen om te zorgen dat alleen jij toegang krijgt. Zo wordt er bijvoorbeeld al niet gereageerd op verzoeken waarbij een certificaat ontbreekt. Certificaten zijn ook veel veiliger dan wachtwoorden omdat ze veel groter zijn.

Een handige VPN hiervoor is Wireguard. Die wordt beschouwd als veilig en presteert goed. Heeft ook een app voor Apple en Android waarmee je het zo kunt instellen dat buitenshuis het verkeer over de VPN wordt geleid, zodat je het niet telkens aan- en uit hoeft te zetten. Als je ergens een Docker server hebt, dan is het echt een breeze om te installeren, maar het kan ook op Windows.

[donny007]

Je kunt ook kiezen voor een ZTNA (Zero-Trust Network Access) oplossing, zelf gebruik ik bijvoorbeeld Cloudflare Tunnels/Access om Home Assistant op een veilige manier te ontsluiten.

Het is in feite een reverse-proxy in de cloud met een extra autorisatielaag en web application firewall, de verbinding tussen de proxy-provider en Home Assistant loopt via een beveiligde tunnel zonder dat daarvoor poorten hoeven te worden geopend.



https://developers.cloudf...onnect-apps/#how-it-works

[Ben(V)]

Thijsmans schreef op maandag 23 januari 2023 @ 10:20:
@Ben(V) ...maar dan beter presterend (lagere ping, hogere throughput) en verkrijgbaar als add-on. Niet om een discussie "wireguard vs openvpn" uit te lokken, maar dit zijn punten die in elk geval een eigen vermelding van WG rechtvaardigen

Add-on van wat?
Je hebt een wireguard server nodig in je Lan en een wireguard client op je device net als alle VPN oplossingen (er zijn er nog een paar meer).

[GekkePrutser]

keroner schreef op zondag 22 januari 2023 @ 21:52:
Ik ben recent met Home Assistant gestart en wil mij Home Assistant natuurlijk ook vanaf buitenaf kunnen benaderen.
De meest makkelijke manier hiervoor is om in mijn router via port forwarding dit toe te wijzen.
Ik lees echter veel dat dit onveilig is, maar kan iemand uitleggen waarom dit zo onveilig is?
Als ik achter mijn WAN IP adres een volledig willekeurige port (288, ik roep maar wat) laat forwarden naar mijn Home Assistant interne IP/port en de toegang tot Home Assistant ook nog om credentials vraagt lijkt mij (maar hier schiet mijn kennis waarschijnlijk tekort) dit toch behoorlijk veilig?

Voor een aanvaller is de volgende info nodig lijkt mij,
- WAN IP (makkelijk te achterhalen als ze eenmaal weten wie ik ben)
- Geforwarde port (er zijn geloof ik 65.535 porten beschikbaar, dus niet voor de hand liggend te vinden)
- Mijn Home Assistant credentials (ik gebruik altijd strong passwords)

Het lijkt mij dan ook ontzettend veilig om bovenstaande situatie op te zetten, maar toch wordt dit afgeraden.
Er wordt echter nergens duidelijk uitgelegd waarom dit nou zo onveilig is.
Ik wil niet eigenwijs bovenstaande doordrukken/verdedigen. Dit is gewoon een vraag om mijn kennis uit te breiden. Uiteraard zal ik in de DNS/VPN optie duiken als dat aangeraden wordt.

Alvast bedankt om deze netwerk leek wat wijzer te maken......

Poorten zijn gewoon te scannen. En als iemand je home assistant hackt door bijvoorbeeld een vulnerability in de code die je nog niet geupdate hebt, dan zitten ze ook gelijk in je thuis netwerk. Daarom worden bij bedrijven internet servers altijd in een DMZ geplaatst (maar nog liever in de cloud). Met tools als shodan zijn het vinden van kwetsbare instances een peuleschil.

Ik zou ook altijd VPN doen, doe ik zelf ook trouwens.

[laurens0619]

@donny007
Dat lijkt een beetje op de azure application proxy die ik aanhaalde.
Werkt de home assistant app (bv iOS) ook hiermee samen? Of werkt het alleen in de browser

[Ben(V)]

Het is eigenlijk gewoon een VPN maar dan via cloudflare.
Je moet ergens op je lan een cloudflare server hebben draaien.
Het verschil is dat je gewoon met je webbrowser naar Cloudflare gaat en geen VPN client op je device nodig hebt.
Kortom je laat de beveiliging aan een bedrijf over met een(nu nog) gratis abbo bij Cloudflare.

De server kun je hier downloaden.
https://developers.cloudf...l-and-setup/installation/

[ Voor 11% gewijzigd door Ben(V) op 23-01-2023 11:05 ]

[Thijsmans]

Ben(V) schreef op maandag 23 januari 2023 @ 10:54:
Add-on van wat?

Home Assistant natuurlijk, gezien het TS daarom te doen is...

[Ben(V)]

Tja dan zou ik toch een gewone wireguard installeren, dan kun je de rest van je devices en applicaties in je netwerk ook bereiken.
Maar dat is natuurlijk ieder zijn eigen keus.

[Freekers]

Ben(V) schreef op maandag 23 januari 2023 @ 10:03:
@Freekers
Nee dat is de laatste jaren vaker ontdekt in grote pakketten.
Dat is heel wat anders

Inderdaad, ontdekt en dus is voorgekomen

Ben(V) schreef op maandag 23 januari 2023 @ 09:31:
Tevens kan zo'n applicatie wel eens down gaan en dan is er niets meer wat die poort beschermt.

Maar als de applicatie down is, dan luistert er toch niets meer op die poort? En dan kun je geen connectie meer op zetten, of zie ik dat verkeerd?

donny007 schreef op maandag 23 januari 2023 @ 10:54:
Je kunt ook kiezen voor een ZTNA (Zero-Trust Network Access) oplossing, zelf gebruik ik bijvoorbeeld Cloudflare Tunnels/Access om Home Assistant op een veilige manier te ontsluiten.

Het is in feite een reverse-proxy in de cloud met een extra autorisatielaag en web application firewall, de verbinding tussen de proxy-provider en Home Assistant loopt via een beveiligde tunnel zonder dat daarvoor poorten hoeven te worden geopend.

[Afbeelding]

https://developers.cloudf...onnect-apps/#how-it-works

Interessant. Hoe verhoudt zich dit tot een 'simpele' DNS entry in Cloudflare waarbij je alle verkeer via Cloudflare routeert, ofwel het 'oranje' wolkje aan hebt staan? Wat ik zo snel kan bedenken is dat men dan niet stiekem buiten de tunnel om kan gaan als ze op een of andere manier het IP adres van je server weten te ontfutselen, maar misschien zijn er nog meer verschillen. En ben net als @laurens0619 ook benieuwd of dit met de HASS Companion App werkt

[Thijsmans]

Ben(V) schreef op maandag 23 januari 2023 @ 11:09:
Tja dan zou ik toch een gewone wireguard installeren, dan kun je de rest van je devices en applicaties in je netwerk ook bereiken. Maar dat is natuurlijk ieder zijn eigen keus.

Dat kun je met de add-on ook; het is een gewone installatie in een docker-container. Maar dan makkelijker te installeren voor beginners. Nadeel van de docker-container binnen Home Assistant is wél dat je moeilijk in de container komt. Een QR-code genereren voor een client (in plaats van config-files exporteren) zou bijvoorbeeld wel eens lastig kunnen blijken.

[Tsurany]

Wellicht is een oplossing als Tailscale interessant? Het maakt een virtueel netwerk aan tussen je devices en routeert enkel onderling verkeer naar elkaar toe. Je hoeft dan zelfs geen poort open te zetten voor een VPN server.

[Flans]

laurens0619 schreef op maandag 23 januari 2023 @ 10:57:
@donny007
Dat lijkt een beetje op de azure application proxy die ik aanhaalde.
Werkt de home assistant app (bv iOS) ook hiermee samen? Of werkt het alleen in de browser

Veelal maak je in dit geval gebruik van een (sub)domein om de koppeling tot stand te brengen. Ik ga er vanuit dat je de host binnen de home assistant app gewoon zelf kunt instellen. In dat geval zou dit prima moeten werken.

[laurens0619]

Flans schreef op maandag 23 januari 2023 @ 11:47:
[...]


Veelal maak je in dit geval gebruik van een (sub)domein om de koppeling tot stand te brengen. Ik ga er vanuit dat je de host binnen de home assistant app gewoon zelf kunt instellen. In dat geval zou dit prima moeten werken.

Theoretisch:
Die app doet bijvoorbeeld een http POST naar https://thuisip/login.php

Als daar een cloudflare tussen zit dan geeft die webserver specifieke cloudflare code/response terug, veelal met MFA. Dat snapt die appt natuurlijk nooit.
Pas na een succesvolle signin op Cloudflare zal de server de communicatie rauw doorgeven en zal de app werken.

Dus theoretisch gezien denk ik dat die app stuq gaat

edit:
https://seantodd.co.uk/blog/putting-2fa-on-everything/

Hier zie je ook een implementatie voor nginx.
Zolang je niet authenticated bent, zal je geredirect worden naar de authenticatie pagina.

Als je een applicatie naar internet toe open zet is je attack surface:
- Nginx Webserver
- Code van HomeAssistant

Met die implementatie verander je dat naar:
- Nginx Webserver
- Code van 2fa applicatie

Die 2fa applicatie is kleiner en meer focus op security, met de juiste 2fa applicatie erop zal je applicatie dus netto veiliger worden. De 2fa uit het artikel heb ik, met 7 jaar oude code, niet direct vertrouwen in
Alleen hoogstwaarschijnlijk breek je er Fat clients mee en werkt het alleen in de browser. Met een vpn heb je daar geen last van, dan werkt alles

[ Voor 33% gewijzigd door laurens0619 op 23-01-2023 12:19 ]

[Brent]

Tsurany schreef op maandag 23 januari 2023 @ 11:39:
Wellicht is een oplossing als Tailscale interessant? Het maakt een virtueel netwerk aan tussen je devices en routeert enkel onderling verkeer naar elkaar toe. Je hoeft dan zelfs geen poort open te zetten voor een VPN server.

Tailscale et al zou de standaardoplossing moeten zijn voor al deze vragen.

[ninjazx9r98]

Of gebruik maken van Nabu Casa waarmee je de ontwikkelaars ook meteen financieel ondersteunt.

[vinniefireman]

ninjazx9r98 schreef op maandag 23 januari 2023 @ 12:26:
Of gebruik maken van Nabu Casa waarmee je de ontwikkelaars ook meteen financieel ondersteunt.

Voor zover ik begrijp is de oplossing van Nabu Casa ook niet veel meer dan een reverse proxy met een Let's encrypt certificaat. Dat is niet veiliger dan lokaal een NGINX met Let's encrypt voor HA zetten en een poort open zetten.

[Waarnemer]

Craven schreef op zondag 22 januari 2023 @ 21:57:
...Hoe goed ze hun best ook doen er kan altijd een security hole in zitten. Zelfs als je netjes patched kan het een zero day zijn.

Ja, dat geldt voor alles...

[ninjazx9r98]

vinniefireman schreef op maandag 23 januari 2023 @ 15:13:
[...]


Voor zover ik begrijp is de oplossing van Nabu Casa ook niet veel meer dan een reverse proxy met een Let's encrypt certificaat. Dat is niet veiliger dan lokaal een NGINX met Let's encrypt voor HA zetten en een poort open zetten.

Zou zomaar kunnen maar het zit ingebakken in Home Assistant, je geeft wat financiele ondersteuning voor een mooi product, je hoeft geen poorten open te zetten en je hebt er zelf geen onderhoud aan.
Zomaar wat redenen waarom ik wel gekozen heb voor Nabu Casa maar uiteraard zijn er meer wegen die naar Rome leiden.

[CAPSLOCK2000]

Drardollan schreef op maandag 23 januari 2023 @ 10:37:
Tenzij je wachtwoord gelekt is of bijvoorbeeld zoals laatst bij LastPass de wachtwoord databases ontvreemd zijn. Dan worden tijd en verversen ineens een groot punt.

Maar preventief, dus zonder reden, veranderen van unieke en sterke wachtwoorden levert geen enkele extra veiligheid op.

Niet mee eens. Je weet namelijk niet of je wachtwoorden gelekt zijn of niet. Af en toe verversen is dus best een goed idee, gewoon voor het geval je wachtwoord op straat ligt zonder dat je het zelf weet.

Er zijn wel redenen om terughoudend te zijn:
1. iedere verandering is een risico, het moment dat je een ww invoert/verandert is ook het meest riskante moment
2. als je mensen dwingt om iets te doen gaan ze zich automatisch verzetten. Geen enkele beveiliging kan compenseren voor onwil. Zo kan gedwongen veranderen negatief uitpakken.

Fundamenteel blijft het een goed idee om af en toe een nieuw wachtwoord in te stellen, maar hoe lang daar tussen moet zitten is erg afhankelijk van de omstandigheden. Er zijn dus ook sites waar "eens in de 25 jaar" goed genoeg is. Dat is effectief voor altijd.

[CAPSLOCK2000]

keroner schreef op zondag 22 januari 2023 @ 21:52:
Voor een aanvaller is de volgende info nodig lijkt mij,
- WAN IP (makkelijk te achterhalen als ze eenmaal weten wie ik ben)
- Geforwarde port (er zijn geloof ik 65.535 porten beschikbaar, dus niet voor de hand liggend te vinden)

Daar heb je niks aan, reken er maar op dat het niet meer dan 10 minuten duurt voor iemand heeft ontdekt dat er ergens een poortje is open gegaan. (Dit is geen garantie dat je ontdekt wordt, maar als beveiliging heb je er niks aan).

Het lijkt mij dan ook ontzettend veilig om bovenstaande situatie op te zetten, maar toch wordt dit afgeraden.
Er wordt echter nergens duidelijk uitgelegd waarom dit nou zo onveilig is.

In het algemeen is alle software slecht en onveilig. Veilig software schrijven is ontzettend moeilijk. Daarom gaan we er in de security voor het gemak maar van uit dat alles lek is als het niet nadrukkelijk gebouwd is met het doel om veilig te zijn.

Het is leuk dat de software zelf een receptionist heeft die gasten ontvangt maar daar vertrouwen we liever niet op als het om veiligheid gaat. Liever zetten we zelf onze eigen bewaker voor de deur die geen ander baan heeft dan de toegang bewaken. Hoe minder die bewaker doet hoe makkelijker het is om te controleren of het goed wordt gedaan.

Alles suggesties over VPN's en proxy's moet je in dit licht zien. Het zijn gespecialiseerde toegangswegen die ontworpen zijn om makkelijk in de gaten te houden wie binnen probeert te komen. De veiligheid zit vooral in de extra aandacht die aan het onderwerp wordt gegeven en de focus op één overzichtelijke taak. Het is geen toverstok want die bestaan niet.

Het gaat dus om algemene principes. In specifieke gevallen zou het kunnen dat de receptionist beter oplet dan de bewaker.

[ Voor 10% gewijzigd door CAPSLOCK2000 op 23-01-2023 15:58 ]

[vinniefireman]

ninjazx9r98 schreef op maandag 23 januari 2023 @ 15:23:
[...]

je geeft wat financiele ondersteuning voor een mooi product, je hoeft geen poorten open te zetten en je hebt er zelf geen onderhoud aan.

Zeker goede argumenten. Maar qua veiligheid voegt het niet echt toe. Dus ik zou wel zorgen voor goede wachtwoorden, TOTP aanzetten en het aantal login pogingen limiteren met een IP ban. Al is van dat laatste onduidelijk of dit wel kan icm Home Assistant Cloud.

[laurens0619]

CAPSLOCK2000 schreef op maandag 23 januari 2023 @ 15:47:
[...]


Niet mee eens. Je weet namelijk niet of je wachtwoorden gelekt zijn of niet. Af en toe verversen is dus best een goed idee, gewoon voor het geval je wachtwoord op straat ligt zonder dat je het zelf weet.

Wachtwoorden verversen is inderdaad een goed idee, vooral bij de situatie die je aanhalde van gelekte database.

Echter de reden dat de industrie "geen goed idee" zegt is vanwege de nadelen:

Password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous password.

Als jij ervan zeker bent dat die nadelen niet van toepassing zijn op jouw situatie dan zou ik hem periodiek wijzigen. In de praktijk blijken die nadelen toch zo zwaar te wegen dat uiteindelijk niet veranderen idd beter is.

Echter in dit geval gaat het om een lokaal account in homewizard op bijvoorbeeld je pi. Als dat wachtwoord lekt, dan zijn ze of al binnen in je homeassistant server of je endpoint vanaf waar je hem gebruikt.
Of phishing, maar bij phishing doet een change ook niet want die misbruiken ze voor je passw change
Tja dan zou ik de moeite van de password change besparen

[ Voor 3% gewijzigd door laurens0619 op 23-01-2023 16:28 ]

[CAPSLOCK2000]

laurens0619 schreef op maandag 23 januari 2023 @ 16:27:
Echter in dit geval gaat het om een lokaal account in homewizard op bijvoorbeeld je pi. Als dat wachtwoord lekt, dan zijn ze of al binnen in je homeassistant server of je endpoint vanaf waar je hem gebruikt.

Het meest voorkomende wachtwoordlek is volgens mij dat mensen hun wachtwoord op de verkeerde plek invullen. Ze vergeten bv dat het nog in de copy/paste buffer zit of ze letten niet goed op welk venster de focus heeft en voor je het weet staat het wachtwoord in de groepschat of op twitter.
Een belangrijke feature van passwordmanagers is imho dan ook zorgen dat je wachtwoorden zo min mogelijk geladen zijn en niet, of zo kort mogelijk, verblijven in copy/paste buffers en clipboards. Ook heel nuttig is het als je passwordmanager er voor zorgt dat een wachtwoord alleen wordt doorgestuurd aan de site waar het bijhoort.

[Drardollan]

CAPSLOCK2000 schreef op maandag 23 januari 2023 @ 15:47:
[...]


Niet mee eens. Je weet namelijk niet of je wachtwoorden gelekt zijn of niet. Af en toe verversen is dus best een goed idee, gewoon voor het geval je wachtwoord op straat ligt zonder dat je het zelf weet.

Er zijn wel redenen om terughoudend te zijn:
1. iedere verandering is een risico, het moment dat je een ww invoert/verandert is ook het meest riskante moment
2. als je mensen dwingt om iets te doen gaan ze zich automatisch verzetten. Geen enkele beveiliging kan compenseren voor onwil. Zo kan gedwongen veranderen negatief uitpakken.

Fundamenteel blijft het een goed idee om af en toe een nieuw wachtwoord in te stellen, maar hoe lang daar tussen moet zitten is erg afhankelijk van de omstandigheden. Er zijn dus ook sites waar "eens in de 25 jaar" goed genoeg is. Dat is effectief voor altijd.

Het is vooral het regelmatig verversen wat mij tegen de borst stuit. Dat lees ik als "elke 30 dagen" of "elke 3 maanden". En dat is waanzin. Sowieso wordt het hele wijzigen ondertussen afgeraden door grote partijen als Microsoft, dat is niet zonder reden.

Of je wachtwoord op straat ligt kan je wellicht weten door je aan te melden op een site als Have I Been Powned.

Maar of het nu wel of niet op straat ligt, als je unieke wachtwoorden hebt doet dat er niet echt toe. Je mag er vanuit gaan dat als een partij gehacked is dat deze je sowieso op de hoogte stelt / een nieuw wachtwoord vereist. Als dat niet zo is dan kan je er vanuit gaan dat de hack niet ontdekt is en nog steeds misbruikt wordt, elk nieuw wachtwoord zal dan ook (direct) uitlekken.

Alles staat of valt, in mijn ogen, met het gebruik van unieke wachtwoorden (die uiteraard sterk zijn en niet van elkaar af te leiden zijn). Vervelend als ze dan je wachtwoord van forum X achter halen, maar daar kunnen ze niets mee behalve een beetje posten. Dat merk je dan snel genoeg.

En uiteraard waar mogelijk MFA gebruiken, maar ook dat staat los van het wachtwoord wijzigen eigenlijk.

[Drardollan]

CAPSLOCK2000 schreef op maandag 23 januari 2023 @ 16:42:
[...]


Het meest voorkomende wachtwoordlek is volgens mij dat mensen hun wachtwoord op de verkeerde plek invullen. Ze vergeten bv dat het nog in de copy/paste buffer zit of ze letten niet goed op welk venster de focus heeft en voor je het weet staat het wachtwoord in de groepschat of op twitter.
Een belangrijke feature van passwordmanagers is imho dan ook zorgen dat je wachtwoorden zo min mogelijk geladen zijn en niet, of zo kort mogelijk, verblijven in copy/paste buffers en clipboards. Ook heel nuttig is het als je passwordmanager er voor zorgt dat een wachtwoord alleen wordt doorgestuurd aan de site waar het bijhoort.

Niet het invullen (copy/paste) naar een groepschat of Twitter is een probleem, het invullen in allerlei Phising Websites is een probleem. Daar heeft de aanvaller namelijk ook gelijk veel meer info zoals de kennis welke website het wachtwoord voor is en de gebruikersnaam.

Ook is het gebruik van simpele wachtwoorden (Welkom123) een probleem.

Waarmee ik overigens zeker niet zeg dat het goed is dat password managers een groot deel van de risico's wegnemen door wachtwoorden enkel op de juiste sites in te vullen. Dat is absoluut een groot voordeel en zorgt absoluut voor meer veiligheid.

[CAPSLOCK2000]

Drardollan schreef op maandag 23 januari 2023 @ 17:08:

Het is vooral het regelmatig verversen wat mij tegen de borst stuit. Dat lees ik als "elke 30 dagen" of "elke 3 maanden". En dat is waanzin. Sowieso wordt het hele wijzigen ondertussen afgeraden door grote partijen als Microsoft, dat is niet zonder reden.

Nee, dat is niet wat er in het advies staat. Het advies is om mensen niet te /dwingen/ om hun wachtwoord regelmatig te veranderen. Het advies is om mensen zoveel mogelijk zelf te laten kiezen of/wanneer ze hun wachtwoord veranderen.

Of je wachtwoord op straat ligt kan je wellicht weten door je aan te melden op een site als Have I Been Powned.

Tegen de tijd dat Have I Been Powned het weet ben je te laat en HIBP kent niet meer dan een fractie van alle gelekte data. Het helpt maar het is niet goed genoeg om er op te vertrouwen.

Maar of het nu wel of niet op straat ligt, als je unieke wachtwoorden hebt doet dat er niet echt toe. Je mag er vanuit gaan dat als een partij gehacked is dat deze je sowieso op de hoogte stelt / een nieuw wachtwoord vereist.

Nee. In 9/10 gevallen is de eerste reactie dat ze proberen het onder de pet te houden. Het is deel van mijn werk om uit te leggen dat het niet zo hoort als ze bij komen vragen hoe ze het stilletjes moeten oplossen.
edit met "ze" bedoel ik typisch iemand van middle management die zowel de techniek als de wet niet echt snapt en vooral op grond van de eigen onderbuik beslist. De techneuten en de juristen zijn meestal juist voor de open aanpak.

Als dat niet zo is dan kan je er vanuit gaan dat de hack niet ontdekt is en nog steeds misbruikt wordt, elk nieuw wachtwoord zal dan ook (direct) uitlekken.

Vergeet je dat veel wachtwoorden lekken via phishing en domme menselijke foutjes. De website waarvan het wachtwoord is uitgelekt weet daar waarschijnlijk niks van. Wachtwoorden veranderen doe je om dat op te vangen. Of het de moeite waard is ligt er nogal aan en is vooral een persoonlijke afweging.

Niettemin blijft het een goed principe om wachtwoorden af en toe te vervangen.

[ Voor 5% gewijzigd door CAPSLOCK2000 op 23-01-2023 17:30 ]

[laurens0619]

Het gaat om een modern beleid te voeren:
- kijken naar kwaliteit ipv complexiteit (Welkom01! Is qua complexiteit goed, niet qua kwaliteit)
- gelekte wachtwoorden detecteren en resetten
Dan pas:
- passw change interval loslaten

[ Voor 26% gewijzigd door laurens0619 op 23-01-2023 18:31 ]

[degrashopper]

En ben net als @laurens0619 ook benieuwd of dit met de HASS Companion App werkt

ik heb mijn ha ontsloten via cloudflare en een lokale proxy. Cloudflare proxy -> traefik proxy -> HA. Daarbij werkt HA perfect met de companion app. Ik zit er nog aan te denken om traefik uit te rusten met crowdsec waarmee je ongewenste activiteiten nog kunt blokken.

[ Voor 4% gewijzigd door degrashopper op 23-01-2023 21:13 ]

[dhrto]

Misschien zit ik er wel naast, maar naar mijn idee hoeft reserve proxy niet minder veilig te zijn dan VPN. Afhankelijk van je netwerk inrichting kan reverse proxy misschien wel veiliger zijn in mijn beleving. Dat is mijn gedachte, ik hoor graag als ik ergens te kort door de bocht ga:

- Met een reverse proxy kan in principe geen directe verbinding worden gemaakt met HA op je thuis netwerk. Alle verkeer tussen client <> HA gaat via de proxy. De proxy is direct toegankelijk van buiten, maar kan je zo instellen dat deze binnen je eigen netwerk alleen verbinding kan maken met HA op een bepaalde poort, middels een firewall tussen de proxy en HA. Als er dan ingebroken wordt op de proxy, kan men niet verder je netwerk in, want firewall.

- Met een VPN ben je over het algemeen ingelogd als 't ware binnen je eigen netwerk en kun je bij je hele netwerk. Je komt als het ware achter je firewall binnen. Dit omdat je VPN vaak als overkoepelend iets gebruikt voor netwerk toegang en niet per applicatie een aparte VPN tunnel zal opzetten. Dus mocht je VPN gecompromitteerd zijn, dan heb je een veel groter probleem dan dat je reverse proxy gecompromitteerd is.

Full disclore: ik heb HA toegankelijk van buiten gemaakt via een reverse proxy en 2FA aan staan voor alle gebruikers (+ban na max. aantal verkeerde inlogpogingen). VPN is een stap teveel 'gedoe' als je op je mobiel zit en geen persistent VPN wilt.

[laurens0619]

@dhrto
Nee een vpn is echt veiliger. Dat stukje software is namelijk volledig ontworpen en getest om "aan het internet te hangen".
Je proxy forward ieder request, dus als er een fout zit in HA.php, dan forward de proxy die gewoon en heb je de server compromised waar HA op zit.
Het is ook aannemelijker dat er een fout in HA zit dan in nginx, een hacker zal dus eerder je HA machine comrpomisen dan nginx.
Behalve als je dus een setup gebruikt zoals bijvoorbeeld Cloudflaure/Azure App proxy doet. Dan gaat je argument denk ik wel op

[dhrto]

Ik volg de redenatie dat VPN ontworpen is om veiliger te zijn, maar als ze eenmaal binnen zijn via VPN, heb je naar mijn idee nog altijd een groter probleem.

HA zou dan wel 'makkelijker' zijn om op in te breken, maar als ze inbreken op HA, kunnen ze bij mij niet verder het netwerk in, omdat dit op een afgescheiden netwerk segment draait.

Cloudflaure/Azure App proxy is uiteindelijk toch ook maar gewoon een proxy? Alleen voor zover ik begrijp, loopt de verbinding tussen proxy <> HA dan via een VPN-tunnel, die verder transparant is. Hiermee is het alsof de proxy op je eigen netwerk draait (zelfs zonder firewall ertussen?). Hoe is dat anders dan nginx dan?

[ Voor 19% gewijzigd door dhrto op 23-01-2023 23:21 ]

[laurens0619]

@dhrto
Ja/nee. Jij hebt daar bewust over nagedacht om je HA te segmenteren. Dat kan je ook met een VPN doen, dat het account alleen maar bij het ip van HA mag wat in segment staat. En stel je weet VPN te compromisen, dan heb je "slechts" toegang tot het netwerk. Als je devices goed ingericht zijn dan kan een aanvaller dan nog niet zoveel. Hebben ze toegang tot het systeem waar HA op draait dan heb je en netwerk access en system access.

Azure app proxy:
Het verschil zit hem erin dat je unauthenticated nergens tegenaan mag praten, behalve tegen een stukje login code van Azure App proxy. Stel je login-homeassistant.php is vulnerable, dan kan je daar als aanvaller alleen tegenaan praten zodra je een succesvolle authenticatie hebt van Azure App proxy.
Met een "rauwe" reverse proxy wordt alles doorgezet, en kan je dus gewoon tegen login-homeassistant.php praten, ook al ben je niet ingelogd;

Zie plaatje onder, met een reguliere proxy mag je meteen vanaf stap 3 communiceren. Met Azure AD app proxy moet je eerst 1 en 2 succesvol weten af te ronden

[ Voor 28% gewijzigd door laurens0619 op 23-01-2023 23:38 ]

[dhrto]

Dank voor de toelichting @laurens0619!

Je creëert dus een extra check vooraf, voordat je uberhaupt mag praten met HA via de reverse proxy, duidelijk.

Een VPN tunnel zou je idd ook zodanig kunnen inrichten dat deze alleen bij HA mag uitkomen. Dit is dan wel vrij onpraktisch, omdat je voor elke server/app dan van VPN tunnel zou moeten switchen op een mobiel. Vanaf een desktop zou je prima met verschillende tunnels verbonden kunnen zijn, alleen is het volgens mij niet goed te doen op een mobiel (in elk geval zie ik de optie niet zo snel in de vanilla Android settings).

[degrashopper]

@dhrto als je dan vervolgens nog crowdsec toevoegd aan je reverse proxy kan deze ook nog checken op ongeoorloofde aanvragen (hack pogingen) en de aanvrager doorverwijzen naar een "bouncer" ipv naar de ha service. crowdsec kan zelfs al op basis van een blacklisted ip uit het crowdsec register de aanvraag niet doorzetten naar ha.

[keroner]

Ik heb met veel interesse meegelezen en moet zeggen dat ik de basis snap, maar sommige reacties (waarschijnlijk van beveiligingsspecialisten ) gaan m'n pet te boven gaan.

Ik draai hier op een Asus router en heb begrepen dat ik daar een openvpn server (client voor anonimiteit is niet mijn doel) op kan draaien. Ik probeer dit nu al een aantal uurtjes op te zetten, maar helaas nog zonder succes.
Hoewel ik de openvpn server configureer blijft mijn geforwarde poort via 4g benaderbaar zonder dat ik in de client een vpn tunnel heb opgebouwd.

Ik heb dus de openvpn server volgens screenshot geconfigureerd en een login en password gegeven.



Vervolgens heb ik via port forwarding externe port 1194 doorverwezen naar intern het IP adres en de port van mijn NAS.
Je zou zeggen dat ik deze nu vanaf de client zonder het opzetten van een tunnel met certificaat niet kan benaderen, maar dit kan dus wel.
Kan iemand misschien uitleggen wat ik hier fout doe?

Thanks!!

[ninjazx9r98]

@keroner
Haal die port forward er eens af en probeer het dan nog een keer.

[Neus]

Of gebruik Tailscale zodat je snel een veilige VPN hebt zonder dat iemand anders daar bij kan, zonder port-forwarding etc. En indien nodig kan je je Tailscale machine als exit node gebruiken zodat ook de rest van je netwerk voor jou beschikbaar is.

[Ben(V)]

@keroner
Als je een VPN server opzet in die router moet je natuurlijk geen portforwarding meer maken.
Je VPN client connect met de VPN server op je Asus en die VPN server geeft de VPN client dan toegang tot je hele Lan.

Dus geen portforwarding meer.

[keroner]

Ok. Ik heb nu de portforward verwijderd. Kan inmiddels ook via de openvpn client software een tunnel opzetten.
M'n server geeft dan ook aan dat er verbinding is. Maar de vraag is... en dan
Ik ga vervolgens naar mijn externe IP adres gevolgd door :5000 maar krijg dan de melding dat de site niet bereikbaar is (als ik een portforward aanmaak naar poort 5000 kom ik er wel in, dus de NAS is correct ingesteld voor toegang).

Ik begrijp het toch goed dat je na het opzetten van de tunnel gewoon je externe IP adres gevolgd door de interne port kunt gebruiken?

Sorry als ik domme vragen stel, maar doe dit voor het eerst en vind het verdomde lastig....

[aegis]

de openvpn server zorgt ervoor dat je verbonden bent met je lan netwerk alsof je gewoon direct een netwerk kabel van jou computer in je router/switch hebt geprikt dus vanaf dat moment zou ook op 192.168.1.xxx:8123 of http://homeassistant.local:8123

Dus je hoeft niks te portforwarden of iets dergelijks als je vpn client op je laptop/mobile verbonden is met je vpn server op je router en jij zit lekker in op het terras kun home-assistant gebruiken.

[keroner]

aegis schreef op donderdag 26 januari 2023 @ 22:27:
de openvpn server zorgt ervoor dat je verbonden bent met je lan netwerk alsof je gewoon direct een netwerk kabel van jou computer in je router/switch hebt geprikt dus vanaf dat moment zou ook op 192.168.1.xxx:8123 of http://homeassistant.local:8123

Dus je hoeft niks te portforwarden of iets dergelijks als je vpn client op je laptop/mobile verbonden is met je vpn server op je router en jij zit lekker in op het terras kun home-assistant gebruiken.

Nah ik voel me echt een appel. Soms zijn simpele dingen zo moeilijk als je ze niet weet......
Thanks. Heb het nu eindelijk draaien. Nu kijken hoe een client op mobiel werkt.