IPv6 Poortfiltering voor eigen webserver

[Iedjee]

Ik heb al lange tijd zonder problemen een eigen webserver op mijn Ziggo-aansluiting draaien op poort 80 en 443. Ik heb nu een nieuw modem, de Arris Connectbox met dualstack IPv4 en IPv6.

Op IPv4 is het makkelijk weer de poortforwarding in te stellen. Echter met IPv6 heb ik meer moeite om de poortfiltering (het openzetten van de firewall) voor elkaar te krijgen.

Het werkt alleen als ik een regel voor alle inkomende poorten en protocollen toevoeg, dat mag toch niet de bedoeling zijn? Ik zou verwachten dat alleen poort 80 en 443 voldoende zouden zijn. Zie het plaatje.



Ik heb alle mogelijke combinaties van andere protocollen geprobeerd maar dit geeft telkens geen verbinding van buitenaf. Blijkbaar zijn er extra TCP-poorten nodig voor IPv6? Weet iemand welke dat moeten zijn?

[Iedjee · Accepted solution]

Ik had al heel veel gezocht op internet, maar pas toen ik dit bericht poste keek ik nog eens naar het plaatje en zag ik dat de source-poort helemaal niet 80 of 443 hoeft te zijn. Een client op internet kan namelijk via een willekeurige TCP-poort komen!

Het is dus goed te configureren door de source-poorten 1 t/m 65535 toe te staan naar poort 80 en 443. Zie het plaatje. Ik denk dat dit een goede how-to is voor meerdere mensen met dit probleem.

[Mark]

Haha, goed bezig Iedjee!

Maar volgens mij heb je nu alsnog je webserver blootgesteld aan alle verkeer (net zoals in het eerste screenshot). Laat ik voorop stellen dat ik hier geen enkele ervaring mee heb zelf, maar dat zal zo wel moeten veranderen.

Als je terug gaat naar je 1e poging, waarbij je alleen poort 80 en 443 (intern + extern) specificeert. Kun je dan je webserver benaderen via http://[ipv6 adres webserver]:80 (inclusief de brackets om je ipv6 adres heen!)?

Hebben jullie hier misschien meer ervaring mee caesar Jonathan-458 ArieKanarie?

[caesar]

Ik kijk met verbijstering naar de IPv6 poort-filtering voorbeelden die hier getoond worden. Ik heb geen Connectbox, en zo te zien mag ik daar blij mee zijn.

De ontwikkelaars van de Connectbox snappen blijkbaar niet hoe IPv6 dient te werken. Hoe anders is het te verklaren dat zij een soort van halve NAT toepassen, met poortomzetting ?!?.

Als je een webserver met IPv6 adres 1234 hebt op je LAN, en je gebruikt gewoon poort 80 voor die webserver, dan zou je op de router niets anders moeten doen dan dan voor adres 1234 poort 80 openzetten. Punt, einde, geen poortomzetting, dat slaat nergens op.

Je behoort op je router alleen die poorten van adres 1234 open te zetten die van buitenaf benaderd moeten kunnen worden, dat is doodsimpel.

De screendump opzet kan natuurlijk nooit werken.

Als iemand van buitenaf via poort 443 een verbinding probeert op te bouwen, dan wordt deze door de eerste regel doorverwezen naar poort 80. Immers alle poorten (1 t/m/ 65535) worden doorverwezen naar poort 80.

De tweede regel is compleet zinloos, want alles wordt al via de eerste regel afgehandeld. Waarom de Connectbox die configuratie regel accepteert is mij een raadsel, regel 1 en regel 2 zijn 100% strijdig.

Een cliënt op het internet moet de poort aanspreken waarop de voor hem bedoelde service draait. Voor HTTP is dat poort 80, voor HTTPS is dat poort 443. Die poorten moeten dus openstaan, en bij die malle Connectbox moet je dus opgeven source port 80:80 - > destination port 80. Hoe je bij destination port een range van poort nummers op kan geven is mij ook een raadsel. Moet de router zelf maar kiezen welke poort uit die range gekozen moet worden??????? Wonderbaarlijk.

Het spijt mij te moeten zeggen dat mijn opinie over de Ziggo routers weer eens bevestigd is. En dan roept Ziggo dat ze alleen Ziggo routers willen toestaan op hun kabel vanwege de veiligheid en de hoge kwaliteit van die routers.

[Jbr67]

caesar wrote:
.

Als iemand van buitenaf via poort 443 een verbinding probeert op te bouwen, dan wordt deze door de eerste regel doorverwezen naar poort 80. Immers alle poorten (1 t/m/ 65535) worden doorverwezen naar poort 80.

