ipv6 + intern v4

Heb je problemen met het instellen van je netwerk, bedraad of draadloos, dan kan je hier altijd terecht!
Plaats reactie
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

simpel gezegd: ik wil ipv6 wel gebruiken, maar wil het enkel extern.
dus ik zoek een manier om énkel op de router/firewall/gateway een ipv6 adres te hebben (is al in orde, natuurlijk) en intern gewoon v4...
maar dat het verkeer waar mogelijk toch over ipv6 gaat en dan intern terug vertaald zou worden naar v4.

ik zie public ip's op mijn lan nu eenmaal niet zitten, en het gebruik van de fc0 adressen krijg ik ook niet aan het werken om een of andere reden.

iemand die dus een idee/voorstel heeft voor deze setup?

kort beschreven wil ik:

bbox => opnsense wan port met ipv6 => opnsense lan port met v6/v4 => heel het lan gebeuren met enkel v4
(en verkeer dus -waar mogelijk- over ipv6)
dovo
Plus Member
Plus Member
Berichten: 118
Lid geworden op: 28 nov 2015, 21:18
Uitgedeelde bedankjes: 13 keer
Bedankt: 39 keer

Bedoel je hiermee nat46 en dns46? ( http://www.brocade.com/content/html/en/ ... 5106E.html )

Dat ga je denk ik in bijna geen enkel product vinden.

Ik zie echter ook totaal geen reden waarom je dat zou doen. Alsook nat66 naar fc00::/7 RFC4193 adres heeft helemaal geen nut en is ook niet de bedoeling. fc00::/7 adressen bestaan om bijvoorbeeld een server intern een adres te geven, terwijl je van je ISP een dynamisch ipv6 subnet krijgt.
Het punt van ipv6 is juist dat je een publiek adres hebt per toestel zodat de router zijn resources niet aan NAT besteed moeten worden, alsook snellere throughput, correcte ipsec ondersteuning... Nat is juist uitgevonden omdat er te weinig ipv4 adressen zijn, oorspronkelijk was een publiek ipv4 voor ieder toestel bedoeld.

En als security echt belangrijk is voor je, gebruik dan pfsense in plaats van opnsense.

Wil je toch per sé absoluut geen enkel ipv6 in je lan, maar wel externe ipv6 connectiviteit, draai dan een transparent proxy in pfsense die aan de buitenkant een ipv6 en ipv4 adres heeft. Bijvoorbeeld squid. Op die manier kan je je web trafiek vanaf de router over ipv6 laten gaan.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

dovo schreef:Het punt van ipv6 is juist dat je een publiek adres hebt per toestel
sja, en dan 1 kleine overkeken zaak en je hele netwerk is kwetsbaar...
bv, mijn chinacams zijn intern op mijn netwerk, hebben elk een intern ip, en zijn verbonden met een nvr.
echter kan je ze niet "verstoppen" achter die nvr: ze halen hun ip steeds rechtstreeks van de modem (itt bv hikvision cam/nvr setups).
met gebruik van interne ips en een firewall met 2 simpele regels (blokkeer alles, laat poort x op host y door) is dat done.

met ipv6 is dat ook wel zo in theorie, i know... maar als ik het niet publiek toegankelijk wil... waarom zou ik het dan een publiek routeerbaar ip geven?
beetje zoals een wagen waarmee je nooit zal rijden inschrijven: absurd gewoon.
om nog maar te zwijgen van het feit dat ik mijn ip's op mijn netwerk vanbuiten ken + ingedeeld heb volgens type met aparte ranges.
iets dat ik me voor ipv6 (die dan nog eens dynamisch worden uitgedeeld door je provider...) niet dadelijk zie doen.
dovo schreef:En als security echt belangrijk is voor je, gebruik dan pfsense in plaats van opnsense.
bronnen van issues waardoor opnsense niet veilig zou zijn? (en kom niet aan met vooroordelen of dergelijke: als je beweert dat pfsense veiliger is, wil ik weten waar opnsense technisch tekort zou schieten)
dovo schreef:Wil je toch per sé absoluut geen enkel ipv6 in je lan, maar wel externe ipv6 connectiviteit, draai dan een transparent proxy....
een proxy lijkt idd een beetje de enige oplossing, maar dat is ook weer niet ideaal natuurlijk
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef:simpel gezegd: ik wil ipv6 wel gebruiken, maar wil het enkel extern.
dus ik zoek een manier om énkel op de router/firewall/gateway een ipv6 adres te hebben (is al in orde, natuurlijk) en intern gewoon v4...
maar dat het verkeer waar mogelijk toch over ipv6 gaat en dan intern terug vertaald zou worden naar v4.

ik zie public ip's op mijn lan nu eenmaal niet zitten, en het gebruik van de fc0 adressen krijg ik ook niet aan het werken om een of andere reden.

iemand die dus een idee/voorstel heeft voor deze setup?

kort beschreven wil ik:

bbox => opnsense wan port met ipv6 => opnsense lan port met v6/v4 => heel het lan gebeuren met enkel v4
(en verkeer dus -waar mogelijk- over ipv6)
Gewoon deftige rules om inbound IPv6 te filteren implementeren? Basically alles filteren behalve state en een paar ICMP types. Is dat niet meer KISS dan jouw voorstel met translation IPV4-IPV6? Het is wat ik doe en tot nu toe probleemloos.

Als je je devices in je eigen netwerk niet vertrouwt is de "geen publiek IPV6"-adres eerder een symptomatische aanpak dan een oorzakelijke. Het zal enkel een false sense of security dienen. Zoals dovo ook al aanhaalde. Als je hun state connections ook niet vertrouwt, wat doen ze dan eigenlijk nog op je netwerk?

NATting != SECURITY !!!!!
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

het is geen kwestie van devices wel of niet vertrouwen (al is de beste aanpak altijd -imho- devices standaard niet te vertrouwen),
het is een kwestie van

- geen publiek routeerbare adressen in mijn lan te willen
- geen ruimte in mijn hoofd te hebben om ipv6 adressen voor al mijn devices vanbuiten te gaan leren
- niet afhankelijk wil zijn van ip's toegekend door mijn isp (stel je leert je ipv6 toewijzingen vanbuiten per device... je gaat naar een andere provider, begin maar opnieuw...)
- het "zoveel mogelijk filteren om het probleem op te lossen" is volgens mij net de symptoombehandeling, want je moet dat gaan doen omdat je je setup gaat aanpassen met routeerbare adressen.

mijn mening is gewoon dat iets dat niet publiek moet zijn, ook niet publiek gerouteerd moet worden. en heb je 1 specifieke port op dat device dat wel routeerbaar moet zijn... dan doe je dat door een forward in de firewall. niet door het device standaard publiek te maken en dicht te timmeren wat niet publiek hoeft...

ik heb ook helemaal geen zin om een welles/nietes spelletje v4 vs v6 te gaan doen, ik wil gewoon een simpele, liefst zo elegant mogelijke oplossing om INTERN *zelf* de volledige controle te houden over mijn netwerk - en daar valt ook adressering onder.
CCatalyst schreef:NATting != SECURITY !!!!!
zeg ik dat dan ergens?
sterker nog, ik heb helemaal niet gevraagd naar security, maar naar een oplossing voor het behouden van v4 op mijn lan terwijl ik toch v6 kan gebruiken naar internet toe...

ga jij maar gezellig v6 ip's vanbuiten leren, en dan opnieuw als je provider kiest om de toegekende range te veranderen...
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef: sterker nog, ik heb helemaal niet gevraagd naar security
Dat je NAT gebruikt als security feature leid ik vooral hier uit af:
Splitter schreef:
dovo schreef:Het punt van ipv6 is juist dat je een publiek adres hebt per toestel
sja, en dan 1 kleine overkeken zaak en je hele netwerk is kwetsbaar...
bv, mijn chinacams zijn intern op mijn netwerk, hebben elk een intern ip, en zijn verbonden met een nvr.
echter kan je ze niet "verstoppen" achter die nvr: ze halen hun ip steeds rechtstreeks van de modem (itt bv hikvision cam/nvr setups)
Het is niet echt welles/nietes, het gaat hier gewoon over de verschillen tussen IPv6 en IPv4. Wat jij wilt is address translation, maw NATting op IPv6. Zoals eerder al aangehaald is NATting ontworpen om tijdelijk de shortage in IPv4 op te vangen. Het is NIET ontworpen voor wat jij er mee wilt bereiken (aka: om te gebruikt worden als security feature omdat je geen publieke IP's hebt), ook al lukt dat nu wel. IPv6 is de definitieve oplossing voor die shortage in IPv4. NATting is daar gewoon geen deel meer van, en firewall filteren is wel degelijk de standaard oplossing om kwetsbare devices in je LAN te beschermen, wat het trouwens altijd al geweest is, ook bij NATting. Dat is net ook het hele punt van een firewall.

Je zal het jezelf gewoon heel moeilijk maken door per se die NATting te willen forceren op IPv6. Er zullen wel oplossingen zijn, maar afaik werkt het allemaal heel krakkemikkig. Je kan een 6in4 tunnel maken in je eigen netwerk misschien (hopelijk ondersteunt je software dat), of als dat niet lukt, desnoods naar een andere provider a la HE.NET? Het zal je aan throughput kosten natuurlijk, en waarom doet Telenet dan nog de moeite om iedereen IPv6 te geven?

Soit, ik wil niet te veel oordelen en ik snap wel waarom je het doet, maar ik vrees dat het moeilijk zal zijn (niet onmogelijk). KISS is gewoon om alle protocollen te gebruiken zoals ze bedoeld zijn, en geen IPv4-artefacten te forceren op IPv6. Dat je netwerk publiek routable zal zijn, da's nu eenmaal IPv6 en da's de toekomst voor ons allemaal, sterker nog, dat is zelfs de bedoeling van het internet en ik heb nog de tijd geweten dat dat zelfs onder IPv4 nog zo was met Telenet (enfin, Pandora) met hun consumentenabo's met 4 IPv4's inbegrepen etc. De firewall dient dan om dat netwerk goed af te dekken.
dovo
Plus Member
Plus Member
Berichten: 118
Lid geworden op: 28 nov 2015, 21:18
Uitgedeelde bedankjes: 13 keer
Bedankt: 39 keer

Splitter schreef: sja, en dan 1 kleine overkeken zaak en je hele netwerk is kwetsbaar...
bv, mijn chinacams zijn intern op mijn netwerk, hebben elk een intern ip, en zijn verbonden met een nvr.
echter kan je ze niet "verstoppen" achter die nvr: ze halen hun ip steeds rechtstreeks van de modem (itt bv hikvision cam/nvr setups).
met gebruik van interne ips en een firewall met 2 simpele regels (blokkeer alles, laat poort x op host y door) is dat done.

met ipv6 is dat ook wel zo in theorie, i know... maar als ik het niet publiek toegankelijk wil... waarom zou ik het dan een publiek routeerbaar ip geven?
Zal het een beetje verduidelijken: Het punt van ipv6 is juist dat je een publiek adres hebt per toestel dat internetconnectiviteit nodig heeft.
Als je ze niet een publiek ip wil geven omdat ze geen internet nodig hebben, geef ze dan een fc00::/7 RFC4193 adres, lees het artikel, de ingenieurs van de ietf hebben RFC4193 onder andere voor zulke zaken bedacht. Als het apparaat (beveiligingscamera) echter geen internet connectiviteit nodig heeft, dan kan je best ook gewoon rfc1918 adressen gebruiken zoals je aangeeft zijn die inderdaad makkelijk te onthouden en is het gebruik ervan totaal geen probleem in een dualstack setup. Ipv4 rfc1918 zullen we nog lang blijven gebruiken voor zaken zoals je hier aangeeft.

Bij ipv6 wordt standaard ook ND met router advertisements (neighbor discovery - RFC4861) gebruikt. Dat is verschillend van dhcp, maakt gebruik van wisselende adressen, een eventuele miscofiguratie in de firewall zal niet zo snel in problemen eindigen als dat bij ipv4 het geval is, aangezien het hier over een hele boel meer adressen gaat. Ipv6 kent ook dhcpv6, maar android ondersteund dat niet, dus je zal altijd ook ND met router advertisements moeten instellen wil je ook android devices werkende krijgen?
bronnen van issues waardoor opnsense niet veilig zou zijn?

post op reddit
post op reddit 2
Kort samengevat: Hun release cycle kent amper testing, waardoor er in het verleden al eens VLANS zijn gestopt met werken. In productie kan je zoiets absuluut niet hebben. De attitude van het bedrijf achter opnsense is naar mijn mening ook zeer kinderachtig (en dan heb ik het niet alleen over de reacties die nog op reddit staan).
ga jij maar gezellig v6 ip's vanbuiten leren, en dan opnieuw als je provider kiest om de toegekende range te veranderen...
Dns is een mogelijkheid om je toestellen steeds met hetzelfde adres te benaderen, ik kan thuis bijvoorbeeld alle toestellen benaderen op <hostname>.lan.intra Veranderd nooit, tenzij ik het verander.
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

dovo schreef: Bij ipv6 wordt standaard ook ND met router advertisements (neighbor discovery - RFC4861) gebruikt. Dat is verschillend van dhcp, maakt gebruik van wisselende adressen, een eventuele miscofiguratie in de firewall zal niet zo snel in problemen eindigen als dat bij ipv4 het geval is, aangezien het hier over een hele boel meer adressen gaat. Ipv6 kent ook dhcpv6, maar android ondersteund dat niet, dus je zal altijd ook ND met router advertisements moeten instellen wil je ook android devices werkende krijgen?
Hmm, Android nog steeds geen DHCPv6 support? Hoe doe je dan firewall filtering met android devices? Komen die dan altijd met hetzelfde autoconfig IPv6 adres? Ikzelf heb geen android devices.

Sommige devices wil ik ook niet publiek toegankelijk. Wat ik gewoon doe is "Managed address configuration" via de RA enerzijds, en dan via DHCPv6 static IPv6 adressen uitreiken aan de devices die ik helemaal niet publiek toegankelijk wil, die worden vervolgens volledig gefilterd door de firewall ahv hun IPv6 adres. Intern blijven die natuurlijk toegankelijk op het LAN. Ik heb momenteel geen devices die ik wel toegankelijk wil vanaf het WAN, maar dan zou ik gewoon dezelfde oplossing toepassen met aangepaste firewall rules. Alle andere devices krijgen random IPv6 adressen van de DHCPv6 en vallen dan onder de standaardrules: enkel state en een paar ICMP types mogen binnen.
dovo
Plus Member
Plus Member
Berichten: 118
Lid geworden op: 28 nov 2015, 21:18
Uitgedeelde bedankjes: 13 keer
Bedankt: 39 keer

Hmm, Android nog steeds geen DHCPv6 support? Hoe doe je dan firewall filtering met android devices? Komen die dan altijd met hetzelfde autoconfig IPv6 adres? Ikzelf heb geen android devices.
Je kan gewoon geen Android devices hetzelfde autoconfig adres geven, en ene Lorenzo bij google blokkeert zelfs commits aan het Android project die RFC compliant dhcpv6 support inbouwen. Tot nu toe is de fairphone de enige Android die dhcpv6 ondersteund (omdat fairphone het zelf inbouwt.)
Waar die Lorenzo goed werk geleverd heeft op google hun globaal ipv6 netwerk, zou hij beter zich niet moeien met Android. Sommige Android devices willen niet eens verbinden met v6-only netwerken.

Aangezien android toestellen vaak niet of weinig updates krijgen zal het ontbreken van dhcpv6 op android nog lang voor problemen zorgen.
Sommige mensen zijn gewoon zo'n doorzettende betweters dat ze op een gegeven moment zichzelf nog gaan geloven te weten hoe het allemaal werkt, kijk maar naar Lorenzo bij google.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

dovo schreef: Zal het een beetje verduidelijken: Het punt van ipv6 is juist dat je een publiek adres hebt per toestel dat internetconnectiviteit nodig heeft.
Als je ze niet een publiek ip wil geven omdat ze geen internet nodig hebben, geef ze dan een fc00::/7 RFC4193 adres, lees het artikel, de ingenieurs van de ietf hebben RFC4193 onder andere voor zulke zaken bedacht. Als het apparaat (beveiligingscamera) echter geen internet connectiviteit nodig heeft, dan kan je best ook gewoon rfc1918 adressen gebruiken zoals je aangeeft zijn die inderdaad makkelijk te onthouden en is het gebruik ervan totaal geen probleem in een dualstack setup
dat is dus wat ik wil proberen... maar ik wil zélf bepalen welk toestel welk v4/v6 adres krijgt, en dit onafhankelijk van eender welke prefix hebben...
iets wat quasi onmogelijk lijkt - of althans toch niet zo simpel is.
ik wil gerust mee evolueren met v6, maar ik wil 0,0 toegeving doen op controle van mijn toestellen en welke adressen ze hebben.
dovo schreef: Dat is verschillend van dhcp, maakt gebruik van wisselende adressen, een eventuele miscofiguratie in de firewall zal niet zo snel in problemen eindigen als dat bij ipv4 het geval is, aangezien het hier over een hele boel meer adressen gaat.
een firewall is er om geen fouten in te maken... :)

dovo schreef: Kort samengevat: Hun release cycle kent amper testing, waardoor er in het verleden al eens VLANS zijn gestopt met werken. In productie kan je zoiets absuluut niet hebben. De attitude van het bedrijf achter opnsense is naar mijn mening ook zeer kinderachtig (en dan heb ik het niet alleen over de reacties die nog op reddit staan).
hmm... dat is idd minder, maar toch blijf ik liever bij opnsense simpelweg omdat ze (imho) een gui hebben met een veel vlottere workflow.
dovo schreef: Dns is een mogelijkheid om je toestellen steeds met hetzelfde adres te benaderen, ik kan thuis bijvoorbeeld alle toestellen benaderen op <hostname>.lan.intra Veranderd nooit, tenzij ik het verander.
gebruik ik intern ook (home.lan), maar dat wil niet zeggen dat ik de ip's niet vanbuiten wil kennen :)
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef:
dovo schreef: Zal het een beetje verduidelijken: Het punt van ipv6 is juist dat je een publiek adres hebt per toestel dat internetconnectiviteit nodig heeft.
Als je ze niet een publiek ip wil geven omdat ze geen internet nodig hebben, geef ze dan een fc00::/7 RFC4193 adres, lees het artikel, de ingenieurs van de ietf hebben RFC4193 onder andere voor zulke zaken bedacht. Als het apparaat (beveiligingscamera) echter geen internet connectiviteit nodig heeft, dan kan je best ook gewoon rfc1918 adressen gebruiken zoals je aangeeft zijn die inderdaad makkelijk te onthouden en is het gebruik ervan totaal geen probleem in een dualstack setup
dat is dus wat ik wil proberen... maar ik wil zélf bepalen welk toestel welk v4/v6 adres krijgt, en dit onafhankelijk van eender welke prefix hebben...
iets wat quasi onmogelijk lijkt - of althans toch niet zo simpel is.
ik wil gerust mee evolueren met v6, maar ik wil 0,0 toegeving doen op controle van mijn toestellen en welke adressen ze hebben.
Geen idee met opnsense, maar in de DHCPv6 van pfSense definieer je gewoon een range van IP's dat je wilt uitdelen, en dan plakt hij zelf de prefix er aan, ook als die verandert. Als je zelf wilt bepalen welk adres het is kan je static mappings definieren, zelfde principe waarbij de prefix er door pfsense aan geplakt wordt. De dhcpv6d geeft dan het IP dat je wilt, zoals dat bij de klassieke dhcpd ook kan.

Een andere optie is een static DHCPv6 prefix, beschikbaar in sommige TN abo's (dezelfde abo's die ook een static IPv4 hebben).

