Eigen router zonder modem only

[kimme]

Hi all,

Aangezien mijn huidig WiFi netwerk rampzalig is en ik voor sommige toepassingen op router niveau wat meer controle nodig heb, heb ik besloten een eigen router met extra aps te zetten.

Nu las ik dat een echte modem only geen optie meer is en enkel kan gewerkt worden met mac passtrough op de erouter.

Om heel wat gedoe te vermijden dacht ik dan eerder om mijn huidige hgw (meest recente WiFi model) te behouden, hier WiFi uit te schakelen en het subnet te veranderen naar .0.1. Daarachter dan de router op .1.1 die alles stuurt.

Is dit een optie of ga ik sowieso tegen problemen aanlopen hiermee en zoja, dewelke.

Thanks!

[dbiphoner]

Gewoon e-router vragen in telenetshop, werkt zoals het hoort!

[kimme]

Gewoon e-router vragen in telenetshop, werkt zoals het hoort!

Dat is niet echt een antwoord op mijn vraag hè

[Sylvester]

Jawel hoor, dat is wel het antwoord. Misschien was hij wat kort, maar hij wilde zeggen dat het altijd beter is om een nieuwe e-modem te zetten en dan uw eigen router met eigen WiFi. Is makkelijker dan uw suggestie en geen problemen nadien.
Uw suggestie is als vloeken in de kerk, en het blijft niet bij vloeken als je me begrijpt!

[kimme]

Jawel hoor, dat is wel het antwoord. Misschien was hij wat kort, maar hij wilde zeggen dat het altijd beter is om een nieuwe e-modem te zetten en dan uw eigen router met eigen WiFi. Is makkelijker dan uw suggestie en geen problemen nadien.
Uw suggestie is als vloeken in de kerk, en het blijft niet bij vloeken als je me begrijpt!

Dat kan gerust zijn maar mijn vraag is waarom dit beter zou zijn.
Voor hetzelfde geld is het voor mijn toepassing totaal onbelangrijk.
Ik las ook dat naar ipv6 er nog issues waren bij die emodem dus ook die oplossing blijkt niet 100% te zijn.

[Sylvester]

Dubbele NAT in uw situatie

[silentkiller]

op IPv4 niveau zit je met een dubbele NAT inderdaad.
Zelf heb ik dit al ongeveer een jaar draaien (WiFi uit op telenet HGW, daarachter mijn eigen router). Op de telenet site heb ik mijn 2e router als 'DMZ' geconfigureerd.

IPv4: werkt perfect, ook voor inkomende connecties
IPv6: werk perfect

Ik heb alleen issues als ik een DNS adres gebruik dat verwijst naar mijn WAN ip adres, dat krijg ik intern niet geregeld. Opgelost door lokaal in de DNS naar het lokale IP te resolven.

Reden: te lui om naar een telenet shop te gaan gezien alles zo ook werkt

[kimme]

op IPv4 niveau zit je met een dubbele NAT inderdaad.
Zelf heb ik dit al ongeveer een jaar draaien (WiFi uit op telenet HGW, daarachter mijn eigen router). Op de telenet site heb ik mijn 2e router als 'DMZ' geconfigureerd.

IPv4: werkt perfect, ook voor inkomende connecties
IPv6: werk perfect

Ik heb alleen issues als ik een DNS adres gebruik dat verwijst naar mijn WAN ip adres, dat krijg ik intern niet geregeld. Opgelost door lokaal in de DNS naar het lokale IP te resolven.

Reden: te lui om naar een telenet shop te gaan gezien alles zo ook werkt

Allright. Dan ga ik dat eerst eens zo proberen denk ik!
Aangezien ik niet echt 100% thuis ben in dit alles, kan je me een concreet voorbeeld geven van je DNS issues? Als je bvb de Google dns gebruikt op de eigen router, geeft dit dan problemen?
Bedankt!

[philippe_d]

Om heel wat gedoe te vermijden dacht ik dan eerder om mijn huidige hgw (meest recente WiFi model) te behouden, hier WiFi uit te schakelen en het subnet te veranderen naar .0.1. Daarachter dan de router op .1.1 die alles stuurt.

Is dit een optie of ga ik sowieso tegen problemen aanlopen hiermee en zoja, dewelke.

De vraag is dus of je tegen problemen gaat aanlopen hiermee en zoja, dewelke.
Antwoord is neen