De tweede regel is compleet zinloos, want alles wordt al via de eerste regel afgehandeld. Waarom de Connectbox die configuratie regel accepteert is mij een raadsel, regel 1 en regel 2 zijn 100% strijdig.

caesar en Mark Ziggo
Beetje late reactie wellicht..kwam hier via via terecht.

Ik lees dit toch iets anders. Die source poorten die genoemd worden zijn de source poorten van de CLIENT. Er wordt dus niet (halfslachtig) geforward , nee, er wordt gefilterd op bron poort (client) en bestemmingspoort (van de server van TS). De config die er staat is dus gewoon goed. Nah ja..volgens mij is 1024+ ook prima als sourcepoorten. Of helemaal leeglaten, net zoals de kolom afzender IP-adres. Daarnaast.. de routerleverancier mag ook wel wat consistenter zijn in de naamgeving. Hanteer in beide kolommen afzender cq source, maar ga niet lopen mengen. Zelfde voor bestemming/destination. Dat geeft alleen maar verwarring.

Kortom: TS heeft idd de juiste oplossing beschreven.

Groet,
Jbr67

[caesar]

De naamgeving op dit scherm is ietwat ongelukkig, dus ik begrijp hoe je tot deze conclusie komt.

Wat er eigenlijk zou moeten staan is 'poort die de source aanroept'. Het werkt net zo als bij IPv4 port forwarding.

De source port die jij bedoeld kan van alles zijn. Stel je voor dat een client zowel telnet, als ftp, http en https kan gebruiken. Bij ieder van die protocollen zal hij een willekeurige poort als afzender gebruiken. Hoe wil je dan ooit vaststellen naar welke destination port dat verkeer naar toe moet, bij jouw redenering?

[Mark]

caesar wrote:
Hoe wil je dan ooit vaststellen naar welke destination port dat verkeer naar toe moet, bij jouw redenering?

Hm, staat dat niet gewoon in het pakketje?

Aangezien dit geen forward is maar een filter wordt er niets gerouteerd. Er wordt alleen een uitzonderingsregel ingesteld in de firewall waarmee bepaald IPv6 verkeer wél doorgelaten wordt.
Dus een pakketje die de webserver wil bereiken via http stuurt een verzoek met 'destination port' 80 en daarbij kan de 'source port' van alles zijn?

caesar wrote:
Als iemand van buitenaf via poort 443 een verbinding probeert op te bouwen, dan wordt deze door de eerste regel doorverwezen naar poort 80.

Dit klopt dus niet volgens mij, want het is geen forward. Iemand van buiten probeert verbinding met de server te krijgen via 'destination port' 443 en dat wordt doorgelaten door de tweede filter regel (in het 1e screenshot van TS).


Verbeter me alsjeblieft als ik het fout heb.

[Jbr67]

Mark Ziggo wrote:

caesar wrote:
Hoe wil je dan ooit vaststellen naar welke destination port dat verkeer naar toe moet, bij jouw redenering?

Hm, staat dat niet gewoon in het pakketje?

Aangezien dit geen forward is maar een filter wordt er niets gerouteerd. Er wordt alleen een uitzonderingsregel ingesteld in de firewall waarmee bepaald IPv6 verkeer wél doorgelaten wordt.
Dus een pakketje die de webserver wil bereiken via http stuurt een verzoek met 'destination port' 80 en daarbij kan de 'source port' van alles zijn?

caesar wrote:
Als iemand van buitenaf via poort 443 een verbinding probeert op te bouwen, dan wordt deze door de eerste regel doorverwezen naar poort 80.

Dit klopt dus niet volgens mij, want het is geen forward. Iemand van buiten probeert verbinding met de server te krijgen via 'destination port' 443 en dat wordt doorgelaten door de tweede filter regel (in het 1e screenshot van TS).


Verbeter me alsjeblieft als ik het fout heb.

Dit is precies zoals ik het ook zie Marc!

Sourcepoort is trouwens in de regel 1024+ (beetje afhankelijk van OS van de client)

[caesar]

Mark Ziggo wrote:

caesar wrote:
Hoe wil je dan ooit vaststellen naar welke destination port dat verkeer naar toe moet, bij jouw redenering?

Hm, staat dat niet gewoon in het pakketje?

Ja, dat klopt. En daar wil je juist op filteren!! Niet op de sourceport waar jullie naar kijken, die is toch volstrekt irrelevant?

Aangezien dit geen forward is maar een filter wordt er niets gerouteerd.