Maar de caveat is blijkbaar dat Android dus (nog) niet meedoet met DHCPv6. Zelf heb ik verschillende toestellen (maar niets op Android OS) en allen werken ze wel met DHCPv6.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef: Als je zelf wilt bepalen welk adres het is kan je static mappings definieren, zelfde principe waarbij de prefix er door pfsense aan geplakt wordt. De dhcpv6d geeft dan het IP dat je wilt, zoals dat bij de klassieke dhcpd ook kan.
ik steek nu gewoon alles met dhcpv6 in de fd00 (private) range... probleem is dan dat ik ergens een firewall regel of routering/gw mis...
maar krijg hem niet zo dadelijk gevonden (sja, nieuw met pfsense/opnsense en mijn ipv6 kennis heeft zoveel stof zitten vergaren dat die terug de mist in gegaan is...)
firewall => ipv6 internet ok
lan clients => firewall v6 ok
lan clients => internet v6 nok
Gebruikersavatar
NuKeM
Administrator
Administrator
Berichten: 5491
Lid geworden op: 10 nov 2002, 00:55
Uitgedeelde bedankjes: 114 keer
Bedankt: 234 keer
Recent bedankt: 5 keer

Ik zit eigenlijk met dezelfde vraag als Splitter. Ik kan netjes mijn netwerk opdelen in VLANs en op basis daarvan beslissen wie aan wat mag (via router).
Zie ik het juist dat ik de router naast een ipv4 ook een publiek ipv6 kan laten krijgen samen met uitdeelbare ipv6 range, zodat bv in een ipv6 vlan hosts dan een publiek ipv6 krijgen via de ipv6dhcp van de router?
Hoe zit dat dan met security? Verhuist het gros van de verantwoordelijkheid naar de host, of kan ik mijn router(board) alles (eenvoudig) laten filteren (met verschillende Rules per vlan). M.a.w. het voordeel dat we hadden op ipv4 met één firewall waar alles langs moest op dezelfde machine als de Natting behouden?
Ben nogal nieuw in het ipv6 verhaal :)