• Een router achter jouw huidige HGW zal géén problemen geven. Je krijgt 2 verschillende netwerken (het netwerk achter de Telenet HGW, en het netwerk achter de eigen router: je moet er dus voor zorgen dat je niets aansluit op de Telenet HGW, alléén de kabel naar de eigen router).
• Je krijgt "dubbele NAT", maar dat hoeft geen probleem te zijn, hier zijn work-arounds voor:
  
  • enige probleem is dus een dubbele firewall die alleen een issue is voor binnenkomende traffiek (vb eigen server op lokaal netwerk)
  • hiervoor kan je nodige port-forwardings instellen op de Telenet HGW
  • of nog eenvoudiger: het WAN IP adres van je eigen router in DMZ zetten op de Telenet HGW (via "Mijn Telenet")
• IPv6 zal perfect werken op je eigen router achter de Telenet HGW (via Prefix Delegation krijgt je eigen router een /60 prefix vanuit de /56 range die toegekend is aan de Telenet HGW. Werkt onafhankelijk van de Mac IPv4 bridge.

Het (enige) voordeel van de E-router is:

• er zit geen WiFi op
• je kan via Mac Passtrough je eigen router een extern IPv4 geven, hierbij vermijdt je dubbele NAT.

Maar met dubbele NAT is perfect te leven

[EDIT]
sorry, posts gekruist (maar de boodschap was dezelfde )

[silentkiller]

Het betreft 'NAT reflection' (vind je wel wat van op het internet).

Ik heb intern een web server draaien. Als ik NIET op mijn eigen netwerk zit, kan ik perfect surfen naar webserver.domein.be (dat resolved naar mijn WAN adres van telenet op de HGW, via NAT kom ik dan op de interne web server terecht).

Als ik intern op het netwerk zit en ik surf naar webserver.domein.be, werkt dit niet. In principe zou dat moeten werken met NAT reflection, maar omdat het WAN adres op mijn eigen router eigenlijk een intern adres is van de HGW, werkt dit niet.
Dit heb ik opgelost door webserver.domein.be ook te definieren in mijn interne DNS server en daaraan het interne IP te koppelen van de web server ipv het WAN ip.

[kimme]

Ok thanks!

Het enige dat ik naar buiten stuur is de connectie met home assistant maar dat verloopt via duckdns. Dat is sowieso een aparte url tov wat ik lokaal gebruik dus ik neem aan dat dat geen probleem zal vormen dan…

[Catchthemoment]

Als me niet vergis heb ik indertijd gekozen voor een modem only, omdat je op de homegateway van Telenet geen adres reservering kan doen.

[cyberbozzo]

Indien je bepaalde VPN servers (bvb L2TP) wilt draaien kan dubbele NAT ook wel nog eens een uitdaging worden. Ook site to site IPSEC tunnels vormen soms een probleem.
Hier zijn zeker en vast oplossingen voor, maar ik probeer dubbele NAT toch wat te vermijden waar ik kan, omdat het altijd een gedoe is om dat achteraf werkend te krijgen...

Maar inderdaad: het kan perfect werken als je niet teveel eisen hebt, maar ik heb het liever niet waar ik kan (thuissituatie is natuurlijk anders en kan perfect).

[rtl]

Indien je bepaalde VPN servers (bvb L2TP) wilt draaien kan dubbele NAT ook wel nog eens een uitdaging worden. Ook site to site IPSEC tunnels vormen soms een probleem.

Waarom zou dit voor problemen zorgen? Ik heb verschillende tunnels draaien (IPSec), bovenop een VPN server en omgekeerd VPN clients die zelf uitgaand verbinding maken. 0 issues gedurende 3 jaar tijd.

[cyberbozzo]

Dan kan je me misschien nog iets bijleren. Bekijk even concreet deze screenshot:
https://www.watchguard.com/help/docs/he ... CO-GWY.jpg

(Het gaat nu niet over het merk, maar over de essentie, want die is bij elke router/firewall/VPN setup wel hetzelfde).
We spreken hier over een site to site VPN tunnel.
Zoals je ziet worden er bij remote gateway 2 IP's ingevuld. Normaal gezien in een situatie met enkele NAT moet je daar 2 keer hetzelfde IP invullen. Ik *vermoed*/*denk* dat je bij dubbele NAT het private IP van de WAN interface moet invullen in 1 van die 2 velden. Waarom is dat?
Ik heb al situaties gekend waar je een S2S IPSEC niet aan de praat krijgt met dubbele NAT, tenzij je begint te spelen met die 2 velden en in 1 van die velden het private WAN IP van de uw DMZ router invult.
Hoe komt dit?

Tevens is er bepaalde apparatuur in omloop die via een mgmt interface zelf een IPSEC tunnel kan opbouwen tussen 2 devices van hetzelfde merk. Met 1 klik kan je dan die VPN tunnel opbouwen (uw mgmt software doet dan eigenlijk de configuratie voor jou). Je mag drie keer raden welk IP hij dan pakt om uw tunnel op te bouwen: dat private IP van de WAN interface...

Met VPN heb ik al teveel miserie meegemaakt met dubbele NAT, dat ik er gewoonweg ver van weg blijf. Zonder VPN is het een heel ander verhaal en kan dit perfect werken.

[devilkin]

Bij dubbel nat ga je het externe ip moeten invullen, en zorgen dat die poort op dat ip op het juiste eindpunt geraakt. Zijnde dus je interne router. Kwestie van de juiste port forwards/dmz ips in te stellen.

[rtl]

Wat devilkin zei. Je moet altijd het public IP invullen, het private IP is onbereikbaar voor de andere partij. Indien er iets misgaat ligt het aan de port forwarding van het device dat effectief het public IP beheert. Gemakkelijkste is om je eigen router in DMZ te steken, dan wordt meteen alles geforward en heb je de minste problemen.

[philippe_d]

Wat cyberzero zei ...

Bij een site-to-site VPN over IpSec wordt de naam (of IP) van de local gateway en de remote gateway in vele gevallen ook gebruikt voor de "authentication", en dit moet aan beide zijden van de tunnel gelijk zijn.
Hiervoor gebruikt het systeem meestal zijn eigen WAN adres (of naam), en dat is bij dubbele NAT niet hetzelfde als het externe IPv4 adres

Het externe IPv4 adres moet natuurlijk gebruikt worden om de andere site te bereiken.

Met andere woorden:
de "remote gateway" IPv4 adres of naam wordt voor 2 zaken gebruikt

- het adres waarop de remote gateway bereikbaar is (dus zijn extern IP)
- het eigen adres dat de remote gateway gebruikt voor de IPSEC authentication

Vandaar dat site to site VPN's soms moeilijk instelbaar zijn bij dubbele NAT situaties. Oplossingen kunnen zijn:
- als de software van de gateway voorziet dat je beide adressen kan invullen.
- als één van beide sites achter dubbele NAT zit, dan moet deze zorgen voor de verbindings opbouw (in plaats dat beide sites mekaar proberen te bereiken).

PS - dit heeft niet zozeer te maken met bereikbaarheid (vb DMZ, port forwarding) maar met authentication!!

[devilkin]

Weer wat bijgeleerd al vaak VPN's opgezet, maar nog nooit achter een dubbele NAT.

[rtl]

Als het puur over authenticatie gaat kan je ook het devicename gebruiken natuurlijk.. Of zelfs een wildcard. Nogmaals, er is op technisch gebied geen enkele beperking door dubbele nat te gebruiken.

[cyberbozzo]

Met andere woorden:
de "remote gateway" IPv4 adres of naam wordt voor 2 zaken gebruikt

- het adres waarop de remote gateway bereikbaar is (dus zijn extern IP)
- het eigen adres dat de remote gateway gebruikt voor de IPSEC authentication

Vandaar dat site to site VPN's soms moeilijk instelbaar zijn bij dubbele NAT situaties. Oplossingen kunnen zijn:
- als de software van de gateway voorziet dat je beide adressen kan invullen.
- als één van beide sites achter dubbele NAT zit, dan moet deze zorgen voor de verbindings opbouw (in plaats dat beide sites mekaar proberen te bereiken).

PS - dit heeft niet zozeer te maken met bereikbaarheid (vb DMZ, port forwarding) maar met authentication!!

Enorm bedankt voor deze uitleg. Ik had ook al zoiets gelezen maar deze is duidelijker geformuleerd. Nu begrijp ik waarom ik dikwijls geen IPSEC's aan de praat krijg met dubbele NAT (en het dus gewoon probeer te vermijden in situaties met VPN en IPSEC en dergelijke).