Dit wordt ook wel IPv6 port forwarding genoemd. Verder is een NAT router ook geen router, hij routeert niet. Wat hij doet is Network Address Translation (en Port Translation), en dat heeft niets met 'echt' routeren te maken.

Er wordt alleen een uitzonderingsregel ingesteld in de firewall waarmee bepaald IPv6 verkeer wél doorgelaten wordt.

Dat is inderdaad de bedoeling, maar dat kan alleen als je filtert op destination port, en in jullie voorstelling van zaken wordt er nergens geselecteerd op destination port, alleen op een volstrekt irrelevante source port.

Dus een pakketje die de webserver wil bereiken via http stuurt een verzoek met 'destination port' 80 en daarbij kan de 'source port' van alles zijn?

Inderdaad, en daarom is een filter op 'source port' dus redelijk onzinnig.

caesar wrote:
Als iemand van buitenaf via poort 443 een verbinding probeert op te bouwen, dan wordt deze door de eerste regel doorverwezen naar poort 80.

Dit klopt dus niet volgens mij, want het is geen forward. Iemand van buiten probeert verbinding met de server te krijgen via 'destination port' 443 en dat wordt doorgelaten door de tweede filter regel (in het 1e screenshot van TS).

Nee, daar komt de filtering nooit aan toe, tenzij je denkt dat het filter van toepassing is op jullie source port en de destination port gelijktijdig. Maar waarom wil je in vredesnaam op jullie source port filteren? welke zin heeft dat als het een volstrekt willekeurig port is?

Verbeter me alsjeblieft als ik het fout heb.

Dat denk ik inderdaad.

• Ik kan me geen enkele reden voorstellen om op 'jullie' source port te filteren.
  
• Omdat die ports min of meer willekeurig gekozen worden, is er ook geen enkel logisch filter voor te bedenken.
  
• Het gevolg is dat je, in jullie denkwijze, alle poorten toegang moet verlenen, dus in de praktijk filter je niet op 'jullie' source address.
  

Kortom, ik kan mij geen enkele logische reden voorstellen waarom je zou willen filteren op de combinatie van destination port + willekeurige source port (in jullie denkwijze).

[caesar]

Ik wil er nog iets aan toevoegen.

Zelf heb ik een Fritz!box router achter een Cisco router in bridge mode. Aangezien Ziggo nog steeds niet in staat is om achter een router in bridge mode ook IPv6 te leveren, maak ik al vele jaren gebruik van een IPv6 tunnel.

Fritz!box routers hadden al IPv6, toen ze bij Ziggo nog niet eens wisten dat IPv6 bestond, dus ik ben zo vrij om het Fritz OS als referentie te kiezen voor de wijze waarop je IPv6 filtering moet opzetten. En dat is heel eenvoudig, je kiest voor een apparaat op je LAN een poortnummer (of een reeks van nummers), en kiest TCP of UDP als transport protocol, en je zet die poort open. Doodsimpel. Geen source en destination port numbers, of port number reeksen.

Ziggo levert jammer genoeg geen echte DOCSIS modems, waarachter je een eigen IPv4 + IPv6 router kunt opzetten. Dat zou al heel wat beter zijn dan die wrakke opzet van nu waarbij je geen IPv6 kunt krijgen als je een Ziggo router in bridge mode laat zetten (hoe bedenk je het om dergelijk rommel bij je klanten te plaatsen).

Ziggo zou er natuurlijk nog beter aan doen om al die rommelrouters die ze nu uitzetten, in de container te flikkeren, en ook Fritz!box cablerouters te gaan leveren, Al is het tegen bijbetaling, het kan me niet schelen. Ik heb het helemaal gehad met alle rommelrouters die ik in de loop van de jaren heb zien langskomen. Om het maar eens zo te stellen, een Connectbox vergelijken met een Fritz!box, is net zo als een derde hands Lada vergelijken met een nieuwe Rolls Royce.

Sorry dat ik het zo hard breng, maar als Ziggo claimt dat hun routers zo geweldig goed zijn dat het toestaan van 'vreemde' routers hun netwerk in gevaar brengt, omdat hun routers zo geweldig zijn, dan is dat wel een gotspe. Ziggo heeft nog nooit iets anders dan goedkope wrakke rommel uitgezet bij de klanten. Aan de coax kant zal alles wel goed getest geweest zijn, want anders had Ziggo daar zelf veel last van. Aan de LAN kant had iedere router wel ernstige bugs, maar Ziggo had daar nooit enige boodschap aan. Verbeteringen kon je naar fluiten.

Ik meen dus dat ik het recht heb om eens flink uit de slof te schieten.

