Het grote IPv6 topic

[Snow_King]

Airw0lf schreef op woensdag 21 december 2022 @ 08:58:
[...]


Wat zou er op die EB ingesteld moeten kunnen worden?
Zou vervangen door de KPN-Fritzbox helpen?

Ik denk dat je er weinig in kan. Deze kan wel iets van Prefix Delegation doen, maar je hebt er gewoon weinig invloed op.

Een MikroTik router is veel flexibeler en dan kan je denk ik precies bouwen wat je wil.

[Jef61]

Ja idd, daar ben ik in mijn xs4all tijd ook op overgestapt. Combinatie Draytek Vigor 130 (als DSL modem) en daarachter een Mikrotik, dan heb je alle vrijheid.

[Airw0lf]

Jef61 schreef op woensdag 21 december 2022 @ 09:39:
[...]

Kun je een 'statische route' of 'static route' inbrengen op die EB? lijkt me van niet...?
Op een Fritzbox kan dat volgens mij wel, heb ooit een Fritzbox gehad in mijn xs4all tijd maar dat is alweer lang geleden (en misschien is het een door KPN aangepaste Fritzbox met weer beperkingen?).

Ik kan in ieder geval niks van die strekking vinden. Dus ik neem voor nu even aan dat dat niet kan.

Afgaande op de productbeschrijving is de KPN-Fritzbox niet aangepast.
Ze adviseren zelfs om er zelf een aan te schaffen...

Een andere mogelijkheid is de KPN-EB vervangen door een Asus router met Merlin firmware.
Die heb ik hier nog ongebruikt op de plank liggen.

Het idee achter de cascadering van twee (of meer) routers is begrijpen hoe zo een verdeling werkt. En wat daarvoor ingesteld moet worden.

Het idee achter de inzet van de KPN-EB is dat ik met KPN geen discussie ga krijgen als hun IP-TV ergens gaat haperen.

[ Voor 10% gewijzigd door Airw0lf op 21-12-2022 10:51 ]

[Jef61]

Airw0lf schreef op woensdag 21 december 2022 @ 10:49:
[...]
Een andere mogelijkheid is de KPN-EB vervangen door een Asus router met Merlin firmware.
Die heb ik hier nog ongebruikt op de plank liggen.

Ja haha, die heb ik ook gebruikt, heb ik ook nog ergens in de kast liggen.
Maar als je alles hebt gehad..., eindstation zal de Mikrotik router worden...

[nero355]

Airw0lf schreef op woensdag 21 december 2022 @ 08:00:
Wat wil je hiermee nou precies zeggen

Zoek eens de verschillen op tussen NAT en EIGRP/OSPF/BGP/Static Routing/enz.

Snow_King schreef op woensdag 21 december 2022 @ 08:56:
Maar mijn punt is vooral: Routing met IPv6 is niet anders dan met IPv4.

I know, maar ik vroeg me af wat men in de praktijk doet op dit moment, want helaas geen ervaring mee

Jef61 schreef op woensdag 21 december 2022 @ 10:11:
Ja idd, daar ben ik in mijn xs4all tijd ook op overgestapt. Combinatie Draytek Vigor 130 (als DSL modem) en daarachter een Mikrotik, dan heb je alle vrijheid.

In het verleden de DrayTek 2820 en 2860 gebruikt, helaas zonder IPv6 destijds, maar een xDSL lijn i.c.m. DrayTek is inderdaad puur genieten!

Airw0lf schreef op woensdag 21 december 2022 @ 10:49:
Een andere mogelijkheid is de KPN-EB vervangen door een Asus router met Merlin firmware.
Die heb ik hier nog ongebruikt op de plank liggen.

Waarom als je toch al een OPNsense DIY Router hebt

Beter dan dat wordt het gauw niet

[Airw0lf]

nero355 schreef op woensdag 21 december 2022 @ 19:06:
[...]

Zoek eens de verschillen op tussen NAT en EIGRP/OSPF/BGP/Static Routing/enz.

[...]

Waarom als je toch al een OPNsense DIY Router hebt

Beter dan dat wordt het gauw niet

Ik weet wat de verschillen zijn tussen NAT en routing.
Sorry - maar ik begrijp eigenlijk nog steeds niet wat je nou je punt is?
Misschien de aanname dat ik dat verschil niet weet?

Het belangrijkste doel van de hele oefening is wat ervaring op doen met een gelaagde vorm van IPv6 routing en daaraan gelieerde (delegeted) prefixes - vandaar de inzet van twee eigen routers (naast die van KPN).

[Snow_King]

Snow_King schreef op woensdag 7 december 2022 @ 10:32:
[...]

Ik heb nu een vraag liggen bij Microsoft of ze bij alle MS365 domeinen die wij resellen (enkele tienduizenden!) IPv6 aan willen zetten en dit by default ook kunnen doen voor alle domeinen die we hierna nog bij ze gaan registreren.

Super stom dat dit moet, bij Google staat het gewoon aan. Binnen de organisatie heb ik mensen ook gelijk moeten vertellen dat er geen klant impact is danwel firewalls die mensen moeten aanpassen. Gelijk paniek omdat het opt-in is...

Ik krijg hier van Microsoft terug: We kunnen dit niet standaar doen, je moet hier voor elke aangemaakt tenant (klant van ons) hier een apart (manueel!) verzoek voor indienen.

Dat gaan we dus niet doen. Dat wordt iets harder nog bij Microsoft drukken.

[Snow_King]

Snow_King schreef op woensdag 28 december 2022 @ 12:42:
[...]

Ik krijg hier van Microsoft terug: We kunnen dit niet standaar doen, je moet hier voor elke aangemaakt tenant (klant van ons) hier een apart (manueel!) verzoek voor indienen.

Dat gaan we dus niet doen. Dat wordt iets harder nog bij Microsoft drukken.

Ik citeer mijzelf weer om even te refereren naar dit artikel van vandaag: https://www.security.nl/p...voor+e-mail+toe+te+passen

Volgens Van Huffelen biedt de meestgebruikte e-mailprovider van de overheid geen ondersteuning van de DANE-standaard en IPv6. "De implementatie van deze standaarden is door Microsoft steeds in tijd opgeschoven. SLM en Forum Standaardisatie hebben Microsoft opnieuw gewezen op de verplichting voor de Nederlandse Overheid deze standaard toe te passen en hebben Microsoft gevraagd de huidige ultieme invoerdatum van juli 2023 hoe dan ook te garanderen", voegt ze toe.

Hup, een beetje drukken bij Microsoft!

[Streamert]

Goedenavond,

Voor mijn pfSense firewall heb ik een IPv6 vraag over de Glasnet/BlackGATE verbinding. Middels de DHCPv6 Server & RA krijgen mijn LAN interface en clients (in alleen het default VLAN) een IPv6 adres, echter mijn WAN/PPPoE interface niet.

Ik heb de settings voor WAN en LAN toegevoegd. Inmiddels al veel verschillende opties getest.

[RobertMe]

Streamert schreef op donderdag 29 december 2022 @ 20:17:
Goedenavond,

Voor mijn pfSense firewall heb ik een IPv6 vraag over de Glasnet/BlackGATE verbinding. Middels de DHCPv6 Server & RA krijgen mijn LAN interface en clients (in alleen het default VLAN) een IPv6 adres, echter mijn WAN/PPPoE interface niet.

Ik heb de settings voor WAN en LAN toegevoegd. Inmiddels al veel verschillende opties getest.

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Geen kenner, maar moet die WAN => IPv6 Configuration Type niet iets van SLAAC of zo zijn?

Waarschijnlijk moet die op de WAN gewoon een IP adres "verzinnen" binnen de RA die de provider stuurt.

Vergeet daarbij ook niet dat WAN en LAN gescheiden zijn. De router ontvangt een prefix die die adverteert aan de LAN kant (RA). Maar de WAN krijgt (/bedenkt zelf) een IP adres "binnen het LAN van alle routers van de provider". De WAN poort is dus een client vanuit de ISP gezien. Daar waar de LAN kant meer als router geldt en dus een volledig subnet / prefix krijg.

[RobertMe]

RobertMe schreef op maandag 19 december 2022 @ 21:54:
Ik ben aan het zoeken hoe IPv6 op mijn "thuisserver" / "NAS" / ... te gebruiken. Op PC / telefoon / ... werkt het al een tijd prima, nu eens het "infrastructuur" VLAN om gooien. Dit wil ik dan doen op Proxmox (host) als Debian based LXC containers.