Als mijn hosts het ondersteunen kan ik misschien in een vlan enkel lokale ipv6 adressen gebruiken (fe80 of wat was het)?
Ipv4 hosts (omdat die bv. geen ipv6 ondersteunen) kan ik die dan over één ipv6 krijgen (natten via publiek ipv6 van router?)

Teveel vragen en zero-kennis bij mezelf merk ik. Zal mij denk ik best eens bijscholen op ipv6 vlak en het dan in de praktijk omzetten :)
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

je kan je router idd een publiek ipv6 range laten krijgen, en dat datn uitdelen op je lan.
zo krijgen alle hosts in je lan een rechtstreeks routeerbaar ipv6 adres, maar blijft je firewall nog steeds verantwoordelijk voor de veiligheid.

meestal krijg je iets a la aaaa:bbbb:cccc:dddd::/64 (ik merk dat pxm de bbox zelfs een /56 geeft) - waarbij de overige 4 delen bestaan uit het mac adres van het toestel dat het adres heeft.

de lokale range is fd00::/8 (ULA), en dat is wat ik aan het proberen ben (ondertussen ook NPT ingesteld daarvoor),
maar als je toestel helemaal geen ipv6 zou ondersteunen, zou je al met proxy of NAT moeten werken en dat is dan weer niet aangeraden op ipv6 (daarom dus NPT ipv NAT voor de routering)


back to me:

- ik heb dus via de firewall wel ipv6 connectiviteit.
- diezelfde firewall deelt lokaal ULA's uit
- op mijn pc heb ik fd00:1::100 als adres gekregen via de dhcp6
- ik doe NPT om dat adres te vertalen naar een GUA met de toegekende prefix
- de firewall geeft mooi aan dat de regels doorgelaten worden en vertaald zijn:
PASS Dec 17 09:31:18 WAN [2a02:a03f:2c24:2900:(mac)]:45940 [ipv6 site]:80 TCP:S

... maar ik krijg niets terug en werken doet het ook nog niet...
dovo
Plus Member
Plus Member
Berichten: 118
Lid geworden op: 28 nov 2015, 21:18
Uitgedeelde bedankjes: 13 keer
Bedankt: 39 keer