[Jbr67]

caesar wrote:

Aangezien dit geen forward is maar een filter wordt er niets gerouteerd.

Dit wordt ook wel IPv6 port forwarding genoemd. Verder is een NAT router ook geen router, hij routeert niet. Wat hij doet is Network Address Translation (en Port Translation), en dat heeft niets met 'echt' roteren te maken.

Beetje semantische discussie dit.. nadat de NAT is uitgevoerd moet de router nog steeds kiezen op welk interface het pakket uit te sturen. Volgens mij heet dat routeren.

Dat is inderdaad de bedoeling, maar dat kan alleen als je filtert op destination port, en in jullie voorstelling van zaken wordt er nergens geselecteerd op destination port, alleen op een volstrekt irrelevante source port.

Zekers wel! Op poort 443 en 80 in dat voorbeeld!

Nee, daar komt de filtering nooit aan toe, tenzij je denkt dat het filter van toepassing is op jullie source port en de destination port gelijktijdig.

BINGO!

Maar waarom wil je in vredesnaam op jullie source port filteren? welke zin heeft dat als het een volstrekt willekeurig port is?

Netzoals je kunt filteren op source address. Bovendien, er zijn vast protocollen (over tcp/udp) waarbij het source poortnummer NIET willekeurig is!

Elke UDP/TCP pakket heeft
a) source address
b) source port
c) destination address
d) destination port

In gangbare scenario's is filteren op a en b naast c en d niet nodig (en kun je beide kolommen leeg laten). Maar als je dat wilt, dan kun je dus ook filteren op a,b,c en d gelijktijdig. Overigens; dit is een op een vergelijkbaar met extended acl's in bijv. cisco en hp routers.

Groet,
Jbr67

[Jbr67]

caesar wrote:
Ik wil er nog iets aan toevoegen.

Zelf heb ik een Fritz!box router achter een Cisco router in bridge mode. Aangezien Ziggo nog steeds niet in staat is om achter een router in bridge mode ook IPv6 te leveren, maak ik al vele jaren gebruik van een IPv6 tunnel.

Fritz!box routers hadden al IPv6, toen ze bij Ziggo nog niet eens wisten dat IPv6 bestond, dus ik ben zo vrij om het Fritz OS als referentie te kiezen voor de wijze waarop je IPv6 filtering moet opzetten. En dat is heel eenvoudig, je kiest voor een apparaat op je LAN een poortnummer (of een reeks van nummers), en kiest TCP of UDP als transport protocol, en je zet die poort open. Doodsimpel. Geen source en destination port numbers, of port number reeksen.

Ziggo levert jammer genoeg geen echte DOCSIS modems, waarachter je een eigen IPv4 + IPv6 router kunt opzetten. Dat zou al heel wat beter zijn dan die wrakke opzet van nu waarbij je geen IPv6 kunt krijgen als je een Ziggo router in bridge mode laat zetten (hoe bedenk je het om dergelijk rommel bij je klanten te plaatsen).

Ziggo zou er natuurlijk nog beter aan doen om al die rommelrouters die ze nu uitzetten, in de container te flikkeren, en ook Fritz!box cablerouters te gaan leveren, Al is het tegen bijbetaling, het kan me niet schelen. Ik heb het helemaal gehad met alle rommelrouters die ik in de loop van de jaren heb zien langskomen. Om het maar eens zo te stellen, een Connectbox vergelijken met een Fritz!box, is net zo als een derde hands Lada vergelijken met een nieuwe Rolls Royce.

Sorry dat ik het zo hard breng, maar als Ziggo claimt dat hun routers zo geweldig goed zijn dat het toestaan van 'vreemde' routers hun netwerk in gevaar brengt, omdat hun routers zo geweldig zijn, dan is dat wel een gotspe. Ziggo heeft nog nooit iets anders dan goedkope wrakke rommel uitgezet bij de klanten. Aan de coax kant zal alles wel goed getest geweest zijn, want anders had Ziggo daar zelf veel last van. Aan de LAN kant had iedere router wel ernstige bugs, maar Ziggo had daar nooit enige boodschap aan. Verbeteringen kon je naar fluiten.

Ik meen dus dat ik het recht heb om eens flink uit de slof te schieten.

Inhoudelijk ben ik het hier helemaal mee eens. En, Ziggo zet natuurlijk routers in waarbij de kostprijs een belangrijk/belangrijkste factor is. Dat betekent (bijna) altijd inleveren op kwaliteit.