Om iets met statische adressen te doen zonder 100% statisch te gaan (want Ziggo levert natuurlijk geen statisch adres) kom ik uit op iets met ip token set ::dead:beef/64 dev eth0. Maar om mijzelf een hoop gepruts, frustraties en downtime ver voorkomen zou ik willen weten of anderen hier dit al gedaan hebben / een voorbeeld hebben. Ik gok dat dit commando (uiteraard in aangepaste vorm) als zodanig opgenomen kan worden in /etc/network/interfaces{,.d/*}. Maar zou daar graag iets van bevestiging / voorbeeld van zien als iemand dat heeft . Waarbij ik mij ook afvraag of ik met de Debian LXCs zomaar in die file kan gaan zitten frotten. Volgens mij wordt die namelijk elke boot opnieuw gegenereerd uit de host. Maar mogelijk dat dat deel dan in /etc/network/interfaces.d/ kan en LXC zelf de /etc/network/interfaces config file genereerd.

Voor systemd-network ziet het er dan weer wel vrij eenvoudig uit incl. voorbeeld in de man page

[...]

bron
Maarja, daar heb ik niks aan, want Debian gebruikt dat niet

Om mijn eigen vraag te beantwoorden. V.w.b. Proxmox zelf (en dan ook in Debian) kom ik uit op de zeer simpele:

code:

iface vmbr0 inet6 auto
        pre-up ip token set ::30 dev vmbr0

Dit dan in /etc/network/interfaces waarbij vmbr0 dan de (hoofd) bridge is die Proxmox gebruikt. Zou dus net zo goed moeten werken Debian (etc) met de juiste interface naam (2x dan, zowel in het config blok als het commando).

V.w.b. LXC containers gok ik dat het dan beter is om dit in /etc/network/interfaces.d te zetten. Omdat /etc/network/interfaces naar mijn idee dus steeds opnieuw geconfigureerd wordt bij start van container of zo.

[Streamert]

RobertMe schreef op donderdag 29 december 2022 @ 20:29:
[...]

Geen kenner, maar moet die WAN => IPv6 Configuration Type niet iets van SLAAC of zo zijn?

Waarschijnlijk moet die op de WAN gewoon een IP adres "verzinnen" binnen de RA die de provider stuurt.

Vergeet daarbij ook niet dat WAN en LAN gescheiden zijn. De router ontvangt een prefix die die adverteert aan de LAN kant (RA). Maar de WAN krijgt (/bedenkt zelf) een IP adres "binnen het LAN van alle routers van de provider". De WAN poort is dus een client vanuit de ISP gezien. Daar waar de LAN kant meer als router geldt en dus een volledig subnet / prefix krijg.

Met de SLAAC (ook als deze gebruikmaakt van de IPv4 verbinding) werkt de tevens de IPv6 voor LAN ook niet meer. Bij Glasnet support werd mij verteld om DHCP6 te gebruiken als Configuration Type, met Prefix Delegation Size 64, maar blijkbaar ontbreekt er ergens nog een detail.

[RobertMe]

RobertMe schreef op donderdag 29 december 2022 @ 22:23:
[...]

Om mijn eigen vraag te beantwoorden. V.w.b. Proxmox zelf (en dan ook in Debian) kom ik uit op de zeer simpele:

code:

iface vmbr0 inet6 auto
        pre-up ip token set ::30 dev vmbr0

Dit dan in /etc/network/interfaces waarbij vmbr0 dan de (hoofd) bridge is die Proxmox gebruikt. Zou dus net zo goed moeten werken Debian (etc) met de juiste interface naam (2x dan, zowel in het config blok als het commando).

V.w.b. LXC containers gok ik dat het dan beter is om dit in /etc/network/interfaces.d te zetten. Omdat /etc/network/interfaces naar mijn idee dus steeds opnieuw geconfigureerd wordt bij start van container of zo.

Voor de volledigheid. Proxmox doet geen source /etc/network/interfaces.d/* toevoegen aan de gegenereerde interfaces file. Oplossing is om Proxmox helemaal niet de interfaces file te laten genereren. Dit kan door een "ignore" file aan te maken: touch /etc/network/.pve-ignore.interfaces. Dit dan uiteraard in de container. Daarna kun je in volledige vrijheid /etc/network/interfaces aanpassen.

[Snow_King]

Streamert schreef op donderdag 29 december 2022 @ 20:17:
Goedenavond,

Voor mijn pfSense firewall heb ik een IPv6 vraag over de Glasnet/BlackGATE verbinding. Middels de DHCPv6 Server & RA krijgen mijn LAN interface en clients (in alleen het default VLAN) een IPv6 adres, echter mijn WAN/PPPoE interface niet.

Ik heb de settings voor WAN en LAN toegevoegd. Inmiddels al veel verschillende opties getest.

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Houd er rekening mee dat DHCP6 voor WAN in dit geval enkel is het voor het verkijgen van een IPv6 adres op je WAN. Deze heb je in de basis niet eens nodig omdat je via Link-Local al een prefix kan krijgen via DHCPv6+PD

Let op! Dit heet dan wel beide DHCPv6, dat is het ook, maar the devil is in the details.

Via PD, Prefix Delegation, ga je via DHCPv6 om een Prefix vragen en daar gaat het mis wellicht. In je screenshots:

- Request IPv6 via IPv4 link? Die snap ik niet. Zet die eens uit
- Only request a IPv6 prefix, probeer die eens

Je krijgt dan een /48 of /56 (ligt aan de ISP) en daaruit kan je weer /64s uitdelen aan je LAN.

[nero355]

RobertMe schreef op donderdag 29 december 2022 @ 22:23:
V.w.b. LXC containers gok ik dat het dan beter is om dit in /etc/network/interfaces.d te zetten. Omdat /etc/network/interfaces naar mijn idee dus steeds opnieuw geconfigureerd wordt bij start van container of zo.

Proxmox doet dit : https://pve.proxmox.com/w...on#_apply_network_changes

Dus misschien heb je daar in het verleden last van gehad

Streamert schreef op vrijdag 30 december 2022 @ 00:03:
Met de SLAAC (ook als deze gebruikmaakt van de IPv4 verbinding) werkt de tevens de IPv6 voor LAN ook niet meer. Bij Glasnet support werd mij verteld om DHCP6 te gebruiken als Configuration Type, met Prefix Delegation Size 64, maar blijkbaar ontbreekt er ergens nog een detail.

Ik heb in het verleden begrepen dat sommige ISP's hun IPv6 via de PPPoE aanleveren en anderen weer direct via de WAN verbinding dus overleg effe met je ISP hoe zij dat precies doen

[RobertMe]

nero355 schreef op vrijdag 30 december 2022 @ 15:01:
[...]

Proxmox doet dit : https://pve.proxmox.com/w...on#_apply_network_changes

Dus misschien heb je daar in het verleden last van gehad

Dat gaat over Proxmox zelf / de host? Ik doelde met dat stukje op het gebruik van een Debian LXC. Op basis van hoe je de LXC dan configureert wordt er automatisch een /etc/network/interface gegenereerd. Maar als je dan zelf customizations wilt doen worden die weer overschreven, tenzij... je zoals in mijn latere post stond in de LXC (/het LXC filesystem) dus een /etc/network/.pve-ignore.interfaces bestand aanmaakt. Dat geldt dan als "marker" om de interfaces file niet te genereren waardoor die dus naar eigen inzicht aangepast kan worden.

[nero355]

RobertMe schreef op vrijdag 30 december 2022 @ 15:28:
Dat gaat over Proxmox zelf / de host?

Yep!

Ik doelde met dat stukje op het gebruik van een Debian LXC. Op basis van hoe je de LXC dan configureert wordt er automatisch een /etc/network/interface gegenereerd. Maar als je dan zelf customizations wilt doen worden die weer overschreven, tenzij... je zoals in mijn latere post stond in de LXC (/het LXC filesystem) dus een /etc/network/.pve-ignore.interfaces bestand aanmaakt. Dat geldt dan als "marker" om de interfaces file niet te genereren waardoor die dus naar eigen inzicht aangepast kan worden.

Dan kan je toch beter alles in de Container Settings gooien : https://pve.proxmox.com/w...ntainer#pct_configuration

Of heb je dan bepaalde toepassingen die daarmee niet compatible zijn ?

[RobertMe]

nero355 schreef op vrijdag 30 december 2022 @ 15:33:
[...]

Dan kan je toch beter alles in de Container Settings gooien : https://pve.proxmox.com/w...ntainer#pct_configuration

Of heb je dan bepaalde toepassingen die daarmee niet compatible zijn ?

Als jij mij kunt wijzen op waar ik kan vinden hoe ik een IPv6 token (/statische suffix) kan toepassen dan hoor ik het graag.

Ik was al blij dat ik die ip token set ::32 dev eth0 gevonden had. Waarbij het IPv6 adres dus een combinatie van de prefix (vanuit ISP) wordt met dus de vaste 32 op het eind. Dus als de ISP prefix 1234:5678:: levert is het IPv6 adres uiteindelijk 1234:5678::32.

[darkrain]

RobertMe schreef op vrijdag 30 december 2022 @ 15:39:
[...]

Als jij mij kunt wijzen op waar ik kan vinden hoe ik een IPv6 token (/statische suffix) kan toepassen dan hoor ik het graag.

Ik was al blij dat ik die ip token set ::32 dev eth0 gevonden had. Waarbij het IPv6 adres dus een combinatie van de prefix (vanuit ISP) wordt met dus de vaste 32 op het eind. Dus als de ISP prefix 1234:5678:: levert is het IPv6 adres uiteindelijk 1234:5678::32.

Precies dat zou ik graag willen kunnen in mijn unifi firewall... maar ik heb nog geen config gevonden die dat ook kan...

[RobertMe]

darkrain schreef op vrijdag 30 december 2022 @ 16:49:
[...]

Precies dat zou ik graag willen kunnen in mijn unifi firewall... maar ik heb nog geen config gevonden die dat ook kan...

Hoe bedoel je in de UniFi Firewall? Ik neem aan dat je dan een USG of UDM (/UDR) bedoeld? Maar ik snap ook niet goed wat je wilt bereiken. De WAN poort een vast IP geven? Want waarschijnlijk heeft die dat al. Of vaste IP adressen uitdelen aan de clients? Of vaste IP adressen op de VLANs?

* RobertMe heeft de VLANs in ieder geval een eigen private IP / subnet gegeven. Bv fd00:10::1 voor VLAN id 10 etc. Waarbij in elk VLAN op ::53 DNS te vinden is etc.

[darkrain]

RobertMe schreef op vrijdag 30 december 2022 @ 16:58:
[...]

Hoe bedoel je in de UniFi Firewall? Ik neem aan dat je dan een USG of UDM (/UDR) bedoeld? Maar ik snap ook niet goed wat je wilt bereiken. De WAN poort een vast IP geven? Want waarschijnlijk heeft die dat al. Of vaste IP adressen uitdelen aan de clients? Of vaste IP adressen op de VLANs?

* RobertMe heeft de VLANs in ieder geval een eigen private IP / subnet gegeven. Bv fd00:10::1 voor VLAN id 10 etc. Waarbij in elk VLAN op ::53 DNS te vinden is etc.

Ja DNS heeft een vast IPv6 adres (in VLAN 10) maar ja dat is wel met de hele prefix ervoor, ik wil de clients (ander VLAN) daar toegang toe geven, ook als de prefix wijzigt...

Hmm private IP range... daar moet ik eens naar kijken.

[ Voor 3% gewijzigd door darkrain op 30-12-2022 17:01 ]

[RobertMe]

darkrain schreef op vrijdag 30 december 2022 @ 17:00:
Hmm private IP range... daar moet ik eens naar kijken.

* RobertMe heeft voor de USG een config.gateway.json die deze fd00:... IPv6 adressen toekent aan de virtuele interfaces. Dit wordt vervolgens "magischerwijs" over genomen door de clients. Op mijn telefoon heb ik nu bv automatisch 5 IPv6 adressen. De link local fe80, 2x een publiek adres (op basis van de prefix van de ISP) en 2x deze fd00:10:.... En die 2x is dan het statische adres en het privacy adres.
Zelfde op de Proxmox bak. Met die set token ::30 heeft deze nu fd00:1::30 en <public prefix>::30. Zonder dat ik zelf dus echt iets ervoor heb hoeven te doen. Die set token wordt meteen over genomen.

Maar... IPv6 voor DNS heb ik al langer, en dat is wel echt een statisch ingesteld IP adres aan de client. Dus echt volledig uitgeschreven de fd00:1::53 en niet een combinatie van de router discovery(?) + een fixed token/suffix.

[darkrain]

RobertMe schreef op vrijdag 30 december 2022 @ 17:09:
[...]
Maar... IPv6 voor DNS heb ik al langer, en dat is wel echt een statisch ingesteld IP adres aan de client. Dus echt volledig uitgeschreven de fd00:1::53 en niet een combinatie van de router discovery(?) + een fixed token/suffix.

Dit is een idee wat ik zelf had moeten bedenken, geen idee waarom ik daar nog niet eerder aan dacht... Mijn UXG-pro doet helaas geen config.json meer...

[RobertMe]

Semi gerelateerd vraagje voor de kenners. Wie of wat blokkeert de private IP adressen? Want ik kan vanuit fd00:10:: wel een ping doen naar fd:1::30. Maar als het goed is kan fd00:: dan niet het internet op. Maar hoe weet, neem ik aan de router dan, wat waarheen mag? Als in: hoe weet mijn USG dat fd00:10:: op de eth1.10 interface wel naar fd00:1:: mag op eth1? Maar dit verkeer niet naar eth0 (WAN) mag? Want mijn PC in fd00:10:: zal niet weten waar met fd00:1:: heen te moeten en dit dus naar de default gateway te sturen. Maar als ik dan een niet bekend subnet gebruik (bv fd00:2::) dan mag de router dit ook niet over WAN gooien. Is dat dan puur een "deze subnets mogen nooit naar de default gateway worden gestuurd"? Of hoe is zoiets vastgelegd?

[nero355]

darkrain schreef op vrijdag 30 december 2022 @ 17:00:
Ja DNS heeft een vast IPv6 adres (in VLAN 10) maar ja dat is wel met de hele prefix ervoor, ik wil de clients (ander VLAN) daar toegang toe geven, ook als de prefix wijzigt...

Geef je DNS Server meerdere VLAN Interfaces en doe DNS per VLAN via Link-Local

RobertMe schreef op vrijdag 30 december 2022 @ 17:37:
Semi gerelateerd vraagje voor de kenners. Wie of wat blokkeert de private IP adressen? Want ik kan vanuit fd00:10:: wel een ping doen naar fd:1::30. Maar als het goed is kan fd00:: dan niet het internet op. Maar hoe weet, neem ik aan de router dan, wat waarheen mag? Als in: hoe weet mijn USG dat fd00:10:: op de eth1.10 interface wel naar fd00:1:: mag op eth1? Maar dit verkeer niet naar eth0 (WAN) mag? Want mijn PC in fd00:10:: zal niet weten waar met fd00:1:: heen te moeten en dit dus naar de default gateway te sturen. Maar als ik dan een niet bekend subnet gebruik (bv fd00:2::) dan mag de router dit ook niet over WAN gooien. Is dat dan puur een "deze subnets mogen nooit naar de default gateway worden gestuurd"? Of hoe is zoiets vastgelegd?

Zonder NAT zal je IPv4 192.168.x.x/172.16.x.x/10.x.x.x adres ook niet richting het Internet kunnen dus ik denk dat puur het protocol alles bepaalt

[Snow_King]

RobertMe schreef op vrijdag 30 december 2022 @ 17:37:
Semi gerelateerd vraagje voor de kenners. Wie of wat blokkeert de private IP adressen? Want ik kan vanuit fd00:10:: wel een ping doen naar fd:1::30. Maar als het goed is kan fd00:: dan niet het internet op. Maar hoe weet, neem ik aan de router dan, wat waarheen mag? Als in: hoe weet mijn USG dat fd00:10:: op de eth1.10 interface wel naar fd00:1:: mag op eth1? Maar dit verkeer niet naar eth0 (WAN) mag? Want mijn PC in fd00:10:: zal niet weten waar met fd00:1:: heen te moeten en dit dus naar de default gateway te sturen. Maar als ik dan een niet bekend subnet gebruik (bv fd00:2::) dan mag de router dit ook niet over WAN gooien. Is dat dan puur een "deze subnets mogen nooit naar de default gateway worden gestuurd"? Of hoe is zoiets vastgelegd?

Mits jouw router aan source filtering doet, zal dit gewoon naar de default gateway gaan.

Daarna gaat het naar je ISP en daar komt het in een router. Als deze geen filtering doet gaat het door totdat het een full table router tegen komt.

Deze router heeft geen default gateway maar enkel de echte internet routes heeft. Die kent dan geen route en dropped het pakket.

[RobertMe]

Snow_King schreef op vrijdag 30 december 2022 @ 19:08:
[...]

Mits jouw router aan source filtering doet, zal dit gewoon naar de default gateway gaan.

Daarna gaat het naar je ISP en daar komt het in een router. Als deze geen filtering doet gaat het door totdat het een full table router tegen komt.

Deze router heeft geen default gateway maar enkel de echte internet routes heeft. Die kent dan geen route en dropped het pakket.

Dus eigenlijk is er weinig "private" aan? En bij verkeerde configuratie kun je dus zomaar verkeer het internet op gooien? (Wat dan uiteindelijk geen bestemming bereikt)

Best apart dan eigenlijk. En wellicht daarvoor maar een mooie "WAN_OUT" filter maken in mijn router. Op dan voor het volledige subnet (fc00::/7 wat ik nu zo snel vind?). "destination: fc00::/7 => DROP".

[RobertMe]

nero355 schreef op vrijdag 30 december 2022 @ 19:05:
[...]

Zonder NAT zal je IPv4 192.168.x.x/172.16.x.x/10.x.x.x adres ook niet richting het Internet kunnen dus ik denk dat puur het protocol alles bepaalt

Lijkt mij niet te vergelijken. De router heeft voor IPv4 een default route om verkeer over de WAN poort naar buiten te gooien en een firewall regel om masquerade toe te passen op verkeer op de WAN poort. Daardoor communiceer je dus sowieso al niet met private source naar buiten toe omdat altijd masquerading wordt toegepast. Daar waar je bij IPv6 wel rechtstreeks naar buiten toe babbelt. En bij IPv6 heb je natuurlijk al de link local adressen die sowieso one way or another hard netwerk gebonden zijn en nooit gerouteerd mogen worden (AFAIK).

[Snow_King]

RobertMe schreef op vrijdag 30 december 2022 @ 19:28:
[...]

Dus eigenlijk is er weinig "private" aan? En bij verkeerde configuratie kun je dus zomaar verkeer het internet op gooien? (Wat dan uiteindelijk geen bestemming bereikt)

Best apart dan eigenlijk. En wellicht daarvoor maar een mooie "WAN_OUT" filter maken in mijn router. Op dan voor het volledige subnet (fc00::/7 wat ik nu zo snel vind?). "destination: fc00::/7 => DROP".

Correct. Zo zie je voldoende 10.0.0.0/8 packets op routers voorbij komen.

Ook met Ipv4 gebeurd dit.

Je kan op je WAN out filter filteren dat alles wat niet matched aan 2000::/3 weg mag.

Alle publieke IPv6 space valt binnen 2000::/3

[Roetzen]

RobertMe schreef op vrijdag 30 december 2022 @ 19:28:
[...]

Dus eigenlijk is er weinig "private" aan?

Aanvankelijk waren die adressen gelabeld als "site local" Niet voor wereldwijd gebruik maar breder dan binnen één subnet. Later werd het omgedoopt tot "Unique Local Address". Het was niet duidelijk wat er onder een "site" moest vallen.

Die ULAs kunnen dus verder reiken dan het eigen subnet, Denk bijvoorbeeld aan een bedrijf met meerdere vestigingen. Ja moet dan op een of andere manier routeren tussen die vestigingen. Niet aan mij vragen hoe dat moet, ik weet het niet. Maar ik snap het idee.

En bij verkeerde configuratie kun je dus zomaar verkeer het internet op gooien? (Wat dan uiteindelijk geen bestemming bereikt)

Je moet dus goed weten wat je doet...

[Airw0lf]

RobertMe schreef op vrijdag 30 december 2022 @ 17:37:
Semi gerelateerd vraagje voor de kenners. Wie of wat blokkeert de private IP adressen? Want ik kan vanuit fd00:10:: wel een ping doen naar fd:1::30. Maar als het goed is kan fd00:: dan niet het internet op. Maar hoe weet, neem ik aan de router dan, wat waarheen mag? Als in: hoe weet mijn USG dat fd00:10:: op de eth1.10 interface wel naar fd00:1:: mag op eth1? Maar dit verkeer niet naar eth0 (WAN) mag? Want mijn PC in fd00:10:: zal niet weten waar met fd00:1:: heen te moeten en dit dus naar de default gateway te sturen. Maar als ik dan een niet bekend subnet gebruik (bv fd00:2::) dan mag de router dit ook niet over WAN gooien. Is dat dan puur een "deze subnets mogen nooit naar de default gateway worden gestuurd"? Of hoe is zoiets vastgelegd?

Dat gebeurd in twee stappen.

Stap-1 (“Als in: hoe weet mijn USG dat fd00:10:: op de eth1.10 interface wel naar fd00:1:: mag op eth1”):

Dit zijn twee direct-connected interfaces elk met een private IPv6-adres. Via IP-forwarding gaat je USG de netwerk pakketjes van de een naar de ander kunnen doorsturen. Zolang er verder geen routing protocollen meelopen zullen deze twee private subnetten verder nergens bekend zijn. Waardoor elke andere poging zal stranden met zoiets als “unknown destination”.

Zo ook als er een netwerk pakketje met een vreemde, onbekende subnet-bestemming het netwerk opgegooid wordt: zolang dat subnet niet direct-connected is en verder nergens in een routing tabel staat gaat er altijd zoiets als “unknown destination” terug naar de afzender.

Daar hoef je in de firewall(s) eigenlijk niks aparts voor te regelen – is inherent aan de werking van ip-forwarding en routing protocollen. Het is daarom zaak dat je selectief bent in het gebruik van deze twee – vooral de routing protocollen en het bekend maken van subnetten (IPv4 en IPv6).

Stap-2 (Is dat dan puur een "deze subnets mogen nooit naar de default gateway worden gestuurd"? Of hoe is zoiets vastgelegd?):

Het grootste deel wordt inderdaad afgevangen over de as van selectief gebruik van IP-forwarding en routing protocollen: via routing ACL's wordt de inhoud van routing tabellen tot een minimum beperkt. Bij grote(re) netwerken is het daarom meer dan handig om vooraf per locatie een verkeersmatrix op te stellen. Op basis van een dergelijke matrix worden de firewalls en routers ingeregeld. Dit gebeurd meestal op basis van templates; bijvoorbeeld met zoiets als ZeroTier (mocht je hier zelf eens mee aan de slag willen).

Voor de zekerheid: daarnaast zou je op de WAN-interface(s) met een directe internet verbinding een filter kunnen instellen voor alle IPv4 private subnetten uit de RFC1918-reeks. Bij IPv6 is dit RFC4139 – ook wel aangeduid met de IANA prefix FC00::/7. De genoemde FD00::/8 adressen vallen hier dan ook onder.

[Airw0lf]

RobertMe schreef op vrijdag 30 december 2022 @ 19:35:
[...]

Lijkt mij niet te vergelijken. De router heeft voor IPv4 een default route om verkeer over de WAN poort naar buiten te gooien en een firewall regel om masquerade toe te passen op verkeer op de WAN poort. Daardoor communiceer je dus sowieso al niet met private source naar buiten toe omdat altijd masquerading wordt toegepast. Daar waar je bij IPv6 wel rechtstreeks naar buiten toe babbelt. En bij IPv6 heb je natuurlijk al de link local adressen die sowieso one way or another hard netwerk gebonden zijn en nooit gerouteerd mogen worden (AFAIK).

Voor je USG klopt dat wellicht. Maar er zijn ook routers/firewalls die werken met NAT rules en Access rules. Waarbij je met NAT rules de verschillende soorten translaties regelt. En met Access rules bepaald onder welke voorwaarden die netwerk pakketjes het internet op mogen.

Als je dan het NAT-ing stuk vergeet, dan kan het inderdaad gebeuren dat netwerk pakketjes met private IPv4 adressen het Internet op gegooid worden.

Maar om dat voor elkaar te krijgen moet je het toch wel redelijk bont maken...

[ Voor 10% gewijzigd door Airw0lf op 30-12-2022 23:39 ]

[RobertMe]

Als voortborduursel van mijn eerdere vraag m.b.t. private IPs en routering / blokkades daarvan, en de daarop volgende antwoorden van @Snow_King en @Airw0lf. Denk ik te simpel door dit te testen met een traceroute? fd00:6::1 gaat naar fd00:10:1 (= de USG / default gateway) en is dan dood. Verzin ik een willekeurig publiek adres (2000::1) zie ik 3 hops (2x Ziggo, 1x core.as<...>.net die ook onder Ziggo valt?). Oftewel: USG gooit het private verkeer al niet het internet op, doordat die het (lokaal) niet kan routeren en het niet het internet op mag / ...? Terwijl dat adres in de publieke scope wel het internet op wordt gestuurd, en daar uiteindelijk "dood gaat".

Edit:
Ik schrijf wel 2x Ziggo, maar een van beiden zal gegarandeerd het IPv6 adres zijn van de virtuele interface van het VLAN (eth1.10 dus). Wat ook wel meteen duidelijk had moeten zijn gezien de <...>.dynamic.<...>.ziggo.nl. Dat zullen ze vast niet gebruiken op de core infrastructuur

[ Voor 17% gewijzigd door RobertMe op 30-12-2022 23:41 ]

[Airw0lf]

RobertMe schreef op vrijdag 30 december 2022 @ 23:35:

Als voortborduursel van mijn eerdere vraag m.b.t. private IPs en routering / blokkades daarvan, en de daarop volgende antwoorden van @Snow_King en @Airw0lf. Denk ik te simpel door dit te testen met een traceroute? fd00:6::1 gaat naar fd00:10:1 (= de USG / default gateway) en is dan dood. Verzin ik een willekeurig publiek adres (2000::1) zie ik 3 hops (2x Ziggo, 1x core.as<...>.net die ook onder Ziggo valt?). Oftewel: USG gooit het private verkeer al niet het internet op, doordat die het (lokaal) niet kan routeren en het niet het internet op mag / ...? Terwijl dat adres in de publieke scope wel het internet op wordt gestuurd, en daar uiteindelijk "dood gaat".

Een traceroute is daar inderdaad geschikt voor. Hoewel ik wel nieuwsgierig ben naar de resultaten van een tcptrace naar poort 80 en/of 443... Dit omdat traceroute via ICMP loopt. En dat wil nog wel eens geblokkeerd worden.

Dat tcptrace kun je hier ophalen: http://www.tcptrace.org/download.shtml

[Hipska]

@RobertMe gaat er ook verkeerdelijk van uit dat wanneer traceroute geen antwoord krijgt, het pakket dan ook niet verstuurd werd.

Dat is niet gezegd, je weet nu alleen dat de volgende hop(s) geen route hebben/weten om het antwoord terug te sturen.

[RobertMe]

Hipska schreef op zaterdag 31 december 2022 @ 09:17:
@RobertMe gaat er ook verkeerdelijk van uit dat wanneer traceroute geen antwoord krijgt, het pakket dan ook niet verstuurd werd.

Dat is niet gezegd, je weet nu alleen dat de volgende hop(s) geen route hebben/weten om het antwoord terug te sturen.

True too. Dan zou ik moeten valideren wat de afzender is. Als die (een van beide) publieke IPs is zou een traceroute wel moeten werken en kan deze "oorzaak" die jij omschrijft niet aan de orde zijn?

Of... ik draai gewoon eens een tcpdump op de WAN interface van de router. Dan weet ik het sowieso zeker en is het makkelijkst.

[RobertMe]

@Hipska gaat door voor de wasmachine

Als ik een ping naar 2000:a:: doe dan gaat het verkeer op de WAN interface de deur uit met als source mijn 2001:xxxx (als in: publieke IP). Dit zoals verwacht.
Als ik een ping naar fd00:6::1 doe dan zie ik op de WAN poort ook dat verkeer naar buiten toe gaan, alleen als source fd00:10:xxxx.
Oftewel: zoals @Hipska al aangeeft zegt die traceroute niks. Simpelweg omdat de volgende hop geen route terug heeft naar mijn fd00:10:... adres.

[Hipska]

Klopt. Daarom heten ze ook local of private; omdat ze niet op het publieke netwerk routeerbaar zijn.

[Airw0lf]

RobertMe schreef op zaterdag 31 december 2022 @ 10:17:
@Hipska gaat door voor de wasmachine

Als ik een ping naar 2000:a:: doe dan gaat het verkeer op de WAN interface de deur uit met als source mijn 2001:xxxx (als in: publieke IP). Dit zoals verwacht.
Als ik een ping naar fd00:6::1 doe dan zie ik op de WAN poort ook dat verkeer naar buiten toe gaan, alleen als source fd00:10:xxxx.
Oftewel: zoals @Hipska al aangeeft zegt die traceroute niks. Simpelweg omdat de volgende hop geen route terug heeft naar mijn fd00:10:... adres.

Eeehhh - maar dat is precies zoals routing bedoeld is te werken...

Waarom zegt het nu niks?
Oftewel even terug - waar ben je nu naar op zoek?

[ Voor 3% gewijzigd door Airw0lf op 31-12-2022 11:55 ]

[Snow_King]

RobertMe schreef op zaterdag 31 december 2022 @ 10:17:
@Hipska gaat door voor de wasmachine

Als ik een ping naar 2000:a:: doe dan gaat het verkeer op de WAN interface de deur uit met als source mijn 2001:xxxx (als in: publieke IP). Dit zoals verwacht.
Als ik een ping naar fd00:6::1 doe dan zie ik op de WAN poort ook dat verkeer naar buiten toe gaan, alleen als source fd00:10:xxxx.
Oftewel: zoals @Hipska al aangeeft zegt die traceroute niks. Simpelweg omdat de volgende hop geen route terug heeft naar mijn fd00:10:... adres.

Klopt, zo werkt het helemaal. Routing is allemaal destination based, er wordt niet gekeken naar de source bij routing.

Let op! Uiteraard kan dit wel met ACLs en andere policies, maar in de basis kijkt een router puur naar de destination van een IP packet. Onder IPv4 en IPv6. De route terug is daarom over het internet ook nog wel eens (vaak!) anders dan de route heen.

Een traceroute verteld je dus ook niet hoe je packets bij je terug komen, alleen hoe ze bij jou vandaan gaan.

We moeten firewalls en routers niet met elkaar verwarren. De routers waar hier over wordt gesproken zoals een USG of een pfSense machine kunnen beide.

Waar ik werk gebruiken we bijvoorbeeld Juniper MX-series (204, 240 en 960) routers. Ze kunnen honderden Gigabits aan verkeer per seconde verwerken, maar ze kunnen niet firewallen. (ACL != Firewall).

Hipska schreef op zaterdag 31 december 2022 @ 10:24:
Klopt. Daarom heten ze ook local of private; omdat ze niet op het publieke netwerk routeerbaar zijn.

Technisch gezien kan het prima, maar filters droppen het vaak.

Zoals ik aan gaf, alle publieke IPv6 space valt binnen 2000::/3

[fagao]

Waar ik werk gebruiken we bijvoorbeeld Juniper MX-series (204, 240 en 960) routers. Ze kunnen honderden Gigabits aan verkeer per seconde verwerken, maar ze kunnen niet firewallen. (ACL != Firewall).

ACL is weldegelijk een manier van firewalling, maar het is geen statefull firewalling (alhoewel reflective ACL's daar ook mogelijkheid voor bieden)
Daarnaast hebben de meeste firewalls ook gewoon routing functionaliteit. Dus het is niet zo heel zwart wit.
De fabrikant zal je uiteraard doen geloven dat je naast een router een firewall nodig hebt, maar je kan met goede ACL's ook heel veel zaken dicht timmeren.

[Airw0lf]

Snow_King schreef op zaterdag 31 december 2022 @ 13:39:
[...]

Een traceroute verteld je dus ook niet hoe je packets bij je terug komen, alleen hoe ze bij jou vandaan gaan.

Even een zijstap...
Strikt genomen klopt dat. Alleen denk ik dat je de nodige problemen zou hebben op het moment dat de heenweg <> terugweg (d.w.z. asymmetric routing). Immers, de nummervolgorde van binnenkomende netwerk pakketjes klopt dan niet meer waardoor het geheel op zijn minst onvoorspelbaar wordt - zeker i.c.m. TCP-optimizers en encryptors.

Dus voor nu maar even aannemen dat heen- en terugweg altijd aan elkaar gelijk zijn?

[RobertMe]

Airw0lf schreef op zaterdag 31 december 2022 @ 11:50:
[...]


Eeehhh - maar dat is precies zoals routing bedoeld is te werken...

Waarom zegt het nu niks?
Oftewel even terug - waar ben je nu naar op zoek?

Het begon met "wat gebeurt met verkeer naar private subnetten". Antwoord dus: router (consumenten spul dan) stuurt het gewoon naar de default gateway / het internet op, en het wordt niet automatisch gedropt omdat het niet het internet op mag en tegelijkertijd intern "onbereikbaar" is. Dus zoals @Snow_King aangaf is het dan het beste om een "wan out" regel te maken die alle verkeer dropt tenzij het 2000::/3 als destination heeft.

[Airw0lf]

RobertMe schreef op zaterdag 31 december 2022 @ 15:13:
[...]

Het begon met "wat gebeurt met verkeer naar private subnetten". Antwoord dus: router (consumenten spul dan) stuurt het gewoon naar de default gateway / het internet op, en het wordt niet automatisch gedropt omdat het niet het internet op mag en tegelijkertijd intern "onbereikbaar" is. Dus zoals @Snow_King aangaf is het dan het beste om een "wan out" regel te maken die alle verkeer dropt tenzij het 2000::/3 als destination heeft.

Aja - kee. Maar dan liefst met twee van die blocking-regels:
- Een voor IPv4 private subnetten uit de RFC1918-reeks.
- Een voor de IPv6 private prefixes uit RFC4139.
Die laatste wordt ook wel aangeduid met IANA prefix FC00::/7. De genoemde FD00::/8 adressen vallen hier dan ook onder.

[fagao]

Airw0lf schreef op zaterdag 31 december 2022 @ 15:28:
[...]


Aja - kee. Maar dan liefst met twee van die blocking-regels:
- Een voor IPv4 private subnetten uit de RFC1918-reeks.
- Een voor de IPv6 private prefixes uit RFC4139.
Die laatste wordt ook wel aangeduid met IANA prefix FC00::/7. De genoemde FD00::/8 adressen vallen hier dan ook onder.

RFC4193

Overigens zou ik het gebruik van FC00::/7 altijd afraden. Er is genoeg IPv6 global space om een adres plan te maken voor je eigen netwerk/site. Elke ISP zal je een /56 geven (en soms zelfs een /48, wat overigens voor 99,99% overkill is voor consumer.)
Wil je niet dat bepaalde ranges bereikbaar zijn, zet je gewoon een ACL op je WAN verbinding en klaar is kees.

Nadeel van het gebruik maken van ULA adressen is dat je in de toekomst altijd wel tegen beperkingen aan gaat lopen en je spijt hebt dat je deze keuze gemaakt hebt. Bijvoorbeeld als je een host toch (beperkt) publiek bereikbaar wil maken.

[Roetzen]

fagao schreef op zaterdag 31 december 2022 @ 16:26:
[...]

Nadeel van het gebruik maken van ULA adressen is dat je in de toekomst altijd wel tegen beperkingen aan gaat lopen en je spijt hebt dat je deze keuze gemaakt hebt. Bijvoorbeeld als je een host toch (beperkt) publiek bereikbaar wil maken.

Er is niks tegen om zowel een ULA als een publiek adres toe te (laten) wijzen aan een interface. Het voordeel van ULA is dat het blijft werken als de verbinding met het internet wegvalt.

[fagao]

Roetzen schreef op zaterdag 31 december 2022 @ 16:31:
[...]

Er is niks tegen om zowel een ULA als een publiek adres toe te (laten) wijzen aan een interface. Het voordeel van ULA is dat het blijft werken als de verbinding met het internet wegvalt.

Je delegated prefix blijft ook werken als je verbinding wegvalt (als je CPE de RFC goed implementeert). Over het algemeen zijn die lifetimes van die prefixes lang genoeg om een storing van een paar uur te overbruggen.

Daarnaast zal een ISP niet zo snel je IPv6 delegated prefix wijzigen. De best practice is om een static IPv6 prefix toe te kennen aan klanten, zie: https://www.ripe.net/publications/docs/ripe-690

[Roetzen]

fagao schreef op zaterdag 31 december 2022 @ 16:40:
[...]

Daarnaast zal een ISP niet zo snel je IPv6 delegated prefix wijzigen. De best practice is om een static IPv6 prefix toe te kennen aan klanten, zie: https://www.ripe.net/publications/docs/ripe-690

Als eindgebruiker heb je meestal geen invloed op het prefixbeleid van de provider. De mijne (Ziggo) wijzigt de IPv6 prefix niet vaak, maar wanneer het gebeurt is onvoorspelbaar.

Mijn punt is dat je ULA en publiek adres naast elkaar kunt gebruiken. Voor wie dat handig vindt...

[RobertMe]

fagao schreef op zaterdag 31 december 2022 @ 16:26:
[...]

RFC4193

Overigens zou ik het gebruik van FC00::/7 altijd afraden. Er is genoeg IPv6 global space om een adres plan te maken voor je eigen netwerk/site. Elke ISP zal je een /56 geven (en soms zelfs een /48, wat overigens voor 99,99% overkill is voor consumer.)
Wil je niet dat bepaalde ranges bereikbaar zijn, zet je gewoon een ACL op je WAN verbinding en klaar is kees.

Nadeel van het gebruik maken van ULA adressen is dat je in de toekomst altijd wel tegen beperkingen aan gaat lopen en je spijt hebt dat je deze keuze gemaakt hebt. Bijvoorbeeld als je een host toch (beperkt) publiek bereikbaar wil maken.

Grote nadeel van puur het gebruik van de publieke adressen is dat je er totaal geen controle over hebt. Nu veranderd bij Ziggo mijn IPv4 adres al niet vaak (laatste keer is jaren terug waarbij die van 84.* naar 217.* ging, dus ook compleet ander range. Daarvoor alleen met router swap), en bij IPv6 wellicht nog minder vaak. Maar als ik zaken aan elkaar koppel (bv een DNS server die wordt uitgedeeld, of firewall regels voor specifieke systemen) wil ik niet dat ik dit allemaal ineens moet gaan wijzigen als Ziggo mij ineens een andere prefix geeft. Daarnaast zou het vervolgens ook nog eens een horde opleveren om naar een andere ISP over te stappen omdat dat gegarandeerd een nieuwe prefix zal opleveren (ok, blijkbaar behoud je bij Delta <=> Caiway swaps soms het oude IP adres, maar due doen alleen IPv4). Met een extra ULA adres voorkom ik die problemen. Mijn DNS server kan een statisch ULA adres hebben die ik door mijn router kan laten uitdelen en altijd blijft werken onafhankelijk van de prefix die de ISP toekent. En zo ook met andere communicatie tussen VLANs. Ik maak liever een firewall regel aan dat mijn IoT VLAN op fd00:11::/64 wel terug mag communiceren naar fd00:10::/64 dan een regel met 2000:abcd:1234:5611::/64 en 2000:abcd:1234:56:10::/64. Want die laatste kan elk moment wijzigen, die eerste niet.

Overigens gok ik dan dat iets uit het IoT VLAN wel nog steeds met het "prive" VLAN kab babbelen over het publieke adres. Dus "van IoT interface" naar "alles behalve WAN interface, met bestemming 2000::/7" zou dan alsnog geblokkeerd moeten worden. Maar daarbij maakt een public IP (/prefix) wijziging dan ook niet uit.

Edit:
Overigens ter opheldering. Ik gebruik dan dus beide. Daar waar ik IPv6 toepas hebben de systemen zowel een publiek als een ULA (fd00:<VLAN ID>::) adres. Dus effectief 5 adressen met dan link local, vast en privacy publiek adres en vast en privacy ULA adres.

[ Voor 5% gewijzigd door RobertMe op 31-12-2022 17:40 ]

[Roetzen]

RobertMe schreef op zaterdag 31 december 2022 @ 17:38:
[...]
Edit:
Overigens ter opheldering. Ik gebruik dan dus beide. Daar waar ik IPv6 toepas hebben de systemen zowel een publiek als een ULA (fd00:<VLAN ID>::) adres. Dus effectief 5 adressen met dan link local, vast en privacy publiek adres en vast en privacy ULA adres.

Het nut van publieke privacy adressen voor devices op een "vaste" aansluiting is al twijfelachtig, maar voor een ULA ontgaat me dat zeker...

[Snow_King]

Airw0lf schreef op zaterdag 31 december 2022 @ 13:58:
[...]


Even een zijstap...
Strikt genomen klopt dat. Alleen denk ik dat je de nodige problemen zou hebben op het moment dat de heenweg <> terugweg (d.w.z. asymmetric routing). Immers, de nummervolgorde van binnenkomende netwerk pakketjes klopt dan niet meer waardoor het geheel op zijn minst onvoorspelbaar wordt - zeker i.c.m. TCP-optimizers en encryptors.

Dus voor nu maar even aannemen dat heen- en terugweg altijd aan elkaar gelijk zijn?

Nee, zeker niet. In de regel is de terugweg eigenlijk altijd anders dan de heenweg. Zo werkt het internet nu eenmaal.

[Airw0lf]

Snow_King schreef op zaterdag 31 december 2022 @ 19:20:
[...]
Nee, zeker niet. In de regel is de terugweg eigenlijk altijd anders dan de heenweg. Zo werkt het internet nu eenmaal.

Echt? Hoe werkt dat dan bij de ontvanger (de eindbestemming)? Als de volgnummers van de netwerk pakketjes niet opeenvolgend zijn?

Bij mijn weten is dat bij de foutafhandeling (d.w.z. OSI-laag-4) wel het vertrekpunt. Omdat via die volgnummers wordt teruggemeld welke netwerk pakketjes foutvrij zijn verwerkt. En welke opnieuw verstuurd moeten worden.

[RobertMe]

Airw0lf schreef op zaterdag 31 december 2022 @ 21:57:
[...]


Echt? Hoe werkt dat dan bij de ontvanger (de eindbestemming)? Als de volgnummers van de netwerk pakketjes niet opeenvolgend zijn?

Bij mijn weten is dat bij de foutafhandeling (d.w.z. OSI-laag-4) wel het vertrekpunt. Omdat via die volgnummers wordt teruggemeld welke netwerk pakketjes foutvrij zijn verwerkt. En welke opnieuw verstuurd moeten worden.

Voor zover dat nog niet duidelijk was, ik ben een netwerk noob Maar maakt de route uit voor de volgorde? Als de client 1, 2, 3 stuurt via route A en vervolgens de server A1, A2, A3 (A voor"antwoord op") is dat toch nog steeds in volgorde? Volgens mij heeft TCP in die zin geen synchrone communicatie in de zin van 1 => A1 => 2 => A2. Zolang de client en server maar opvolgende nummers gebruiken en ze opvolgend antwoorden is dat prima? En als de verzoeken sneller verstuurd worden dan de antwoorden via een langzamere route binnen komen zou dat dus ook niet uit maken?

[arbraxas]

Redelijke noob op dit gebied, maar ik wil graag mijn router zo instellen dat ik standaard naar mijn Adguard home servertje verwijs.
Ipv4 is dat een eitje, alleen met ipv6 snap ik het even niet hoe ik dat op de router instel.
Windows / linux machines zijn niet zo`n probleem, daar kan ik het apart instellen en dan werkt het ook. Alleen een x aantal apparaten die ik heb zoals mediaspelers hebben eigenlijk alleen maar dhcp maar wel ipv6 ondersteuning.
Mijn router is een tp-link AX11000. Ben wat aan het rommelen geweest, maar dat had alleen maar als resultaat dat ik de router moest resetten 0_o
Iemand een voorzetje waar ik verder mee kan?

[Snow_King]

Airw0lf schreef op zaterdag 31 december 2022 @ 21:57:
[...]


Echt? Hoe werkt dat dan bij de ontvanger (de eindbestemming)? Als de volgnummers van de netwerk pakketjes niet opeenvolgend zijn?

Bij mijn weten is dat bij de foutafhandeling (d.w.z. OSI-laag-4) wel het vertrekpunt. Omdat via die volgnummers wordt teruggemeld welke netwerk pakketjes foutvrij zijn verwerkt. En welke opnieuw verstuurd moeten worden.

Zeker. Je haalt IP en TCP door elkaar heen. Ik praat hier over Laag 3 (L3).

Een IP packet heeft een destination en op basis daarvan zoeken routers hun route.

Ik stuur een IP packet naar host A, host A stuurt het terug naar mij ( en de route terug wordt bepaald door de routers waar het pakket dan langs komt.

In die IP packets kan TCP of UDP zitten, maar dat maakt voor de routering niet uit.

[nero355]

arbraxas schreef op zaterdag 31 december 2022 @ 22:02:
Ik wil graag mijn router zo instellen dat ik standaard naar mijn Adguard home servertje verwijs.
Ipv4 is dat een eitje, alleen met ipv6 snap ik het even niet hoe ik dat op de router instel.

Link-Local adressen gebruiken

Windows / linux machines zijn niet zo`n probleem, daar kan ik het apart instellen en dan werkt het ook. Alleen een x aantal apparaten die ik heb zoals mediaspelers hebben eigenlijk alleen maar dhcp maar wel ipv6 ondersteuning.

En zijn dat Clients die liever DHCPv6 of SLAAC hebben ??

Mijn router is een tp-link AX11000.

Post eens je IPv6 Settings in de webGUI ervan en dan kunnen we je misschien helpen...

[Airw0lf]

Snow_King schreef op zondag 1 januari 2023 @ 09:07:
[...]

Zeker. Je haalt IP en TCP door elkaar heen. Ik praat hier over Laag 3 (L3).

Een IP packet heeft een destination en op basis daarvan zoeken routers hun route.

Ik stuur een IP packet naar host A, host A stuurt het terug naar mij ( en de route terug wordt bepaald door de routers waar het pakket dan langs komt.

In die IP packets kan TCP of UDP zitten, maar dat maakt voor de routering niet uit.

RobertMe schreef op zaterdag 31 december 2022 @ 22:01:
[...]

Voor zover dat nog niet duidelijk was, ik ben een netwerk noob Maar maakt de route uit voor de volgorde? Als de client 1, 2, 3 stuurt via route A en vervolgens de server A1, A2, A3 (A voor"antwoord op") is dat toch nog steeds in volgorde? Volgens mij heeft TCP in die zin geen synchrone communicatie in de zin van 1 => A1 => 2 => A2. Zolang de client en server maar opvolgende nummers gebruiken en ze opvolgend antwoorden is dat prima? En als de verzoeken sneller verstuurd worden dan de antwoorden via een langzamere route binnen komen zou dat dus ook niet uit maken?

Ja - klopt - zo werkt het (theoretisch). Maar blijkt in de praktijk niet handig.

Je ontvangende firewall heeft daar moeite mee - laat staan als je op enig moment met twee of meer ontvangende firewalls te maken hebt. En pakketjes van een bepaalde sessie bij verschillende firewalls langskomen. Geen van die gaat nog kunnen bepalen of alles goed gaat en veilig is.

Maar we dwalen nu wel wat ver af van het topic - in een apart topic verder over bomen?

[ Voor 23% gewijzigd door Airw0lf op 01-01-2023 17:39 ]

[arbraxas]

nero355 schreef op zondag 1 januari 2023 @ 16:55:
[...]

Link-Local adressen gebruiken


[...]

En zijn dat Clients die liever DHCPv6 of SLAAC hebben ??


[...]

Post eens je IPv6 Settings in de webGUI ervan en dan kunnen we je misschien helpen...

Ik zie hier al een hoop termen die mij helemaal niets zeggen zoals SLAAC. Ga eerst ff wat Googlen om me wat te verdiepen in het onderwerp. Heb in elk geval wat steekwoorden.
Kom er op terug.

[RobertMe]

Ik heb relatief recentelijk Wireguard op gezet en ben nu ook maar aan het puzzelen met IPv6. Intussen werkt dat ook, door simpelweg aan beide kanten ("server" en "client") een IP adres binnen de prefix van de ISP te gebruiken. Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om? Ik neig nu zelf namelijk meer naar VPN op telefoon dan maar alleen te gebruiken als ik deze daadwerkelijk nodig heb (effectief dus: tijdelijk "thuis inloggen"), i.p.v. "altijd aan". Immers ben ik met "altijd aan" dan weer op het specifieke apparaat te tracken, wat de privacy extensions dan juist voorkomen.

[Roetzen]

RobertMe schreef op zondag 1 januari 2023 @ 21:18:
Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om?

Volgens mij hebben privacy extensions alleen zin als je met een mobiel apparaat de wereld rondreist. Op een "vaste" aansluiting is het schijnprivacy, je bent immers aan de prefix te identificeren. En als je servers draait slaat het helemaal nergens op. Ik heb privacy extensions op mijn hoofdcomputer uit staan.

[RobertMe]

Roetzen schreef op zondag 1 januari 2023 @ 23:14:
Op een "vaste" aansluiting is het schijnprivacy, je bent immers aan de prefix te identificeren.

Zoals bij IPv4 dus. Wel te traceren op aansluiting (IPv4 adres of IPv6 prefix), niet op individueel apparaat (want NAT verbergt het IP bij v4 en privacy extensions soort van bij v6).

En als je servers draait slaat het helemaal nergens op.

Care to elaborate? Een server zet sowieso vrijwel geen uitgaande verbindingen op dus zouden de privacy extensions al minder van toepassing zijn. En voor inkomende verbindingen zijn de privacy extensions nooit bedoeld geweest en heb je de statische suffix (die meestal op het MAC adres gebaseerd is?).
Nog los van het feit dat je een server altijd al een statisch v4 adres geeft. Ik zou ook niet weten waarom dat bij v6 anders zou zijn en daar SLAAC, DHCP of privacy extensions op van toepassing zouden zijn.

[Snow_King]

Airw0lf schreef op zondag 1 januari 2023 @ 17:26:
[...]


[...]


Ja - klopt - zo werkt het (theoretisch). Maar blijkt in de praktijk niet handig.

Je ontvangende firewall heeft daar moeite mee - laat staan als je op enig moment met twee of meer ontvangende firewalls te maken hebt. En pakketjes van een bepaalde sessie bij verschillende firewalls langskomen. Geen van die gaat nog kunnen bepalen of alles goed gaat en veilig is.

Maar we dwalen nu wel wat ver af van het topic - in een apart topic verder over bomen?

Nee, toch zitten we in dit topic goed wat mij betreft. Want we hebben het hier over IP(v6), maar jij denkt hier op TCP/UDP niveau.

Je moet het zo zien:

- Jouw router stuurt een brief naar Groningen vanaf Amsterdam
- De brief komt aan en ik reageer terug

Heenweg: A1, knooppunt hoevelaken (router), A28 naar Groningen
Terugweg: A7, afsluitdijk, A8, A10

In beide gevallen is het pakketje aangekomen met de juiste inhoud. De route die daar tussen lag doet er niet toe.

Zo werkt IP, zo werkt het internet. In het overgrote deel van de routes terug anders dan heen. Dat maakt ook niet uit, alles komt gewoon in de juiste volgorde aan.

Firewalls doen er hier even niet toe, die zijn druk bezig met L4 en evt hoger. We hebben het hier over L3.

L3 is waar IPv6 op werkt.

[Airw0lf]

Snow_King schreef op maandag 2 januari 2023 @ 09:26:
[...]

Nee, toch zitten we in dit topic goed wat mij betreft. Want we hebben het hier over IP(v6), maar jij denkt hier op TCP/UDP niveau.

Je moet het zo zien:

- Jouw router stuurt een brief naar Groningen vanaf Amsterdam
- De brief komt aan en ik reageer terug

Heenweg: A1, knooppunt hoevelaken (router), A28 naar Groningen
Terugweg: A7, afsluitdijk, A8, A10

In beide gevallen is het pakketje aangekomen met de juiste inhoud. De route die daar tussen lag doet er niet toe.

Zo werkt IP, zo werkt het internet. In het overgrote deel van de routes terug anders dan heen. Dat maakt ook niet uit, alles komt gewoon in de juiste volgorde aan.

Firewalls doen er hier even niet toe, die zijn druk bezig met L4 en evt hoger. We hebben het hier over L3.

L3 is waar IPv6 op werkt.

Zo bezien - ja - zolang de weg terug voor een gegeven sessie altijd hetzelfde pad is klopt dat.
En inderdaad - dat hoeft niet hetzelfde pad te zijn als de heenweg.

[Streamert]

Snow_King schreef op vrijdag 30 december 2022 @ 13:53:
[...]


Houd er rekening mee dat DHCP6 voor WAN in dit geval enkel is het voor het verkijgen van een IPv6 adres op je WAN. Deze heb je in de basis niet eens nodig omdat je via Link-Local al een prefix kan krijgen via DHCPv6+PD

Let op! Dit heet dan wel beide DHCPv6, dat is het ook, maar the devil is in the details.

Via PD, Prefix Delegation, ga je via DHCPv6 om een Prefix vragen en daar gaat het mis wellicht. In je screenshots:

- Request IPv6 via IPv4 link? Die snap ik niet. Zet die eens uit
- Only request a IPv6 prefix, probeer die eens

Je krijgt dan een /48 of /56 (ligt aan de ISP) en daaruit kan je weer /64s uitdelen aan je LAN.

Eindelijk in de gelegenheid om wat testjes te doen. Bedankt voor je informatie en suggestie, maar in alle gevallen krijg ik zonder het gebruik van de optie om IPv6 via IPv4 aan te vragen alleen een link-local adres en werkt IPv6 op mijn LAN ook niet meer. De status van de WAN_DHCP6 is dan offline.
Glasnet is een fijne provider met prima support, maar er is erg weinig informatie verder over het gebruik van IPv6 icm pfSense, wat bijv. voor KPN wel te vinden is.

[hkoster1]

RobertMe schreef op zondag 1 januari 2023 @ 21:18:
Ik heb relatief recentelijk Wireguard op gezet en ben nu ook maar aan het puzzelen met IPv6. Intussen werkt dat ook, door simpelweg aan beide kanten ("server" en "client") een IP adres binnen de prefix van de ISP te gebruiken. Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om? Ik neig nu zelf namelijk meer naar VPN op telefoon dan maar alleen te gebruiken als ik deze daadwerkelijk nodig heb (effectief dus: tijdelijk "thuis inloggen"), i.p.v. "altijd aan". Immers ben ik met "altijd aan" dan weer op het specifieke apparaat te tracken, wat de privacy extensions dan juist voorkomen.

In plaats van je echte ISP IPv6-prefix kun je toch adressen uit fd00::/8 gebruiken voor de Wireguard tunnel?

[RobertMe]

hkoster1 schreef op maandag 2 januari 2023 @ 12:11:
[...]

In plaats van je echte ISP IPv6-prefix kun je toch adressen uit fd00::/8 gebruiken voor de Wireguard tunnel?

Klopt, maar dan kan ik niet het internet op, terwijl dat dan wel mijn bedoeling zou zijn. Of ik moet NAT66 gaan toepassen, maar dat voelt dan ook raar.

[hkoster1]

Je kunt ook je Wireguard tunnel via een VPS-met-socat (als portmapper) sturen, daarmee wordt het Endpoint op je mobiele apparaat dat van de VPS, niet je thuisaansluiting.

[Airw0lf]

RobertMe schreef op maandag 2 januari 2023 @ 12:13:
[...]

Klopt, maar dan kan ik niet het internet op, terwijl dat dan wel mijn bedoeling zou zijn. Of ik moet NAT66 gaan toepassen, maar dat voelt dan ook raar.

Mja - maar dit lijkt wel de praktijk te (gaan?) zijn:
Private IPv6 adressen en die gaan NAT-en - analoog aan IPv4.

[Muis666]

RobertMe schreef op zondag 1 januari 2023 @ 21:18:
Ik heb relatief recentelijk Wireguard op gezet en ben nu ook maar aan het puzzelen met IPv6. Intussen werkt dat ook, door simpelweg aan beide kanten ("server" en "client") een IP adres binnen de prefix van de ISP te gebruiken. Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om? Ik neig nu zelf namelijk meer naar VPN op telefoon dan maar alleen te gebruiken als ik deze daadwerkelijk nodig heb (effectief dus: tijdelijk "thuis inloggen"), i.p.v. "altijd aan". Immers ben ik met "altijd aan" dan weer op het specifieke apparaat te tracken, wat de privacy extensions dan juist voorkomen.

Tja, dat is een nadeel van de huidige wireguard implementatie, alleen statische IPv6 adressen. Ik liep hier zelf ook tegenaan en accepteer het voorlopig maar.

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 10:56:
[...]


Eindelijk in de gelegenheid om wat testjes te doen. Bedankt voor je informatie en suggestie, maar in alle gevallen krijg ik zonder het gebruik van de optie om IPv6 via IPv4 aan te vragen alleen een link-local adres en werkt IPv6 op mijn LAN ook niet meer. De status van de WAN_DHCP6 is dan offline.
Glasnet is een fijne provider met prima support, maar er is erg weinig informatie verder over het gebruik van IPv6 icm pfSense, wat bijv. voor KPN wel te vinden is.

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

[Airw0lf]

Snow_King schreef op maandag 2 januari 2023 @ 12:31:
[...]

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

[Keiichi]

Airw0lf schreef op maandag 2 januari 2023 @ 13:07:
[...]


Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

Mijn config voor pfsense is als volgt:

KPN Wan interface: https://frankdebot.nl/tmp/tweaker/kpn-v6/kpnwan.png
LAN: https://frankdebot.nl/tmp/tweaker/kpn-v6/locallan.png

Op m'n LAN heb ik eigenlijk niet echt iets met configuratie vanuit de PD gedaan, gewoon een subnet gepakt. Volgens mij gooit KPN alle v6 pakjes in je /48 (of /56?) die je in je PD zitten krijgt gewoon op je lijn.

[Roetzen]

RobertMe schreef op maandag 2 januari 2023 @ 06:54:
[...]

Zoals bij IPv4 dus. Wel te traceren op aansluiting (IPv4 adres of IPv6 prefix), niet op individueel apparaat (want NAT verbergt het IP bij v4 en privacy extensions soort van bij v6).

Als een apparaat verbinding maakt met het internet zijn er voor iemand die dat wil zo veel mogelijkheden om van alles over dat apparaat te weten te komen en het te volgen, dat het m.i. vrij zinloos is om te proberen het IP adres te verbergen.

Care to elaborate? Een server zet sowieso vrijwel geen uitgaande verbindingen op dus zouden de privacy extensions al minder van toepassing zijn. En voor inkomende verbindingen zijn de privacy extensions nooit bedoeld geweest

Precies Van een server kun je het IP adres sowieso niet verbergen.

en heb je de statische suffix (die meestal op het MAC adres gebaseerd is?)

Alleen bij SLAAC. Er zijn meer mogelijkheden...

Tja je vroeg hoe anderen omgaan met privacy extensions. Mijn antwoord was: op een "vaste" aansluiting: niet.

[nero355]

Muis666 schreef op maandag 2 januari 2023 @ 12:30:
Tja, dat is een nadeel van de huidige wireguard implementatie, alleen statische IPv6 adressen.
Ik liep hier zelf ook tegenaan en accepteer het voorlopig maar.

Dus totaal geen DHCPv6/SLAAC mogelijkheden

Kan je tenminste de boel met je lokale netwerk bridgen en dan op die manier eromheen werken ?!

OpenVPN heeft bijvoorbeeld de keuze tussen TUN en TAP Interfaces die je verschillende mogelijkheden geven

[RobertMe]

nero355 schreef op maandag 2 januari 2023 @ 15:14:
[...]

Dus totaal geen DHCPv6/SLAAC mogelijkheden

Nope. Overigens ook geen DHCP op IPv4. Je moet de interface een of meerdere statische IP adressen geven, en aan de andere kant moet je ook expliciet aangeven welke IP adressen gerouteerd mogen worden naar die peer. Dus de "server" stel je statisch in met IP adres X. Vervolgens geef je meerdere peers op met bij elke peer een "Allowed IPs" die (minimaal) het statische IP van die peer moet matchen. Bij elke "client" geef je dan ook weer expliciet aan "de interface heeft IP Y" en dan dat er een peer is (zijnde de "server") en daarbij moet je dan ook weer een "Allowed IPs" opgeven die minimaal X bevat (of dus het volledige subnet, of meerdere subnets, of 0.0.0.0/0 en ::/0).

Kan je tenminste de boel met je lokale netwerk bridgen en dan op die manier eromheen werken ?!

Vast niet. Dan zou je alsnog de wg interface een vast IP moeten geven om vervolgens weer een bridge te maken met daarin de wg interface en daarop zou je dan SLAAC moeten toepassen? Geeft me al koppijn als ik er aan denk. Om nog maar te zwijgen over "hoe wil je dit in godsnaam op een telefoon doen".

OpenVPN heeft bijvoorbeeld de keuze tussen TUN en TAP Interfaces die je verschillende mogelijkheden geven

Maar TUN/TAP zijn user space dingen. Wireguard zit volledig in de kernel ingebakken. De wg command line tools sturen maar de kernel aan. En de wireguard config files staan ook zaken in die je zelf kunt doen zonder wireguard tools. Zo kun (/moet) je de interface aanmaken met ip link add dev wg0 type wireguard. De statische IP configuratie doe je met ip addr add ... de Allowed IPs zijn effectief de routes die dus door ip route beheert worden etc etc. wg gebruik je alleen om de Wireguard specifieke stuff te regelen, dus de private key, peers (met de public key, optionele endpoint, etc).

[nero355]

RobertMe schreef op maandag 2 januari 2023 @ 15:38:
- Nope.
- Overigens ook geen DHCP op IPv4.
- Vast niet.

Wat een crap systeem dan!

OpenVPN is echt lichtjaren verder wat betreft al die dingen dus je moet wel heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn (Dat is tenminste wat ik hier en daar lees ?!) om voor Wireguard te kiezen

[Streamert]

Snow_King schreef op maandag 2 januari 2023 @ 12:31:
[...]

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

Goeie vraag en ik had inderdaad gezocht, maar kon er geen kaas van maken, in ieder geval heb ik een stukje uit de PPP logs wat misschien interessant is, alleen ik kan er niets mee.

code:

Jan 2 19:18:16  ppp 99184   [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Add description "WAN"
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Rename interface ng0 to pppoe0
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Up event
Jan 2 19:18:13  ppp 99184   [wan] 020c:29ff:fedd:9a41 -> 0000:0000:00f1:282f
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: LayerUp
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Ack-Sent --> Opened
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPADDR 0.0.0.0
Jan 2 19:18:13  ppp 99184   [wan] IPCP: SendConfigReq #2
Jan 2 19:18:13  ppp 99184   [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 2 19:18:13  ppp 99184   [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan_link0] rec'd unexpected protocol MPLS Control Protocol (RFC 3032), rejecting
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Req-Sent --> Ack-Sent
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: SendConfigAck #1
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPCP: state change Req-Sent --> Ack-Sent

[Streamert]

Airw0lf schreef op maandag 2 januari 2023 @ 13:07:
[...]


Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

Inderdaad, handige voorbeelden zijn ten minste terug te vinden.

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 19:30:
[...]


Goeie vraag en ik had inderdaad gezocht, maar kon er geen kaas van maken, in ieder geval heb ik een stukje uit de PPP logs wat misschien interessant is, alleen ik kan er niets mee.

code:

Jan 2 19:18:16  ppp 99184   [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Add description "WAN"
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Rename interface ng0 to pppoe0
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Up event
Jan 2 19:18:13  ppp 99184   [wan] 020c:29ff:fedd:9a41 -> 0000:0000:00f1:282f
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: LayerUp
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Ack-Sent --> Opened
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPADDR 0.0.0.0
Jan 2 19:18:13  ppp 99184   [wan] IPCP: SendConfigReq #2
Jan 2 19:18:13  ppp 99184   [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 2 19:18:13  ppp 99184   [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan_link0] rec'd unexpected protocol MPLS Control Protocol (RFC 3032), rejecting
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Req-Sent --> Ack-Sent
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: SendConfigAck #1
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPCP: state change Req-Sent --> Ack-Sent

Ben je een beetje begaan met SSH? Ik zou anders eens op de terminal van de router inloggen en daar in /var/log eens door wat logfiles gaan bladeren.

Dit moet echt ergens een kleine setting zijn. Zo lastig is het allemaal niet uiteindelijk, het zijn gewoon standaard protocollen die ook Glasnet gebruikt.

[Airw0lf]

Streamert schreef op maandag 2 januari 2023 @ 19:34:
[...]

Inderdaad, handige voorbeelden zijn ten minste terug te vinden.

Proef ik daar enige ironie...?

Unne dikke mercie - vrijwel zeker overheen gekeken!

[Streamert]

Airw0lf schreef op maandag 2 januari 2023 @ 20:37:
[...]


Proef ik daar enige ironie...?

Unne dikke mercie - vrijwel zeker overheen gekeken!

Totaal niet ironisch bedoeld, maar toen ik zoekende was kwam ik dit als beste voorbeeld tegen en dacht (natuurlijk) dat ik eindelijk de oplossing had.

[Streamert]

Snow_King schreef op maandag 2 januari 2023 @ 19:39:
[...]

Ben je een beetje begaan met SSH? Ik zou anders eens op de terminal van de router inloggen en daar in /var/log eens door wat logfiles gaan bladeren.

Dit moet echt ergens een kleine setting zijn. Zo lastig is het allemaal niet uiteindelijk, het zijn gewoon standaard protocollen die ook Glasnet gebruikt.

SSH is niet zo'n punt, anders kun je beter bij pfSense wegblijven, of elke andere *nix, maar als je een tail -f /var/log/dhcpd.log /var/log/ppp.log /var/log/system.log doet, krijg je niet veel meer info dan in de Status/System Logs sectie van de web interface, als ik me niet vergis?

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 20:59:
[...]


SSH is niet zo'n punt, anders kun je beter bij pfSense wegblijven, of elke andere *nix, maar als je een tail -f /var/log/dhcpd.log /var/log/ppp.log /var/log/system.log doet, krijg je niet veel meer info dan in de Status/System Logs sectie van de web interface, als ik me niet vergis?

De dhcpd.log file is van de DHCP server, maar je wil juist de client hebben.

Maar als je met 'ifconfig -a' kijkt, krijg je WAN interface wel een IPv6 adres?

En ergens moet je iets kunnen vinden in de logs over een DHCPv6 lease met een prefix of iets dergelijks. Vooral even blijven zoeken.

[Streamert]

Snow_King schreef op dinsdag 3 januari 2023 @ 09:48:
[...]

De dhcpd.log file is van de DHCP server, maar je wil juist de client hebben.

Maar als je met 'ifconfig -a' kijkt, krijg je WAN interface wel een IPv6 adres?

En ergens moet je iets kunnen vinden in de logs over een DHCPv6 lease met een prefix of iets dergelijks. Vooral even blijven zoeken.

De WAN interface krijgt alleen een link-local adres, fe80... en fungeert dus als gateway in dit geval. De van oorsprong meegeleverde Vigor 2130 router voor Glasnet, ook nog even een test mee gedaan, krijgt op de WAN interface netjes een publiek IPv6 adres. Kan ik er dan vanuit gaan dat je in pfSense hetzelfde is?

[Snow_King]

Streamert schreef op dinsdag 3 januari 2023 @ 11:32:
[...]


De WAN interface krijgt alleen een link-local adres, fe80... en fungeert dus als gateway in dit geval. De van oorsprong meegeleverde Vigor 2130 router voor Glasnet, ook nog even een test mee gedaan, krijgt op de WAN interface netjes een publiek IPv6 adres. Kan ik er dan vanuit gaan dat je in pfSense hetzelfde is?

pfSense zou op de WAN ook een publiek IPv6 adres moeten krijgen. Daar zit in je instellingen dan het eerste probleem.

Dat moet je oplossen met:
- SLAAC
- DHCPv6 IA (Address verkrijgen)

Kan je in die Vigor 2130 iets van instellingen opvragen?

[Streamert]

Snow_King schreef op dinsdag 3 januari 2023 @ 12:31:
[...]

pfSense zou op de WAN ook een publiek IPv6 adres moeten krijgen. Daar zit in je instellingen dan het eerste probleem.

Dat moet je oplossen met:
- SLAAC
- DHCPv6 IA (Address verkrijgen)

Kan je in die Vigor 2130 iets van instellingen opvragen?

Ik ga voor de SLAAC/DHCPv6 toch nog een keer contact opnemen met support.

Helaas heb ik de Vigor inmiddels al weer teruggestuurd, maar het was lastig om vergelijkbare settings te vinden in een interface die zo totaal anders is, gezien de aard van het beestje.

In de tussentijd ben ik ook wel benieuwd hoe de configuraties van vergelijkbare ISP's eruit zien, zoals Telford en anderen. Ik vermoed dat we nog veel van elkaar kunnen leren.

[Snow_King]

Streamert schreef op dinsdag 3 januari 2023 @ 13:11:
[...]


Ik ga voor de SLAAC/DHCPv6 toch nog een keer contact opnemen met support.

Helaas heb ik de Vigor inmiddels al weer teruggestuurd, maar het was lastig om vergelijkbare settings te vinden in een interface die zo totaal anders is, gezien de aard van het beestje.

In de tussentijd ben ik ook wel benieuwd hoe de configuraties van vergelijkbare ISP's eruit zien, zoals Telford en anderen. Ik vermoed dat we nog veel van elkaar kunnen leren.

Al die configs zijn echt bijna identiek, zo veel spannends zit er niet in. Voor IPv4 heb je DHCP en voor IPv6 heb je de keuze uit SLAAC en DHCPv6.

DHCPv6 IA voor adres allocatie en PD voor Prefix Delegation.

[alm]

Heeft er iemand recente ervaring met een HE IPv6 tunnel die daar iets over kan zeggen qua stabiliteit/betrouwbaarheid/snelheid?

Ik ben mijn opties aan het verkennen nu hier in de buurt glasvezel van T-Mobile komt en zij alleen IPv4 leveren. Heb nu XS4All/KPN via VDSL en wil IPv6 niet kwijt mocht ik daarnaar overstappen.

[xbeam]

Misschien interessant om te kijken/volgen hoe deze ipv6 post/discussie zich onder zijn wereldwijd volgers gaat ontwikkelen.
[Embed: Tom Lawrence IPv6 discussion]

[ Voor 54% gewijzigd door xbeam op 06-01-2023 09:50 ]

[fvbommel]

alm schreef op donderdag 5 januari 2023 @ 21:44:
Heeft er iemand recente ervaring met een HE IPv6 tunnel die daar iets over kan zeggen qua stabiliteit/betrouwbaarheid/snelheid?

Ik ben mijn opties aan het verkennen nu hier in de buurt glasvezel van T-Mobile komt en zij alleen IPv4 leveren. Heb nu XS4All/KPN via VDSL en wil IPv6 niet kwijt mocht ik daarnaar overstappen.

Ik heb dit enige tijd gebruikt na de overstap naar online.nl glasvezel (via Delta/Caiway).

Het werkte op zich prima, al kan het zijn dat het niet de volledige snelheid van de verbinding kon benutten (weet ik niet meer zeker, maar was in ieder geval niet problematisch traag of zo).

Het grotere probleem was de geolocatie: ondanks dat het in het systeem van HE geregistreerd stond als Amsterdam, waren verschillende streaming-diensten er niet blij mee.

We gebruiken hier toch al niet echt veel zulke diensten, maar ook de IPTV (via Canal Digitaal) konden hier blijkbaar niet mee omgaan waardoor hun TV-boxjes vaak niet werkten. Dit was een deal breaker, dus het staat nu alweer een hele tijd uit helaas. (Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

[alm]

fvbommel schreef op vrijdag 6 januari 2023 @ 09:45:
[...]


Ik heb dit enige tijd gebruikt na de overstap naar online.nl glasvezel (via Delta/Caiway).

Het werkte op zich prima, al kan het zijn dat het niet de volledige snelheid van de verbinding kon benutten (weet ik niet meer zeker, maar was in ieder geval niet problematisch traag of zo).

Het grotere probleem was de geolocatie: ondanks dat het in het systeem van HE geregistreerd stond als Amsterdam, waren verschillende streaming-diensten er niet blij mee.

We gebruiken hier toch al niet echt veel zulke diensten, maar ook de IPTV (via Canal Digitaal) konden hier blijkbaar niet mee omgaan waardoor hun TV-boxjes vaak niet werkten. Dit was een deal breaker, dus het staat nu alweer een hele tijd uit helaas. (Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

Da's wel een minpunt dan. Heb nu totaal geen issues met IPv6 gebruik. Ik neem aan dat je deze issues met native IPv6 bij de voorgaande provider niet had? Of had je nog geen IPv6 daarvoor?

[fvbommel]

Daarvoor had ik Ziggo, maar in former UPC gebied wat destijds nog betekende dat ik moest kiezen tussen IPv4-only of DS-Lite (IPv6 + IPv4, maar geen IPv4 port forwarding). Dus toen moest ik IPv6 uit laten zetten om poorten te kunnen openen op IPv4.

Ik heb daar geprobeerd een HE tunnel op te zetten, maar dat lukte niet zonder een PC in de DMZ te zetten (effectief zonder firewall vanuit het Internet) dus dat heb ik toen ook maar achterwege gelaten.

[nero355]

fvbommel schreef op vrijdag 6 januari 2023 @ 09:45:
(Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

Apart VLAN opzetten zodra je een fatsoenlijke Router koopt of bouwt!

[Freeaqingme]

Ik zat te kijken naar een Ziggo Internet Pro abonnement vanwege de SLA. Je hoort wel eens dat supportafdelingen zeggen "wij horen nooit iemand vragen naar ipv6", dus dat dacht ik even te doen.

17:26
Hallo,

Zit er bij een internet pro pakket ook IPv6?

Een goedemiddag Freeaqingme. U spreekt nu met $medewerker en ik help u graag met uw zakelijke vragen over zowel Ziggo als Vodafone 🙂 Goed dat u contact met ons opneemt. Dit is inderdaad standaard bij onze pro pakket.

Oke. En zijn die adressen ook vast?

Nee de IPV6 is voor intern. naar de buitenwereld is het IPV4 met 1 vast ip. Gaat u ook gebruik maken van wifi via ons apparatuur?

Nee, geen wifi. Maar, IPv6 is ook echt voor extern verkeer. Dus de vraag is of dat dan ook verandert, of dat je zolang het abonnement loopt hetzelfde ipv6-subnet behoudt

Dat is een goeie vraag. Ik vraag het even na voor de zekerheid. 1 moment

Dat klopt inderdaad, dat is ook voor extern en dat zal niet wijzigen.

Oke. En hoe groot is het subnet dat je krijgt toegewezen met een pro pakket?

17:37
Ik ga u even doorverbinden naar de afdeling waar ik zojuist mee sprak. Ik moet eerlijk bekennen dat ik hier niet de info voor in huis heb. 1 moment alstublieft.

17:47
ik: Oke

18:48
Ik: Hallo?

Denk dat dat doorverwijzen nog even gaat duren.

[Snow_King]

Freeaqingme schreef op dinsdag 10 januari 2023 @ 18:52:
Ik zat te kijken naar een Ziggo Internet Pro abonnement vanwege de SLA. Je hoort wel eens dat supportafdelingen zeggen "wij horen nooit iemand vragen naar ipv6", dus dat dacht ik even te doen.


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


Denk dat dat doorverwijzen nog even gaat duren.

Ik heb Ziggo Zakelijk Pro als thuisverbinding. Dit vanwege de SLA omdat ik 3 a 4 dagen in de week thuis werk en vanwege het vaste IPv6 subnet en IPv4 adres.

Je krijgt een opleverdocument met daar in:

- IPv4 /30 subnet om te configureren op je router (geen DHCP dus!)
- IPv6 /48 subnet (static)

De eerste /64 uit deze /48 wordt gebruikt voor Ziggo <> Jouw router en ze routeren dan de rest van de /48 naar het ::2 adres uit die /64.

Zowel het IPv4 als IPv6 subnet worden vervolgens in de RIPE database op jouw naam gezet.

[CAPSLOCK2000]

nero355 schreef op maandag 2 januari 2023 @ 16:22:
OpenVPN is echt lichtjaren verder wat betreft al die dingen dus je moet wel heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn (Dat is tenminste wat ik hier en daar lees ?!) om voor Wireguard te kiezen

Zo moet je het niet zien. Dat beide producten 'VPN' genoemd worden betekent niet dat ze hetzelfde doel hebben. We gebruiken de term 'VPN' tegenwoordig vooral in relatie met privacy maar dat hoeft niet. Wireguard heeft een ander doel en een andere aanpak.

Wireguard heeft juist het doel om minimalistisch te zijn. Doe één ding goed.
Wireguard heeft niet het doel om een totaal-oplossing te zijn voor alle use-cases die OpenVPN heeft.

Het enige wat Wireguard doet is pakketjes veilig van A naar B brengen, niet meer en niet minder.
In tegenstelling tot OpenVPN dat een totaalpakket probeer te leveren en dus ook een stukje routing doet, wat adresmanagement, hele netwerken kan tunnelen, een hoop authenticatiemethodes heeft, een management interface, wat privacy dingetjes en andere zaken die je van een totaalpakket verwacht.

Als OpenVPN precies doet wat je wil (en snel genoeg is) dan is er geen goede reden om over te stappen. Maar als OpenVPN niet goed past en te veel of te weinig doet dan heb je met Wireguard meer flexibiliteit.

Wat meer theoretisch zou je kunnen zeggen dat Wireguard veiliger is omdat het veel simpeler en daardoor overzichtelijker is. OpenVPN is veel groter en daar moet je dus veel meer beveiligen en controleren. Hoe simpeler een systeem is hoe minder kans op onvoorziene problemen of verstopte fouten.

heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn

Onderschat niet hoe gigantisch groot het verschil is. Mijn router kan Wireguard op gigabit snelheid doen (en waarschijnlijk nog sneller, maar dat heb ik niet) terwijl OpenVPN moeite heeft om meer dan 20% van de verbinding te vullen terwijl de CPU staat te roken.

OpenVPN vs Wireguard is als MS Terminal Server versus SSH.

Ik gebruik Wireguard om mijn telefoon en mijn laptop te verbinden met mijn thuisnetwerk. Privacy speelt geen rol want het is allemaal van mij en ik hoef geen adressen voor mezelf te verbergen of zo iets.

Ook heb ik een commerciele VPN voor uitgaand verkeer dat Wireguard gebruikt. Dat gebruik ik bv als ik een Facebook-pagina "moet" bekijken en ik niet wil dat ze m'n vaste IP zien.


Ten derde heb ik een geneste VPN-verbinding naar mijn werk (de binnenste tunnel is overigens geen Wireguard). Dat is niet omdat ik mijn werkgever niet vertrouw maar omdat deel van mijn werk is dat mensen soms niet zo blij met me zijn, ook mensen met zeg maar meer technische skills dan ethiek. Het soort mensen dat niet bij ons in dienst is maar wel van binnenuit meekijkt.
Daarom stuur ik de VPN-verbinding naar mijn werkgever via een commerciele VPN-aanbieder.
Ik heb niet de illusie dat dit een waterdichte beveiliging is, wie gaat zoeken kan mijn IP echt wel vinden, maar iedere extra hobbel is er een.

In mijn thuisnetwerk heb ik aparte VLANs voor de verschillende uitgaande VPNs. Als je in zo'n vlan zit wordt al het uitgaande verkeer automatisch via VPN gerouteerd. Mijn router zit er tussen om te NATten want Wireguard doet alleen de point-to-point verbinding van mijn router naar die van de provider.

Ook verkeer uit andere VLAN's kan door mijn router onderschept worden en via een geschikt VPN naar buiten worden gestuurd.

Tegenwoordig doe ik dit dus met Wireguard maar vroeger gebruikte ik OpenVPN. Het enige waar ik nog geen alternatief voor heb is dat OpenVPN met profielen/accounts kan werken met verschillende configuraties. Dat gebruikte ik om mijn telefoon/laptop in een vlan naar keuze te kunnen zetten. Wireguard heeft geen concept van gebruikers of accounts. Ik denk dat het mogelijk is om Wireguard op verschillende poorten te laten luisteren en daar dan iets aan te knopen maar dat heb ik nog niet geimplementeerd.

[RobertMe]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 12:11:
Ik denk dat het mogelijk is om Wireguard op verschillende poorten te laten luisteren en daar dan iets aan te knopen maar dat heb ik nog niet geimplementeerd.

Dat is inderdaad geen probleem. Je kunt gewoon meerdere WG interfaces aanmaken en per interface bv ook andere routering en/of NATing inregelen.

[Airw0lf]

@CAPSLOCK2000 en @RobertMe - Hoe zou zo een vergelijking met IPsec er uit kunnen zien?

[CAPSLOCK2000]

Airw0lf schreef op woensdag 11 januari 2023 @ 13:04:
@CAPSLOCK2000 en @RobertMe - Hoe zou zo een vergelijking met IPsec er uit kunnen zien?

Wireguard zit vrij dicht bij ipsec maar ipsec kan meer. Wireguard is end-to-end. ipsec kan ook onderweg worden toegepast op pakketjes die worden doorgegeven.
Het nadeel van ipsec is dat het enorm complex is.

Daarbij is er een hardnekkig gerucht dat ipsec opzettelijk verzwakt is een geheime dienst die zich heeft bemoeit met het opstellen van de standaard. Dat is nooit bewezen maar door de enorme complexiteit van ipsec is dat ook erg lastig. Eigenlijk niemand begrijpt echt hoe het precies werkt en waarom bepaalde keuzes zijn gemaakt en hoe die elkaar beinvloeden.

Dat is een van de directe redenen waarom Wireguard is gegaan voor de minimalistische aanpak. In plaats van de eindeloos veel configuratieopties en flexibele encrpytiealgoritmes en backwards compatibility van ipsec is er juist bijna niks te kiezen bij wireguard. Er is van alles één en daarbij worden geen compromis geaccepteerd. Doe het goed of niet. Als er iets te kiezen is dan maken sommige mensen de verkeerde keuze. Daarom heeft Wireguard z'n best gedaan om een 'one-size-fits-all' oplossing te kiezen en zo veel mogelijk voor eenvoud gekozen boven flexibiliteit.

Omdat de tool maar één ding doet is dat gebrek aan flexbiliteit ook niet zo erg.

Pragmatisch gezien heeft ipsec het voordeel dat het vrij breed wordt ondersteunt en niet is gebonden aan één platform of leverancier.

[nero355]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 12:11:
Zo moet je het niet zien. Dat beide producten 'VPN' genoemd worden betekent niet dat ze hetzelfde doel hebben.

Tja, ik ben nog niet echt met Wireguard bezig geweest, maar door de vele directe vergelijkingen met OpenVPN en soms zelfs IPSec/L2TP en dergelijken kreeg ik wel de indruk dat ze allemaal hetzelfde moeten kunnen, maar blijkbaar is dat niet zo...

We gebruiken de term 'VPN' tegenwoordig vooral in relatie met privacy maar dat hoeft niet. Wireguard heeft een ander doel en een andere aanpak.

Ik ben niet zo van de hypes en door mijn werkervaring heb ik daar een heel ander beeld van, maar ook op dat gebied is het best wel vreemd dat men dan opeens ook Wireguard ging gebruiken ondanks de slechtere privacy en logging opties en weet ik het wat allemaal...

Het enige wat Wireguard doet is pakketjes veilig van A naar B brengen, niet meer en niet minder.
In tegenstelling tot OpenVPN dat een totaalpakket probeer te leveren en dus ook een stukje routing doet, wat adresmanagement, hele netwerken kan tunnelen, een hoop authenticatiemethodes heeft, een management interface, wat privacy dingetjes en andere zaken die je van een totaalpakket verwacht.

Maar dan nog : Doe daar een Bridged VPN Interface bij en je laat een hoop van die nadelen over aan de beheerder die ze vervolgens kan oplossen via allerlei alternatieven!

Onderschat niet hoe gigantisch groot het verschil is. Mijn router kan Wireguard op gigabit snelheid doen (en waarschijnlijk nog sneller, maar dat heb ik niet) terwijl OpenVPN moeite heeft om meer dan 20% van de verbinding te vullen terwijl de CPU staat te roken.

Precies mijn punt : Het lijkt net of er een heleboel mensen alle nadelen negeren puur vanwege de snelheid ?!

OpenVPN vs Wireguard is als MS Terminal Server versus SSH.

Niet mee eens, want SSH kan ook dingen als Tunneling en X-Forwarding wat je weer met VNC/RDP achtigen kan combineren!

Ook heb ik een commerciele VPN voor uitgaand verkeer dat Wireguard gebruikt. Dat gebruik ik bv als ik een Facebook-pagina "moet" bekijken en ik niet wil dat ze m'n vaste IP zien.

Dat is een hoop gedoe en geld voor zoiets simpels : Blokkeer gewoon alle advertenties en tracking zoveel mogelijk en dan ben je er ook grotendeels...

Als je toevallig ergens een VPS of Dedicated Server hebt staan dan zou je zelfs die voor zoiets kunnen misbruiken

Ten derde heb ik een geneste VPN-verbinding naar mijn werk (de binnenste tunnel is overigens geen Wireguard). Dat is niet omdat ik mijn werkgever niet vertrouw maar omdat deel van mijn werk is dat mensen soms niet zo blij met me zijn, ook mensen met zeg maar meer technische skills dan ethiek. Het soort mensen dat niet bij ons in dienst is maar wel van binnenuit meekijkt.
Daarom stuur ik de VPN-verbinding naar mijn werkgever via een commerciele VPN-aanbieder.
Ik heb niet de illusie dat dit een waterdichte beveiliging is, wie gaat zoeken kan mijn IP echt wel vinden, maar iedere extra hobbel is er een.

Tijd om van baan te wisselen