@Splitter: NPT lijkt inderdaad een geschikte manier om een lokale ipv6 range te vertalen naar je dynamische prefix van je provider. In RFC6296 kan je daar nog meer over vinden.
Ik denk dat het probleem is dat de site naar waar je probeert te connecteren niet terug geraakt naar jou toestel. Misschien firewall rule die inbound niet toestaat? (State = established)
Het kan ook zijn dat je router je prefix niet routeerd. (Je krijgt op je router een adres van je provider, bijvoorbeeld 2001:DB8:1111:2222:9999:8888:7777:4444 en je prefix 2001:DB8:1111:9800::/56 . Je router moet dus die prefix routeren met als next hop / static route ::/0
Hieronder een voorbeeld van een mikrotik op het telenet netwerk. We krijgen dus een prefix ::/56 die ik opdeel in twee ::/64 prefixen voor lokaal en gast VLAN met 2a02:1810:xxxx:xx00::69 en 2a02:1810:xxxx:xx10::69 als gateway voor de router advertisements in die vlan's.
Telenet geeft de router (bridge-WAN) een enkel adres uit hun 2a02:181f::/24 range, terwijl het lan netwerk een prefix ::56 uit hun 2a02:1810::/24 range krijgt.
Afbeelding
een pakketje naar buiten zal dus als volgt gaan:
PC > gateway ip lan 2a02:1810:xxxx:xx00::69/64 > ip router 2a02:181f:0:121:xxxx:xxxx:xxxx:36e3/64 > ip telenet router 2a02:181f:0:121::1/64 > telenet netwerk.

In jou geval gebruik je dus NPT, en dan zal alles wat zich aan jou kant van de router bevind anders verlopen. Een pakketje kan je router dus verlaten met als source adres een adres uit je eigen verkregen prefix, maar als het antwoord van de server komt moet die dus ook het adres van dat je voorheen hebt opgegeven als source adres kunnen vinden. Als je NPT deamon dus niet luistert naar de trafiek die binnen komt op die prefix, dan kan hij dit niet vertalen naar je lokale ipv6 adressen fd00::/8

@NuKeM: Slecht nieuws, mikrotik ondersteund op deze moment nog geen geen volledig dhcpv6 server zoals bijvoorbeeld pfsense dat doet. Je kan dus geen statische adresseringen geven aan bepaalde clients. Momenteel moet je dus nog altijd SLAAC gebruiken, maar aangezien android nog altijd geen dhcpv6 doet moet je sowieso altijd ook SLAAC doen wil je die devices ondersteunen.
In het antwoord hierboven heb ik ook al geprobeerd grotendeels jou vraag te beantwoorden.
Het is wel zo dat fe80 adressen link-local zijn, deze horen dus bij een bepaalde interface op je machine en niet te vergelijken met bijvoorbeeld 192.168.1.1 . Link-local is iets dat enkel bij ipv6 voorkomt, en niet bij ipv4.
Hieronder een voorbeeld van een bijhorende firewall, op de forums van mikrotik vind je wel welke opties er allemaal bij die rules horen:
Afbeelding
Alles gaat dus nog altijd langs één firewall, al je trafiek komt tenslotte nog altijd binnen via je router. Het enige verschil is dat je in plaats van
(Publiek ipv4 router > firewall & nat > lokaal ipv4 bv. 192.168.1.2) bij ipv4 ( publiek ipv6 router > firewall & routering > ipv6 subnet vlan ) gaat doen.
Een setup waarbij je een publiek outside ipv6 naar een lokaal inside ipv6 gaat vertalen met nat66 of NPT heeft geen nut in 99,99% van de gevallen en is enkel maar een verspilling van resources van je router. Zoals eerder hier ook is aangegeven NATting != SECURITY !!!!! Er is niets mis met een standaard ipv6 setup. Je kan statische fd00::/8 Unique Local Adressen toekennen aan lokale toestellen zoals bijvoorbeeld een active directory domain controller, security camera, mediaspeler ... zodat je deze steeds lokaal kan bereiken op hetzelfde adres, verandert je dynamische ipv6 prefix, dan moet je niet gaan hernummeren. Je gebruikt dus een ander adres voor lokale trafiek dan voor je publieke internet trafiek. Ipv6 werkt op bepaalde vlakken helemaal anders dan ipv4, een ipv4 topologie kan je dus niet letterlijk vertalen naar ene ipv6 topologie.
Zie het zoals een spreekwoord vertalen naar een andere taal. In het Nederlands zeggen we bijvoorbeeld met de deur in huis vallen, in het Engels ga je dus niet zeggen falling in the house with the door, maar eerder coming straight to the point .
ITnetadmin
userbase crew
userbase crew
Berichten: 8965
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 689 keer
Recent bedankt: 2 keer

Ah, IPv6 NAT is altijd een discussie tussen de puristen ("IPv6 heeft da ni nodig") en de pragmatici ("Er is vraag naar én het heeft nut, dus moet het er komen"). Je weet zoiezo al dat de laatste groep dit gaat winnen.

Soit.

Mag ik om te beginnen het misverstand op de korrel nemen dat hier in grote letters "NAT != Security" staat te roepen? Dat is uiteraard onzin.
De juiste zinsnede moet zijn "Enkel NAT != Security". Nat voegt wel degelijk een laagje bij op de security.
"Security through obscurity" werkt op voorwaarde dat het niet de enige security is.
Of denk je dat pakweg banken je exact gaan vertellen hoe hun netwerk in mekaar zit?
Zelfs bij websites is de gangbare beveiliging "verwijder de footer waarin de exacte versie van je CMS staat".

Ik ken genoeg high security instellingen (waaronder minstens 1 bank) die niet naar IPv6 migreren zonder NAT, omdat anders hun servers geidentificeerd kunnen worden adhv hun IP; terwijl je nu geen énkel idee hebt hoeveel servers ze hebben en welke toestellen welke taken vervullen.

Vergeet daarbij ook niet dat netwerkbeheerders nogal controlefreaks zijn en het moeilijk of niet kunnen verteren dat ze hun eigen netwerk niet *volledig* onder eigen controle hebben. QED:
Splitter schreef:dat is dus wat ik wil proberen... maar ik wil zélf bepalen welk toestel welk v4/v6 adres krijgt, en dit onafhankelijk van eender welke prefix hebben...
iets wat quasi onmogelijk lijkt - of althans toch niet zo simpel is.
ik wil gerust mee evolueren met v6, maar ik wil 0,0 toegeving doen op controle van mijn toestellen en welke adressen ze hebben.
Exact mijn opinie daarin.


Er zijn momenteel dus minstens 2 manieren in ontwikkeling.
Aan de ene kant heb je NPT, network prefix translation; dat vervangt enkel de prefix die je ISP uitdeelt door een eigen prefix.
Aan de andere kant heb je full NAT66, die alles aanpast.

Zonder NAT heb je enorme issues met static IPs, waarbij je bv je prefix elke keer mag aanpassen als je provider je een andere prefix uitdeelt (dynamische IPv6 staat te gebeuren, ook in Duitsland doet men dat omwille van privacy redenen). Je zit ook met issues als je aan multi-wan doet, want welke ISP laat je de prefixen uitdelen, en hoe regel je je routing als die ISP uitvalt (IPv6 is hierarchisch, dus de prefix van ISP2 kan niet geroute worden door ISP2).

Uiteraard heb je dan ook het probleem dat je ISP exact weet hoeveel toestellen je op je netwerk hebt staan; en dan steekt die ouwe "meer toestellen? meer betalen" policy wss terug de kop op in sommige landen.

Verder blijven er issues bestaan omdat de router RAs uitdeelt, en de IPv6 stack meerdere IP adressen per interface toelaat. Hierdoor krijgt zelfs een toestel met een static IP toch nog een DHCP IP toegewezen (win2012 bv lijdt daaraan).

Ook is herkenbaarheid van het IP adres een probleem. Bij IPv4 delen veel ITers IP adressen in herkenbare blocks uit; bv printers in de 20, DHCP boven de 100, etc etc.
Die herkenbaarheid breekt gegarandeerd, want zelfs als je via DHCP een herkenbaar adres uitdeelt, toch gaat het FE80 linklocal adres dynamisch gevormd worden; en dat linklocal wordt voor alle lokale communicatie gebruikt; vergeet herkenbare wireshark traces dus maar.
Er is tot nu toe geen automatische manier om het manueel uitgedeelde suffix óók toe te kennen als linklocal suffix (om zo alle suffixen identiek te houden tussen global, linklocal, en uniquelocal adressen van een toestel).
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

ITnetadmin schreef: Mag ik om te beginnen het misverstand op de korrel nemen dat hier in grote letters "NAT != Security" staat te roepen? Dat is uiteraard onzin.
De juiste zinsnede moet zijn "Enkel NAT != Security". Nat voegt wel degelijk een laagje bij op de security.
"Security through obscurity" werkt op voorwaarde dat het niet de enige security is.
Of denk je dat pakweg banken je exact gaan vertellen hoe hun netwerk in mekaar zit?
Zelfs bij websites is de gangbare beveiliging "verwijder de footer waarin de exacte versie van je CMS staat".

Ik ken genoeg high security instellingen (waaronder minstens 1 bank) die niet naar IPv6 migreren zonder NAT, omdat anders hun servers geidentificeerd kunnen worden adhv hun IP; terwijl je nu geen énkel idee hebt hoeveel servers ze hebben en welke toestellen welke taken vervullen.
Vergeet daarbij ook niet dat netwerkbeheerders nogal controlefreaks zijn en het moeilijk of niet kunnen verteren dat ze hun eigen netwerk niet *volledig* onder eigen controle hebben.
NAT != Security is geen onzin.

NAT DRAAGT 0% BIJ AAN SECURITY.
Bronnen: [1] [2] [3] en specifiek in de context van IPv6: [4]

Ik ga er niet over discussiëren omdat het off-topic is en dit punt zodanig essentieel is dat er geen discussie nodig is, en er anders het risico bestaat dat er (onterechte) twijfel ontstaat met alle mogelijke gevolgen vandien. Ik kan de lezer enkel maar op het hart drukken om de 4 links hierboven eens te bekijken alvorens het idee dat NAT bijdraagt tot security als koek te slikken.

NAT gaat trouwens niemand met middelen en een motivatie tegenhouden om aan netwerk reconnaissance te doen. Ocharme (de klanten van) de banken die dat wel geloven.

Tenslotte zie ik niet in hoe een migratie naar IPv6 betekent dat je enige vorm van controle verliest over je netwerk. Ik heb het gedaan, bij ons op het werk is het gedaan, en we hebben geen controle verloren. We kunnen alles doen dat we onder IPv4 ook konden.
ITnetadmin
userbase crew
userbase crew
Berichten: 8965
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 689 keer
Recent bedankt: 2 keer

Obscurity draagt *altijd* bij aan security.

Een goeie site zet er niet bij exact welke versie van software ze draaien.
Een bank gaat je niet vertellen hoe hun netwerk eruit ziet.
Vraag maar ns aan een bedrijf welke badges je nodig hebt om binnen te geraken en hoe ze eruit zien.

Obscurity is de last/first layer of security, waarin je verhult wat je exact hebt, zodat een aanvaller al moet gaan zoeken/gokken wat er exact intern gebeurt.

In dit geval is NAT een onderdeel van security. Het houdt mss de echte hackers niet buiten, maar een aantal opportunisten zullen gehinderd worden. Security is géén zwart-wit concept. Het bestaat in lagen. Elke laag die iets van security bijvoegt is de moeite waard. De laatste laag is onvermijdelijk een laag van camouflage.

Bv: https://www.giac.org/paper/gsec/160/vir ... ity/100626
"Obscurity can play a part in defense-in-depth"
"Obscurity is a valid security layer"
https://danielmiessler.com/study/securi ... gs.5SvCoDQ

Veel te veel security researchers focussen zich puur op de *technische* kant van de zaak; NAT voegt idd weinig of geen technische security toe, maar dat wil niet zeggen dat het nutteloos is.

En daarnaast voegt NAT wel een deel controle toe, zeker in IPv6; of dat nu controle is over de exacte netwerk config, of controle in de zin "mijn isp hoeft niet te weten wat ik hier staan heb".

Ivm die controle trouwens:
Een externe entiteit die een prefix op *mijn* netwerk gaat uitdelen, is *niet* controle behouden.
Mijn netwerk, mijn settings, en er wordt geen bitje uitgedeeld dat ik niet geconfigureerd heb.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef:Tenslotte zie ik niet in hoe een migratie naar IPv6 betekent dat je enige vorm van controle verliest over je netwerk. Ik heb het gedaan, bij ons op het werk is het gedaan, en we hebben geen controle verloren. We kunnen alles doen dat we onder IPv4 ook konden.
zonder te spieken... het volledige ipv6 adres van je printer?
(en als je dat nu niet kan zeggen... snap je mijn punt, kan je het wel wil ik graag ruilen van hersencapaciteit :p)
ITnetadmin schreef:Ivm die controle trouwens:
Een externe entiteit die een prefix op *mijn* netwerk gaat uitdelen, is *niet* controle behouden.
Mijn netwerk, mijn settings, en er wordt geen bitje uitgedeeld dat ik niet geconfigureerd heb.
dat dus... anders kan je gewoon gelijk een vpn aanvragen naar de nsa of china en hun laten bepalen wat je kan en mag op internet.
overdreven misschien, weet ik... maar pakweg 20j geleden iemand zeggen "je moet de thuis pc met je bankgegevens een publiek -dynamisch!- ip geven", zou dat gepakt hebben?

mijn (thuis)netwerk is steeds zo opgezet dat ik 0,0 aanpassingen moet doen als ik van provider wissel: modem inklikken met mijn utp, done.
geen andere adressen die ik moet kennen, geen veranderingen op het netwerk buiten 1 modem die niks anders doet dan het signaal geven.
het idee van ipv6 uit te delen op het lan, door de provider, met dynamische adressen, waarbij dan ook nog eens je mac adres eigenlijk exposed is aan ieder dat het wil (kan je provider nog perfect zien welke toestellen je hebt ook...) vind ik not done.

sterker, ipv6 is nu door velen gepromoot op een manier dat LOCAL area network niet meer bestaat, gezien je elk toestel een globaal adres zou geven.

*zucht* ik had wel gedacht dat er iets of wat discussie zou komen... maar nu is het enkel discussie en veel verder zit ik nog niet met de oplossing voor mijn netwerk
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

ITnetadmin schreef: Ivm die controle trouwens:
Een externe entiteit die een prefix op *mijn* netwerk gaat uitdelen, is *niet* controle behouden.
Mijn netwerk, mijn settings, en er wordt geen bitje uitgedeeld dat ik niet geconfigureerd heb.
Als iedereen het zo voor het zeggen zou hebben op het internet, dan was er van veel internet geen sprake meer. Externe entiteiten delen prefixen nu eenmaal uit om routing mogelijk te maken. Als je consequent bent heb je trouwens wat IPv4 betreft met je ASN je eigen IPv4 block gekocht, met je eigen fiber naar level3...
ITnetadmin schreef: En daarnaast voegt NAT wel een deel controle toe, zeker in IPv6; of dat nu controle is over de exacte netwerk config, of controle in de zin "mijn isp hoeft niet te weten wat ik hier staan heb".
Telenet heeft met de HGW zelf al een backdoor voorzien om achter je NAT te kunnen kijken (goed voor jou als je een modem-only hebt, maar dat betekent nog steeds niet dat niemand anders achter je NAT kan kijken). Wat meteen mijn punt illustreert.

Aan de lezer: security is geen lachertje, informeer u grondig en neem niet zomaar alles aan van wat u hier leest.
Zie ook de NIST Guide to General Server Security, in het bijzonder "System security should not depend on the secrecy of the implementation or its components." Merk op dat NIST zegt: "should not depend" (en niet "should not solely depend").
Splitter schreef:
CCatalyst schreef:Tenslotte zie ik niet in hoe een migratie naar IPv6 betekent dat je enige vorm van controle verliest over je netwerk. Ik heb het gedaan, bij ons op het werk is het gedaan, en we hebben geen controle verloren. We kunnen alles doen dat we onder IPv4 ook konden.
zonder te spieken... het volledige ipv6 adres van je printer?
(en als je dat nu niet kan zeggen... snap je mijn punt, kan je het wel wil ik graag ruilen van hersencapaciteit :p)
Mijn DNS server kan dat zonder te spieken. Ik heb 4,722,366,482,869,645,213,696 IPv6's tot mijn beschikking, en ik moet die memoriseren? :-)
Splitter schreef:dat dus... anders kan je gewoon gelijk een vpn aanvragen naar de nsa of china en hun laten bepalen wat je kan en mag op internet.
Kan je toch niet vergelijken met een deftig firewalled netwerk?

"NAT security": je hebt een kluis, zet die in een ruimte waar een paar mensen werken die je "vertrouwt", en op de deur van de ruimte hang je het bordje "berging" oid, je doet de deur op slot en geeft iedereen in de ruimte een sleutel. Dat is je security. Hopelijk zal niemand denken dat er meer achter die "berging" zit (=het "obscurity"-aspect) en het slot forceren. Hopelijk zal niemand die er werkt de deur "per ongeluk" open laten. Gebeurt dat toch, dan RIP kluis.
Firewall: je zet effectief een bewaker voor die deur die iedereen 24/7 controleert die binnenkomt en buitengaat.
Splitter schreef:mijn (thuis)netwerk is steeds zo opgezet dat ik 0,0 aanpassingen moet doen als ik van provider wissel: modem inklikken met mijn utp, done.
geen andere adressen die ik moet kennen, geen veranderingen op het netwerk buiten 1 modem die niks anders doet dan het signaal geven.
Mijn IPv6 thuisnetwerk ook.
Splitter schreef: het idee van ipv6 uit te delen op het lan, door de provider, met dynamische adressen, waarbij dan ook nog eens je mac adres eigenlijk exposed is aan ieder dat het wil (kan je provider nog perfect zien welke toestellen je hebt ook...) vind ik not done.
Mijn router deelt de IPv6 LAN adressen uit. Mijn ISP delegeert enkel een prefix en zegt tegen mijn router "hier, doe ermee wat ge wil" (logisch, want uiteindelijk moeten die IPv6 adressen ook terug te koppelen zijn aan het netwerk waar ze zich in bevinden, puur random IPv6's zonder ISP-prefix uitgeven zou niet werken, net zoals het niet zou werken als je je eigen computer het IPv4 8.8.8.8 geeft oid).
Splitter schreef: sterker, ipv6 is nu door velen gepromoot op een manier dat LOCAL area network niet meer bestaat, gezien je elk toestel een globaal adres zou geven.
Maar ook met globale adressen kan je perfect een veilig LAN runnen? Dat was trouwens van in het begin van het internet al de bedoeling? Je vergelijkt hier privaat met lokaal?
Splitter schreef:veel verder zit ik nog niet met de oplossing voor mijn netwerk
Als je doet zoals ik doe kan je volgens mij perfect bereiken wat je wil. Alleen op Android zou het niet werken blijkbaar (omdat Android de standaarden niet volgt, voor de duidelijkheid).
Laatst gewijzigd door CCatalyst 17 dec 2016, 20:32, in totaal 1 gewijzigd.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef:
Splitter schreef: zonder te spieken... het volledige ipv6 adres van je printer?
(en als je dat nu niet kan zeggen... snap je mijn punt, kan je het wel wil ik graag ruilen van hersencapaciteit :p)
Mijn DNS server kan dat zonder te spieken. Ik heb 4,722,366,482,869,645,213,696 IPv6's tot mijn beschikking, en ik moet die memoriseren? :-)
sja, en dan is je dns server down of je ziet ergens een ip voorbijkomen waar het niet hoort en je weet niet welk device het is...
of er komt stiekem een device bij op je netwerk, krijgt mooi een ipv6 adres en je hebt geen flauw benul wat dat device is en of het van jou is...
CCatalyst schreef:
Splitter schreef:mijn (thuis)netwerk is steeds zo opgezet dat ik 0,0 aanpassingen moet doen als ik van provider wissel: modem inklikken met mijn utp, done.
geen andere adressen die ik moet kennen, geen veranderingen op het netwerk buiten 1 modem die niks anders doet dan het signaal geven.
Mijn IPv6 thuisnetwerk ook.
euh, niet toch? je krijgt een prefix van je provider, die prefix neem je mee op je netwerk... dus je ip's zijn anders als je provider daar zin in heeft...
stel je voor, een nummerplaat altijd maar moeten veranderen als de politie/overheid zin heeft je een nieuwe door de strot te rammen (heh, dat hebben we eigenlijk al eens gehad...)

CCatalyst schreef:Mijn router deelt de IPv6 LAN adressen uit. Mijn ISP delegeert enkel een prefix en zegt tegen mijn router "hier, doe ermee wat ge wil"
dus deelt je router "een deeltje van" het adres uit eigenlijk.
CCatalyst schreef: Maar ook met globale adressen kan je perfect een veilig LAN runnen? Dat was trouwens van in het begin van het internet al de bedoeling? Je vergelijkt hier privaat met lokaal?
voor mij is privaat en lokaal hetzelfde in deze context...
en je kan een veilig lan hebben met GUA en een onveilig met ULA - die beweringen maak ik dan ook helemaal niet.
ik wil gewoon niet dat de adressering van mijn lan afhankelijk is van mijn provider (dus wil ik werken met ULA op mijn lan!)

voordelen ULA:
- volledig onafhankelijk van je provider (en eventuele internetconnectiviteit... wat gebeurt er met je GUA als je bv 2 dagen zonder internet zit?)
- makkelijk te onthouden (haja: fd00:1::100 is nu eenmaal makkelijker dan eender welk GUA )
CCatalyst schreef:Als je doet zoals ik doe kan je volgens mij perfect bereiken wat je wil. Alleen op Android zou het niet werken blijkbaar (omdat Android de standaarden niet volgt, voor de duidelijkheid).
met mjn ULA's normaal ook... maar er is iets mis met de routering denk ik.
het verste dat ik raak is fw => internet ok, lan => fw ok, lan => internet nok
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef: sja, en dan is je dns server down of je ziet ergens een ip voorbijkomen waar het niet hoort en je weet niet welk device het is...
Chapeau als je al je IP's van buiten kent. Mijn netwerk is te groot daarvoor. Ik berust mijn security ook niet op het persoonlijk herkennen van IP's, ik kan er ook niet 24/7 op zitten kijken.
Splitter schreef: of er komt stiekem een device bij op je netwerk, krijgt mooi een ipv6 adres en je hebt geen flauw benul wat dat device is en of het van jou is...
DHCPv6 kan je instellen dat ie enkel gekende DUID's een IP geeft en niet aan onbekende, en je zet een firewall rule om enkel de gekende devices door te laten. Problem solved.
Devices kunnen MAC/DUID clonen ja, maar dan ga je ook onder IPv4 een rogue device kunnen hebben die met een "gekend IP" rondloopt.
Opnieuw: afgaan op IP adressen is geen deftige security policy.
Splitter schreef: euh, niet toch? je krijgt een prefix van je provider, die prefix neem je mee op je netwerk... dus je ip's zijn anders als je provider daar zin in heeft...
stel je voor, een nummerplaat altijd maar moeten veranderen als de politie/overheid zin heeft je een nieuwe door de strot te rammen (heh, dat hebben we eigenlijk al eens gehad...)
Het verschil is dat ik geen nieuwe nummerplaat moet ophangen. Dat doet de router gewoon.
Splitter schreef:dus deelt je router "een deeltje van" het adres uit eigenlijk.
Zelf zie ik echt niet vanwaar die angst voor die globale IP's. Mits deftige firewalling zie ik echt niet in wat de problemen zijn. Ik heb LAN toestellen met IPv6 die je ook gewoon niet kan zien vanop het internet... Firewall kan dat allemaal. Mijn ISP weet ook niet dat onder welk IP die toestellen zitten, enkel mijn router weet dat. Het netto-effect is dan toch gewoon hetzelfde als bij je private IP's+NAT?
Splitter schreef: ik wil gewoon niet dat de adressering van mijn lan afhankelijk is van mijn provider (dus wil ik werken met ULA op mijn lan!)

met mjn ULA's normaal ook... maar er is iets mis met de routering denk ik.
het verste dat ik raak is fw => internet ok, lan => fw ok, lan => internet nok
KISS oplossing: gebruik IPv6 zoals het bedoeld is
Anders: NDP proxy, 6in4 tunneling dmv uw toestellen achter een tweede (not public facing) router steken. Allemaal zaken die u perfo gaan kosten, prolly ook geld (geavanceerde functies) en waarschijnlijk niet volledig future-proof zijn, telkens omdat ze afbreuk doen van KISS, maar wel zouden moeten werken. Heb je die al geprobeerd?
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef: KISS oplossing: gebruik IPv6 zoals het bedoeld is
het zou moeten werken met NPT... en dat is een onderdeel van ipv6.
maargoed, i give up... het is duidelijk dat ik hier toch geen zinnige antwoorden meer ga krijgen in deze thread,
maar enkel maar commentaar omdat ik een ander idee heb van (lokaal thuis)netwerkbeheer dan sommigen
(moeten we mss ook allemaal maar met dezelfde wagen rijden?)

als je een beetje deftig je netwerk inplant kan het nog zo groot zijn als je wil, met ipv4 lan ip's kan je makkelijk herkennen wat wat is.
om voorbeeldje te geven (geen kopie van mijn huidige setup overigens, maar wel gelijkaardig);

10.0.1.x = networking hardware
10.0.2.x = security hardware
10.0.3.x = dhcp clients lan
10.0.4.x = dhcp clients wifi
10.0.5.x = guest clients
10.0.6.x = printers
10.0.7.x = services machines

dus ja, ik weet altijd alles: of ik nu bgc of tn heb, internet of niet, intern heb ik altijd 10.0.x.y en kan ik altijd "10.0" negeren, x gebruiken om te weten wat het soort toestel is, en y voor het toestel. dus best makkelijk te onthouden.
je kan dat trouwens nog uitbreiden naar 10.x.y.z met X duidende op groep, Y op locatie, en Z op toestel. dan heb je gelijk een fysieke locatie voor elk ip.

again: doe dat maar eens met v6... het gaat, daar niet van... maar je kan moeilijk ontkennen dat het met v4 eenvoudiger is...
daarom dat er ook veel netwerkbeheerders afaik proberen om hun v6 te laten lijken op hun v4.

maargoed, dit gaat dus nergens meer heen... dus ga ik in dit topic ook niet meer teveel moeite steken.
zal er zelf wel (uiteindelijk) achter komen, of gewoon pfsense/opnsense terug buitenflikkeren
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef:
CCatalyst schreef: KISS oplossing: gebruik IPv6 zoals het bedoeld is
het zou moeten werken met NPT... en dat is een onderdeel van ipv6.
maargoed, i give up... het is duidelijk dat ik hier toch geen zinnige antwoorden meer ga krijgen in deze thread,
maar enkel maar commentaar omdat ik een ander idee heb van (lokaal thuis)netwerkbeheer dan sommigen
(moeten we mss ook allemaal maar met dezelfde wagen rijden?)
Het probleem is vooral dat ik de indruk heb dat je vraagt hoe je je oldtimer in het chassis van een hele nieuwe wagen kunt laten rijden. Je gaat geen problemen hebben om advies te krijgen die binnen het protocol vallen (zoals ik al meermaals heb gegeven), maar jij vraagt eigenlijk hoe je je IPv6 meer IPv4 kunt maken, zoals je zelf ook al een beetje aangeeft:
daarom dat er ook veel netwerkbeheerders afaik proberen om hun v6 te laten lijken op hun v4
En als je vraag is: hoe kan ik mijn IPv6 IPv4 maken, dan is het eigenlijk antwoord alleen maar: IPv6 niet gebruiken. Dat maakt het ook moeilijk voor ons om daar een ander zinnig antwoord op te geven, behalve dan om je richting een paar "workarounds" te sturen waar we zelf niet achter staan (noch tijd gaan in steken) omdat we weten hoe krakkemikkig ze vaak werken, laat staan dat er enige documentatie van bestaat over hoe je die kunt laten werken op de Belgische ISP's.

Anderzijds is dat ook jammer omdat ik merk dat je weerstand berust is op heel wat misverstanden inzake IPv6 (jij niet alleen trouwens) - die angst voor publieke adressen bijvoorbeeld - waardoor je bij IPv4 gaat blijven plakken en de noodzakelijke migratie naar IPv6 weer langer duurt. En als ik je binnen x aantal jaar tegenkom ga je zelf niet meer snappen waarom je daar zo tegen was. Ik kan het weten: ik was ook zo toen ik nog niet goed wist hoe IPv6 werkte.

Ik kan alleen maar besluiten met wat ik al een tijdje zeg: als je je weerstand laat varen kan je perfect doen wat je wilt bereiken met het standaard IPv6 protocol. Ik kan dat ook weten want ik doe het nu al (op Belgische ISP).
ITnetadmin
userbase crew
userbase crew
Berichten: 8965
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 689 keer
Recent bedankt: 2 keer

Er zijn enorm veel netwerkers die hun netwerk kennen puur op basis van IP.
Ik ben dus ook niet bereid om:
- een externe prefix aan mijn interne netwerken toe te kennen (NPT is dus een ab-so-luut minimum)
- systemen zichzelf te laten configgen (DHCP ranges of static IP only; dat SLAAC gedoe komt er niet in, en ik ben van mening dat de router geen beslissingen mag maken over het netwerk, enkel een server die ík daarvoor aanwijs)
- systemen IP adressen te geven met verschillende suffixen (de suffixen van global, unique-local, en link-local IPs zullen dus moeten zo instelbaar zijn dat ze identiek blijven, maw als de DHCP server een suffix uitdeelt, moet dat suffix door de PC voor alldrie de types IP adres ingesteld kunnen worden).

Zolang voor deze basis issues geen oplossing voorhanden is, zal IPv6 niet uitgerold worden.
Ik zal niet toelaten dat onleesbare (voor mensen) IP adressen op mijn netwerk losgelaten worden, of prefixen die niet door mij gekozen zijn.

In het ergste geval moet de router maar een NAT64 oplossing uitvoeren. NAT64 gaan we trouwens nog jaaaren meemaken; ik heb laatst nog gehoord over embedded systems met win3.1 in, dus denk niet te gauw dat we IPv4 snel achter ons zullen laten.
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

ITnetadmin schreef:Er zijn enorm veel netwerkers die hun netwerk kennen puur op basis van IP.
Ik ben dus ook niet bereid om:
- een externe prefix aan mijn interne netwerken toe te kennen (NPT is dus een ab-so-luut minimum)
- systemen zichzelf te laten configgen (DHCP ranges of static IP only; dat SLAAC gedoe komt er niet in, en ik ben van mening dat de router geen beslissingen mag maken over het netwerk, enkel een server die ík daarvoor aanwijs)
- systemen IP adressen te geven met verschillende suffixen (de suffixen van global, unique-local, en link-local IPs zullen dus moeten zo instelbaar zijn dat ze identiek blijven, maw als de DHCP server een suffix uitdeelt, moet dat suffix door de PC voor alldrie de types IP adres ingesteld kunnen worden).

Zolang voor deze basis issues geen oplossing voorhanden is, zal IPv6 niet uitgerold worden.
Ik zal niet toelaten dat onleesbare (voor mensen) IP adressen op mijn netwerk losgelaten worden, of prefixen die niet door mij gekozen zijn.
Alles dat je zegt kan onder IPv6, dus het mag uitgerold worden. Het wordt eigenlijk al enkele jaren uitgerold, een grote uptick in traffic sinds begin vorige maand omdat AWS ook op de kar gesprongen is.

Als je dit als consument wil ga je wel een abo met static IPv6 moeten nemen anders gaat het vervelend worden.

In ieder geval, je netwerk kennen op basis van IP lukt misschien in een KMO. In een groot bedrijf is dat ondoenbaar (veel te veel), onwerkbaar (elke dag wijzigingen) en zelfs onwenselijk, want het geheugen van een mens maakt statistisch gezien veel fouten.
ITnetadmin schreef: ik heb laatst nog gehoord over embedded systems met win3.1 in, dus denk niet te gauw dat we IPv4 snel achter ons zullen laten.
Mooi, ik heb dan nog vele jaren jobzekerheid :-D (ik ben CCNP-SEC dus vooral werkzaam in netwerksecurity).
dovo
Plus Member
Plus Member
Berichten: 118
Lid geworden op: 28 nov 2015, 21:18
Uitgedeelde bedankjes: 13 keer
Bedankt: 39 keer

CCatalyst schreef:Anderzijds is dat ook jammer omdat ik merk dat je weerstand berust is op heel wat misverstanden inzake IPv6 (jij niet alleen trouwens) - die angst voor publieke adressen bijvoorbeeld - waardoor je bij IPv4 gaat blijven plakken en de noodzakelijke migratie naar IPv6 weer langer duurt. En als ik je binnen x aantal jaar tegenkom ga je zelf niet meer snappen waarom je daar zo tegen was. Ik kan het weten: ik was ook zo toen ik nog niet goed wist hoe IPv6 werkte.
Bij mij was dit exact hetzelfde, het grootste deel van van mijn tijd gespendeerd aan ipv6 leren was dat het bij ipv6 anders was. Soms dacht ik ook echt, wat is dit nu, maar na een tijd zeg je van hé dat is echt wel heel slim gezien. VLSM, geen problemen meer mee: ::/64 per vlan en opgelost.
Ip adressen hield ik ook bij op een notitie, bij ipv6 was dat niet meer echt haalbaar en ben ik phpipam gaan gebruiken (lokaal gehost, want die zijn niet 100% bugfree).
Ik heb CCNA, en je ziet daar een beetje ipv6, maar niet duidelijk genoeg om echt volledig mee te zijn.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef:maar jij vraagt eigenlijk hoe je je IPv6 meer IPv4 kunt maken, zoals je zelf ook al een beetje aangeeft:
daarom dat er ook veel netwerkbeheerders afaik proberen om hun v6 te laten lijken op hun v4
....
En als je vraag is: hoe kan ik mijn IPv6 IPv4 maken, dan is het eigenlijk antwoord alleen maar: IPv6 niet gebruiken.
...
Anderzijds is dat ook jammer omdat ik merk dat je weerstand berust is op heel wat misverstanden inzake IPv6 (jij niet alleen trouwens) - die angst voor publieke adressen bijvoorbeeld
...
als je je weerstand laat varen kan je perfect doen wat je wilt bereiken met het standaard IPv6 protocol.
heu... ik vraag niet hoe ik v6 meer v4 kan maken.. en het voorbeeld dat ik bedoel is dat er veel zijn die prefix::192:168:0:100 doen bv, om v6 en v4 te "matchen.

npt is trouwens deel van v6, hadden ze het niet gewild moest dat maar niet gemaakt zijn... dus ik vraag niks dat niet v6 is...
sterker nog: ik wil gewoon v6 gebruiken en niet v4 (maar dan dus wel fd0:: intern, en niet een random toegekende prefix)

en dat jij dan ergens nog aankomt met "dan moet je een static ipv6 abbo nemen"... ten eerste: zijn er al providers die dat aanbieden?
en ten tweede... wat een melkkoe!!!!!
ze hadden ipv6 -als dat toch niet op kan- gewoon per bewoner van de wereld een /64 moeten toekennen.

en goed, ik laat mijn weerstand varen... dus dan kan ik perfect wat ik wil?

moet jij eens zeggen hoe ik dan intern, zonder NPT (wat volgens jou toch niet mag) te gebruiken, een EENVOUDIG en onthoudbaar ip kan hebben, STATIC voor al mijn devices (inclusief prefix!), en zonder daarvoor een speciaal abbo te nemen.

also: ik blijf bij mijn standpunt van zaken te identificeren op ip, zelfs in grote bedrijven (mijn hoger aangehaald voorbeeld schaalt perfect)
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef:
moet jij eens zeggen hoe ik dan intern, zonder NPT (wat volgens jou toch niet mag) te gebruiken, een EENVOUDIG en onthoudbaar ip kan hebben, STATIC voor al mijn devices (inclusief prefix!), en zonder daarvoor een speciaal abbo te nemen.
Enkel IPv4 gebruiken zoals je tot nu toe deed. Hoe je het draait of keert, IPv6 adressen zijn nu eenmaal langer om de expansie van het internet ruimte te geven. Het is nooit de bedoeling geweest dat men die adressen van buiten ging leren, daarvoor is er immers DNS.

Wil je future-proof zijn en ben je bereid 1 prefix van buiten te leren, dan kan dit alles ook in IPv6. Statische prefixen zijn echter net als statische IPv4 adressen een "business class" product en ga je amper of niet vinden op consumentenabo's waar dynamische prefixen (en IPv4's) de norm zijn. Als je de vereiste van "geen speciaal abo" weglaat is hier wat je dan nodig hebt:

* Telenet Business Fibernet 240 plus (solo of in bundel) - afaik een geliefd product op dit forum. Komt meteen ook met onbeperkt volume, hoge throughput en een statische IPv4.
* Telenet modem + een router met pfSense 2.3 of hoger
* statische prefix stel je in via My Telenet en de DUID van je pfSense box
* 5 minuten (of minder) om uw nieuwe statische prefix van buiten te leren (aanvaard aub dat dit geen onmogelijke opgave is en dient om uw netwerk wereldwijd te kunnen lokaliseren en routen)
* daarna kan je in je DHCPv6d via static mappings en je /56 je devices een ip geven zoals je wil en dat je makkelijk kan onthouden, eventueel gebaseerd op hun huidige IPv4 private addresses.
* niet vergeten die IP's onzichtbaar te maken vanaf het internet via pfSense firewall rules naargelang noodzaak

Voor de record: bovenstaand is mijn setup, minus de "gemakkelijk te onthouden" IP's wat ik vervang door DNS wegens te veel toestellen. Ik kan bevestigen dat dit werkt.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef:... ga je amper of niet vinden op consumentenabo's waar dynamische prefixen (en IPv4's) de norm zijn.
en waarom is dat? ohjaaa... omdat ze ip's wilden besparen en dus dynamisch maakten om minder ip's nodig te hebben...
en dus ipv v6 aan iedereen statisch toe te kennen (zoals het hoort), gaan ze dat uitmelken.
sja, daar is v6 ook niet voor gemaakt, maar jij lijkt me ook graag te verkopen.

je mag stoppen met te antwoorden, gezien jou antwoorden toch altijd bestaan uit "dat hoort niet zo"...
mijn netwerk hoeft niet te lokaliseren te zijn in china en betalen voor een probleem op te lossen dat in de eerste plaats artificieel is, ben je gek?

ik vroeg simpelweg advies voor een probleem, niet een hele lezing over andere producten of het gewoon niet op deze (perfect aanvaardbare, overigens) manier te doen.
blijkbaar is dat iets wat moeilijk is? maar aanvaard nu maar dat ik geen controle wil afgeven ook al hoort het zo volgens sommigen.

ik heb een PROBLEEM en wil dat OPGELOST zien, niet "oh, dat mag zo niet dus doe het gewoon niet" als antwoord - dus als dat de redenering is hoeft er helemaal geen post gemaakt te worden in de thread.
wil je dat ik het niet oplos op deze manier (NPT dus) dan moet je maar gaan lobbyen om dat uit ipv6 te halen.
CCatalyst
Elite Poster
Elite Poster
Berichten: 8248
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 522 keer
Recent bedankt: 12 keer

Splitter schreef: wil je dat ik het niet oplos op deze manier (NPT dus) dan moet je maar gaan lobbyen om dat uit ipv6 te halen.
Blijkbaar lukt het niet op die manier, zoals je zelf al zei. Ik heb hierboven nochtans al alternatieven voorgesteld (tunneling, NDP proxy), die je probleem zouden kunnen oplossen op de manier die jij wilt, maar je bent daar nog niet op ingegaan. Heb je die nu al geprobeerd? Heeft weinig zin om verder te doen zolang je daar geen feedback van hebt.

Ik ben ook niet voor dynamische prefixen bij de consumenten, maar ik ben Telenet niet. Anderzijds ga je ook niet veel consumenten hebben die statische prefixen gaan willen zodat "ze hun IP zouden kunnen onthouden" uiteraard. Als ze statisch willen is het meestal om een server te draaien, en dan zit je bijna vanzelf in het business segment.

Geen idee waar ik dat antwoord aan verdiend heb trouwens, heb nog redelijk wat tijd gestoken in die vorige reply. Hopelijk zal het voor iemand anders nuttig zijn.
ITnetadmin
userbase crew
userbase crew
Berichten: 8965
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 689 keer
Recent bedankt: 2 keer

@Ccatalyst: dus jij beweert dat IPv6 intussen een methode heeft gevonden, om een geassignede global suffix (via dhcp) direct ook te dupliceren om als unique local suffix en als link local suffix te dienen?
Schitterend, want daar wacht ik al effe op; dan moet ik er maar eentje meer herkennen om te weten over welk toestel het gaat. Want tot nu toe is er voor zover ik weet geen manier om via DHCP een link-local adres (suffix) te forceren naar een bepaalde waarde.
Ik zoek hier al een tijdje naar, maar had tot op heden nog niks kunnen vinden; kan je me effe helpen met een linkje naar een relevant article/howto/... ?

Dat, in combinatie met op zn minst NPT, zorgt ervoor dat ipv6 adressen terug leesbaar gaan zijn, door de interne prefix zo eenvoudig mogelijk te houden (benieuwd of ze daar al een range voor gereserveerd hebben), en de suffix ook (via static assignment en DHCP).

Je zou je verbazen hoeveel beter ik cijfers kan onthouden dan namen hoor.
Als je een paar maand in een netwerk vertoefd ken je daar toch direct al 90%+ van de IP adressen van? Daar hoef ik zelfs niet op te studeren. Dat komt even vanzelf als mijn bankkaartnummers vanbuiten kunnen intypen bij het online bankieren, omdat je na een 20x dat invullen dat toch echt wel kent.

Ik ben verder geen voorstander van mijn netwerk toestellen op naam te onthouden; als er een dns issue is kan ik ze mogelijks niet bereiken dan; IP is layer 3 en als je dat kent van een toestel heb je geen naam nodig en ben je dus ook niet afhankelijk van een hoger protocol.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

CCatalyst schreef: Blijkbaar lukt het niet op die manier, zoals je zelf al zei. Ik heb hierboven nochtans al alternatieven voorgesteld (tunneling, NDP proxy), die je probleem zouden kunnen oplossen op de manier die jij wilt, maar je bent daar nog niet op ingegaan. Heb je die nu al geprobeerd? Heeft weinig zin om verder te doen zolang je daar geen feedback van hebt
....
Geen idee waar ik dat antwoord aan verdiend heb trouwens, heb nog redelijk wat tijd gestoken in die vorige reply. Hopelijk zal het voor iemand anders nuttig zijn.
tunneling en proxy zijn gewoon geen antwoord op de vraag, dus dat wil ik dan logischerwijs ook niet (want zelfs ZOU dat het oplossen, dan is het nog steeds niet de oplossing voor mijn vraag...)

ik apprecieer dat je tijd steekt in je antwoorden, het probleem is gewoon dat het antwoord wat naast de kwestie is, en na x uur uitzoeken waarom iets niet werkt en enkel antwoorden naast de kwestie krijgen, dan krijg je frustraties.
zeker als je dan al een paar x suggesties hebt gemaakt die inhouden om er meer geld aan uit te geven (verkoperspraat maakt me altijd wat 'edgy')

mijn issue is nu, zoals dovo ook al aanhaalde, effectief dat de ping reply vanop internet niet terug geraakt tot bij mijn host,
omdat de bbox geen neighbor advertisement krijgt als hij naar het wan-ip van mijn pc vraagt.

ndp proxy zou het kunnen oplossen ja... maar ten eerste geen idee waar ik dat in pfsense/opnsense kan vinden, en ten tweede is het niet iets dat me aanstaat (een fw/gateway oplossing hoort te weten wat erachter zit... dus ook te antwoorden als het verkeer daarvoor is, zonder toegevoegde acties)


ik verwacht dus eigenlijk, op het moment dat mijn bbox vraagt achter het wan-ip van mijn pc, dat mijn firewall zegt "he, die ken ik", vervolgens het wan-ip terug omzet naar het lan-ip en het pakket aflevert.
zonder dat daar meer voor te pas komt dan gewoon de firewall en npt - iets dat ik dacht dat perfect mogelijk zou moeten zijn.
(i.e: de firewall vertaalt 1-op-1 de wan en lan prefix en behandelt ze dan, iets wat bij de solicitation blijkbaar de mist in loopt)
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5230
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 520 keer
Recent bedankt: 9 keer

Om hier nog even op terug te komen:

er zit/zat een bug in pfsense/opnsense die NPT foutief doet (heeft iets te maken met een upgrade van freebsd), dat was issue 1.
issue 2 was dat het énkel werkt als het ip ook nog eens als virtual ip toegevoegd is (wat volgens mij nog een fout in de implementatie van NPT is)

maar dus:

- intern fd::00:1:x op de machines
- NPT instellen voor externe range <=> interne range
- het externe ip van de machines (dus na translation) toevoegen aan de lijst van virtual ip's

en dan werkt alles.
alleen is dat 3de puntje dus iets dat niet schaalt, en dat vind ik niet correct (en zowiezo lijkt het me vreemd, want NPT zou in de 2 richtingen moeten vertalen en dus reageren op een discovery voor dat adres)
vreemde is ook dat het toevoegen van de hele range bij virtual ip's ook niet werkt.

en natuurlijk, lang leve belgie, elke keer als de modem herstart mag ik de range aanpassen want zelfs ipv6 is dynamisch *zucht*
Plaats reactie

Terug naar “Netwerken en Security”