Wat die fritzbox kennelijk doet is alleen filteren op destination parameters. In 99% van de gevallen voldoende. De ziggo box kan daar bovenop ook filteren op source paramaters. Standaard acl vs extended acl. Extra feature dus, die verwarrend kan werken.

Groet,
Jbr67

[Mark]

caesar wrote:
Ik meen dus dat ik het recht heb om eens flink uit de slof te schieten.

Dat mag ook, begrijp ik zelfs en heb er weinig aan toe te voegen.

Jbr67 wrote:
Net zoals je kunt filteren op source address. Bovendien, er zijn vast protocollen (over tcp/udp) waarbij het source poortnummer NIET willekeurig is!

Elke UDP/TCP pakket heeft
a) source address
b) source port
c) destination address
d) destination port

In gangbare scenario's is filteren op a en b naast c en d niet nodig (en kun je beide kolommen leeg laten). Maar als je dat wilt, dan kun je dus ook filteren op a,b,c en d gelijktijdig. Overigens; dit is een op een vergelijkbaar met extended acl's in bijv. cisco en hp routers.

Ik vermoed dat dit inderdaad klopt (zal het navragen bij de ontwikkelaars). Verder schiet mijn kennis tekort om een voorbeeld te kunnen noemen waarbij een filter op source port (eventueel i.c.m. destination port) wél wenselijk is.

[caesar]

Jbr67 wrote:

caesar wrote:

Aangezien dit geen forward is maar een filter wordt er niets gerouteerd.

Dit wordt ook wel IPv6 port forwarding genoemd. Verder is een NAT router ook geen router, hij routeert niet. Wat hij doet is Network Address Translation (en Port Translation), en dat heeft niets met 'echt' routeren te maken.

Beetje semantische discussie dit.. nadat de NAT is uitgevoerd moet de router nog steeds kiezen op welk interface het pakket uit te sturen. Volgens mij heet dat routeren.

Absoluut niet. Dat is bridging, en dat is op laag 2 van het OSI referentie model. Routeren is veel complexer, en vindt plaats op laag 3 van het OSI model.

Dat is inderdaad de bedoeling, maar dat kan alleen als je filtert op destination port, en in jullie voorstelling van zaken wordt er nergens geselecteerd op destination port, alleen op een volstrekt irrelevante source port.

Zekers wel! Op poort 443 en 80 in dat voorbeeld!

Nee, daar komt de filtering nooit aan toe, tenzij je denkt dat het filter van toepassing is op jullie source port en de destination port gelijktijdig.

BINGO!

Maar waarom wil je in vredesnaam op jullie source port filteren? welke zin heeft dat als het een volstrekt willekeurig port is?

Netzoals je kunt filteren op source address. Bovendien, er zijn vast protocollen (over tcp/udp) waarbij het source poortnummer NIET willekeurig is!

Elke UDP/TCP pakket heeft
a) source address
b) source port
c) destination address
d) destination port

In gangbare scenario's is filteren op a en b naast c en d niet nodig (en kun je beide kolommen leeg laten). Maar als je dat wilt, dan kun je dus ook filteren op a,b,c en d gelijktijdig. Overigens; dit is een op een vergelijkbaar met extended acl's in bijv. cisco en hp routers.

Groet,
Jbr67

En jij denkt echt dat complexe high-tech filtering op een Ziggo rommel router voor consumenten terecht komt, voor consumenten die geen flauw idee hebben van IP? Keep on dreaming.

Nee, consumenten kunnen hier niets mee. Consumenten programmatuur kan ook niet werken met fixed source ports, dat is iets voor heel specifiek programmatuur in bedrijfsomgevingen. Die domme Connectbox kan nog niet eens twee IPv6 subnetten uitdelen, naar ik gelezen heb. Dus van de 256 mogelijke subnetten kan hij er welgeteld één uitdelen. Wow.......

[Jbr67]

caesar wrote:

Beetje semantische discussie dit.. nadat de NAT is uitgevoerd moet de router nog steeds kiezen op welk interface het pakket uit te sturen. Volgens mij heet dat routeren.

Absoluut niet. Dat is bridging, en dat is op laag 2 van het OSI referentie model. Routeren is veel complexer, en vindt plaats op laag 3 van het OSI model.

No offense, maar het kiezen van de uitgaande interface (met een ander subnet-adres) en het doorsturen op een andere verbinding (met aanpassen van laag 2 MAC-adressen) is toch echt een key-aspect van routering.

caesar wrote:

En jij denkt echt dat complexe high-tech filtering op een Ziggo rommel router voor consumenten terecht komt, voor consumenten die geen flauw idee hebben van IP? Keep on dreaming.

Nou, complex en high-tech wil ik dit niet noemen (want dan moet je forwarding op basis van poorten en adressen dat ook noemen). Het is gewoon filtering.. op basis van 4 parameters (ipv 2). En met de komst van IPv6 is dat nodig. Kortom: dit aspect is gewoon goed in de betreffende router (mijn asus router heeft ook deze 4 parameters). Andere zaken zullen vast minder goed zijn in de betreffende connect-box ....

groet,
Jbr67

[Jbr67]

Mark Ziggo wrote:

caesar wrote:
Ik meen dus dat ik het recht heb om eens flink uit de slof te schieten.

Dat mag ook, begrijp ik zelfs en heb er weinig aan toe te voegen.

Jbr67 wrote:
Net zoals je kunt filteren op source address. Bovendien, er zijn vast protocollen (over tcp/udp) waarbij het source poortnummer NIET willekeurig is!

Elke UDP/TCP pakket heeft
a) source address
b) source port
c) destination address
d) destination port

In gangbare scenario's is filteren op a en b naast c en d niet nodig (en kun je beide kolommen leeg laten). Maar als je dat wilt, dan kun je dus ook filteren op a,b,c en d gelijktijdig. Overigens; dit is een op een vergelijkbaar met extended acl's in bijv. cisco en hp routers.

Ik vermoed dat dit inderdaad klopt (zal het navragen bij de ontwikkelaars). Verder schiet mijn kennis tekort om een voorbeeld te kunnen noemen waarbij een filter op source port (eventueel i.c.m. destination port) wél wenselijk is.

Een programmeur heeft iig de tools om dit programmeren:
https://stackoverflow.com/questions/2605182/when-binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reuse

En als het kan.. dan wordt het vast ook gebruikt. Een voorbeeld is dus feitelijk niet nodig.

Edit: toch een voorbeeld. https://www.cymru.com/jtk/misc/ephemeralports.html
(in dit geval gaat het om SOURCE port-ranges die gelimiteerd zijn).

[caesar]

Jbr67 wrote:

caesar wrote:

Beetje semantische discussie dit.. nadat de NAT is uitgevoerd moet de router nog steeds kiezen op welk interface het pakket uit te sturen. Volgens mij heet dat routeren.

Absoluut niet. Dat is bridging, en dat is op laag 2 van het OSI referentie model. Routeren is veel complexer, en vindt plaats op laag 3 van het OSI model.

No offense, maar het kiezen van de uitgaande interface (met een ander subnet-adres) en het doorsturen op een andere verbinding (met aanpassen van laag 2 MAC-adressen) is toch echt een key-aspect van routering.

Even ter verduidelijking:

Een CE router heeft een router module die aan één kant aan de WAN poort hangt, en aan de andere kant met een virtuele poort aan een 4-poorts LAN switch. Naar welke fysieke poort het verkeer uiteindelijk toegaat wordt dus bepaald m.b.v. bridging, niet routering. Anders zouden die poorten onderling ook moeten routeren, en dat doen ze niet.

caesar wrote:

En jij denkt echt dat complexe high-tech filtering op een Ziggo rommel router voor consumenten terecht komt, voor consumenten die geen flauw idee hebben van IP? Keep on dreaming.

Nou, complex en high-tech wil ik dit niet noemen (want dan moet je forwarding op basis van poorten en adressen dat ook noemen). Het is gewoon filtering.. op basis van 4 parameters (ipv 2). En met de komst van IPv6 is dat nodig. Kortom: dit aspect is gewoon goed in de betreffende router (mijn asus router heeft ook deze 4 parameters). Andere zaken zullen vast minder goed zijn in de betreffende connect-box ....

groet,
Jbr67

Ik zie absoluut niet in waarom dit bij IPv6 nodig zou zijn. Het zegt 99,99% van de consumenten helemaal niets, en ze kunnen er ook niets mee. Het is alleen maar verwarrend.

[Jbr67]

caesar wrote:


Even ter verduidelijking:

Een CE router heeft een router module die aan één kant aan de WAN poort hangt, en aan de andere kant met een virtuele poort aan een 4-poorts LAN switch. Naar welke fysieke poort het verkeer uiteindelijk toegaat wordt dus bepaald m.b.v. bridging, niet routering. Anders zouden die poorten onderling ook moeten routeren, en dat doen ze niet.

Correct! (Gaat beetje off topic dit, maar toch). Hoe noemt men het overzetten het pakket van ene interface (WAN-interface) naar de andere interface (virtuele LAN interface). Van het ene subnet naar het andere? Juist. Routing (switches weten niets van layer 3 properties). Dat er daarna ook nog switching komt is en logisch en irrelevant.

caesar wrote:

En jij denkt echt dat complexe high-tech filtering op een Ziggo rommel router voor consumenten terecht komt, voor consumenten die geen flauw idee hebben van IP? Keep on dreaming.

Sja... het staat er toch echt...



kan het ook niet anders maken.

caesar wrote:

Ik zie absoluut niet in waarom dit bij IPv6 nodig zou zijn. Het zegt 99,99% van de consumenten helemaal niets, en ze kunnen er ook niets mee. Het is alleen maar verwarrend.

Sja, waarom is er nu portforwarding nodig? Om diensten die op je LAN aanwezig zijn te ontsluiten naar de rest van de wereld. Om precies dezelfde reden is filtering nodig bij IPv6. Je wilt niet dat de hele wereld bij al jou interne devices kan, en al helemaal niet met alle poorten.

Dat portforwarding verwarrend is (en ws. filtering ook) dat blijkt idd wel uit de vele vragen hier in de diverse fora. Wat dat betreft ook een beetje goed niews..... filtering is net wat eenvoudiger dan forwarding. (omdat poortnummers niet veranderen)

Ciao,
Jbr67

[caesar]

Jbr67 wrote:

caesar wrote:


Even ter verduidelijking:

Een CE router heeft een router module die aan één kant aan de WAN poort hangt, en aan de andere kant met een virtuele poort aan een 4-poorts LAN switch. Naar welke fysieke poort het verkeer uiteindelijk toegaat wordt dus bepaald m.b.v. bridging, niet routering. Anders zouden die poorten onderling ook moeten routeren, en dat doen ze niet.

Correct! (Gaat beetje off topic dit, maar toch). Hoe noemt men het overzetten het pakket van ene interface (WAN-interface) naar de andere interface (virtuele LAN interface). Van het ene subnet naar het andere? Juist. Routing (switches weten niets van layer 3 properties). Dat er daarna ook nog switching komt is en logisch en irrelevant.

Jawel, maar jij schreef:

No offense, maar het kiezen van de uitgaande interface (met een ander subnet-adres) en het doorsturen op een andere verbinding (met aanpassen van laag 2 MAC-adressen) is toch echt een key-aspect van routering.

Daarmee suggereerde je dat door middel van routering één van de vier LAN poorten gekozen zou worden, en dat is onjuist. Er is geen keuze van interface, want bij slechts één mogelijke uitgaande (virtuele) interface valt er bar weinig te kiezen.

Ik heb ook geen idee wat je bedoeld met aanpassen van laag 2 MAC-adressen. Immers, routeren heeft niets te maken met MAC adressen, dat gaat uitsluitend op basis van IP adressen. Een uitgaande seriële interface bijvoorbeeld, zou helemaal geen MAC adres hebben.

caesar wrote:

En jij denkt echt dat complexe high-tech filtering op een Ziggo rommel router voor consumenten terecht komt, voor consumenten die geen flauw idee hebben van IP? Keep on dreaming.

Sja... het staat er toch echt...



kan het ook niet anders maken.

Mogelijk, hebben ze waarschijnlijk bij een andere leverancier gezien, en toen maar over genomen, onder het motto "waar het goed voor is weten we niet, maar het staat heel interessant'.

caesar wrote:

Ik zie absoluut niet in waarom dit bij IPv6 nodig zou zijn. Het zegt 99,99% van de consumenten helemaal niets, en ze kunnen er ook niets mee. Het is alleen maar verwarrend.

Sja, waarom is er nu portforwarding nodig? Om diensten die op je LAN aanwezig zijn te ontsluiten naar de rest van de wereld. Om precies dezelfde reden is filtering nodig bij IPv6. Je wilt niet dat de hele wereld bij al jou interne devices kan, en al helemaal niet met alle poorten.

Dat portforwarding verwarrend is (en ws. filtering ook) dat blijkt idd wel uit de vele vragen hier in de diverse fora. Wat dat betreft ook een beetje goed niews..... filtering is net wat eenvoudiger dan forwarding. (omdat poortnummers niet veranderen)

Ciao,
Jbr67

Ja, natuurlijk wil je IPv6 verkeer filteren, maar op destination port! Als je een webserver op je LAN opzet, dan kunnen anderen er met een browser naar toe. Wie maakt zich dan druk over source poorten??? Die kan een consument toch helemaal niet kiezen??? Je kunt overal op filteren, maar het moet wel zinvol zijn.

IPv4 port forwarding is weer zo'n typische lelijke oplossing geboren uit noodzaak. Dat is de ellende in ICT land, we worden bedolven onder de halfbakken klungel oplossingen omdat zaken niet fundamenteel goed opgezet zijn.

[Jbr67]

caesar wrote:

Jawel, maar jij schreef:

No offense, maar het kiezen van de uitgaande interface (met een ander subnet-adres) en het doorsturen op een andere verbinding (met aanpassen van laag 2 MAC-adressen) is toch echt een key-aspect van routering.

Daarmee suggereerde je dat door middel van routering één van de vier LAN poorten gekozen zou worden, en dat is onjuist. Er is geen keuze van interface, want bij slechts één mogelijke uitgaande (virtuele) interface valt er bar weinig te kiezen.

Nou, mijn laatste reactie hier. TS is allang van zijn probleem af, op de juiste manier, en dit gaat inmiddels behoordelijk offtopic.

Ik heb nergens gesuggereerd dat er een LANpoort gekozen moest worden. Dat is ook niet zo. Ik heb het alleen over het kiezen van een uitgaande interface. Niet meer en niet minder.
Zekers is er wel een keuze. Op het moment dat het pakket in de routing engine komt, zal deze op basis van destination address een lookup doen in de routing table. Daarin staan alle bekende routes en de bijbehorende -al dan niet virtuele- interfaces (per definitie 2 of meer, bij een consumenten ziggo ding een WAN en een virtulele richting het LAN). Dus er valt wel degelijk te kiezen. Per definitie. Altijd! Anders is het geen router. Er is mij ook geen enkele rfc bekend die aangeeft dat een ontvangen pakket niet weer op dezelfde interface als waar het pakket op ontvangen is, weggestuurd mag worden.

Ik heb ook geen idee wat je bedoeld met aanpassen van laag 2 MAC-adressen. Immers, routeren heeft niets te maken met MAC adressen, dat gaat uitsluitend op basis van IP adressen. Een uitgaande seriële interface bijvoorbeeld, zou helemaal geen MAC adres hebben.

Hmmm, zuiverder was geweest laag 2(-MAC) adressen. Er zijn verbindingen die geen MAC-fundament. Maar ook op seriële verbindingen worden wel degelijk laag 2 adressen, bijv. in HDLC en ook in PPP.
Wat ik bedoelde is niet zo ingewikkeld. Als een datagram overgaat van het ene subnet naar het andere subnet (dat is routing), blijven van datagram de laag 3 adreseigenschappen hetzelfde (behalve bij NAT) de laag 2 adressen veranderen steeds (want zijn speciek voor dat laag2 domein).

Sja... het staat er toch echt...



kan het ook niet anders maken.

Mogelijk, hebben ze waarschijnlijk bij een andere leverancier gezien, en toen maar over genomen, onder het motto "waar het goed voor is weten we niet, maar het staat heel interessant'.

"Mogelijk?"
Nee.. het staat er gewoon. Zwart (groen) op wit. Geen idee waar en hoe ze dat hebben bedacht... ik was er iig niet bij.

IPv4 port forwarding is weer zo'n typische lelijke oplossing geboren uit noodzaak. Dat is de ellende in ICT land, we worden bedolven onder de halfbakken klungel oplossingen omdat zaken niet fundamenteel goed opgezet zijn.

Forwarding is idd lelijk omdat het het end-2-end karakter van IP kapot maakt. De founding father van de internet-technieken (Vinten Cerf en Bob Kahn) vonden 32 bit genoeg voor de expirementfase .. (https://www.youtube.com/watch?v=17GtmwyvmWE&feature=share&t=26m18s). Maar, het experiment is productie geworden. Ondanks dat is het gelukt om een wereldwijde standaard neer te zetten waarmee miljarden mensen dag in dag uit zeer intensief gebruik van maken. Elke internet gebruiker, waar ook ter wereld, kan daarom nu deze tekst lezen (ok; Tim Berners Lee als founding father van het WWW moet ik dan ook noemen). En dat voor iets dat 45 jaar geleden is bedacht! Ik vind dat een ZEER INDRUKWEKKENDE prestatie met een impact van ONGEKENDE omvang.
Dus om deze makers (ze hebben beide heel veel prijzen gewonnen, waaronder ook ACM = nobelprijs voor ICT) als halfbakken klungels neer te zetten komt op mij niet heel respectvol en genuanceerd over. Datzelfde geldt voor je opmerking over ICT-land.

Aangezien de oplossing van TS werkt en omdat ik merk dat ik hier weinig energie krijg, laat ik het hierbij in dit draadje.

Groet,
Jbr67