ipv6 + pfSense: ULA tussen VLANs

[gert.jansen]

Ik heb ondertussen ipv6 al een tijdje werkend via mijn (virtuele) pfSense router.
Op de meeste vragen die ik gesteld had hier, hier, en daar heb ik ondertussen antwoord gekregen of gevonden door te experimenteren.

* VLANs werken perfect door de prefix ID in te vullen, dat vult het door Telenet gekregen 56-bit prefix aan met de bits 57 t/m 64.
* de optie 'Do not allow PD/Address release' zorgt er voor dat ik telkens opnieuw hetzelfde prefix krijg.
Dat werkt goed, ook al wordt de router eens gereset.

Echter, na werken in de buurt is er een stroomstoring geweest en heeft mijn router meer dan een dag zonder stroom gezeten (ik was zelf afwezig)
Nadien heb ik toch een ander PD gekregen.

Ik wil dus naast het GUA adres (wat niet 100% vast is) ook ULA adressen (die ik zelf kan bepalen) aan mijn apparatuur toekennen.
Ik laat de RA naast de GUA adressen (Track Interface: WAN) ook adressen uit een bepaalde ULA reeks verspreiden.

Dat op zich lukt perfect.
Het probleem is dat apparaten op verschillende interfaces (concreet:op verschillende VLANs) niet naar mekaar kunnen pingen op hun ULA adres en wel op hun GUA adres.

Dat zou eigenlijk wel moeten werken.

Om een configuratieprobleem zoveel mogelijk uit te sluiten, heb ik 3 nieuwe Virtual machines geïnstalleerd:
* een pfsense met minimale configuratie: enkel met ULA adressen en ipv6 allow any to any op elke interface.
* een windows 7 client op 1e VLAN interface
* een windows 7 client op de 2e VLAN interface

client 1 kan pingen naar client 2 (en omgekeerd), dus zoals het hoort.
Tot ik de pfSense reboot, daarna stopt dit met werken en krijg ik dat niet meer aan de gang.

Ik heb als verdere test de pfsense in die setup eens vervangen door OPNsense en daar dezelfde configuratie in aangemaakt; en die blijft wel werken na een reboot.

Bij voorkeur zou ik bij pfSense blijven omdat ik die al helemaal ingesteld heb en daar redelijk wat ervaring mee heb, maar dan moet de routering van de ULA adressen tussen de verschillende interfaces wel werken.

Is er iemand die een soortgelijke setup heeft en dat wel werkend heeft?
Of alternatief: een manier kent om permanente ipv6 adressen (dus niet afhankelijk van het door de provider gekregen prefix) toe te kennen aan mijn apparatuur?

[ITnetadmin]

Zou NPT of NAT66 een optie zijn?

[Ofloo]

intern kan je met NPt werken maar als je graag statische IPv6 prefix hebt HE.net bied deze aan, .. als je er services wilt op draaien zoals een mail server dan moet je wel IPv6 examentje doen, en SAGE bekomen.

Tot slot kan je enkel maar een statisch adres hebben als je provider deze statisch toewijst. Als telenet deze dynamisch toewijst kan je enkel maar een tunnel nemen om ze statisch te maken.

Zelfs met NPt moet je de nat translation mappen en dit gebeurd niet automatisch en ook niet dynamisch, het mappen van NPt moet ook statisch gebeuren.

[gert.jansen]

Zou NPT of NAT66 een optie zijn?

Misschien wel. Ik moet eens uitzoeken wat dat exact doet want daar heb ik nu nog geen idee van.

... als je graag statische IPv6 prefix hebt ...

Tot slot kan je enkel maar een statisch adres hebben als je provider deze statisch toewijst. Als telenet deze dynamisch toewijst kan je enkel maar een tunnel nemen om ze statisch te maken.

Ik denk niet dat een statische prefix noodzakelijk is.
Thuis heb ik een gewoon Telenet abonnement en dat zal dus dynamisch zijn. Alhoewel die setting in pfSense [ Do not allow PD/Address release -- dhcp6c will send a release to the ISP on exit, some ISPs then release the allocated address or prefix. This option prevents that signal ever being sent ] er voor zorgt dat ik telkens hetzelfde prefix krijg.
(Tot er een bepaalde tijdslimiet overschreden is, bv door die stroomonderbreking ?)

Op het werk heb ik wel een business abonnement met fixed ipv4 en fixed ipv6. ik ga ervanuit dat het ipv6 prefix dan ook fixed is.


Dus fixed prefix lijkt me niet echt nodig. Wat ik wel wil is een statisch (of beter: voorspelbaar) adres voor een aantal servers/services, bv. voor mijn eigen Windows Active Directory, DNS servers, mijn pi-hole, etc ....

Ik had gehoopt dat op te kunnen lossen door de RA een 2e prefix te laten announcen: buiten dat van de Track Interface ook een ULA (fd<something>).
Dat werkt op zich ook, alleen kan een machine vanop de ene VLAN interface geen contact maken met een machine op een andere VLAN interface op basis van het ULA-adres. Wel als ik het GUA-adres gebruik.

Dat lijkt me overigens een pfSense-specifiek probleem te zijn, met OPNSense bv werkt het wel.
Op het forum daar zijn nog mensen die dat probleem ervaren (en helaas ook geen respons krijgen). Misschien is er een truc om het toch werkend te krijgen, maar zolang niemand bij pfSense reageert kom ik geen stap verder natuurlijk.

Zelfs met NPt moet je de nat translation mappen en dit gebeurd niet automatisch en ook niet dynamisch, het mappen van NPt moet ook statisch gebeuren.

Over NPt moet ik me nog wat inlezen. Ik denk dat ik wel begrijp wat dat doet, maar moet nog even zien hoe ik dat moet instellen, en of het in mijn geval mijn problemen oplost (en geen andere creëert )

[ITnetadmin]

Nat66 is wat het zegt, pure nat.

Bij NPT heb je eigenlijk ook NAT, maar dan alleen op de prefix; de suffixen worden ongemoeid.

[Ofloo]

NPt is niet pure nat, je gaat gewoon zeggen die surfix moet omgezet worden naar die surfix, dat wil zeggen dat iedereen nog steeds een eigen routable IPv6 krijgt en dat is niet zo bij NAT IPv4 daar wordt 1 routable IPv4 gedeeld met meerdere. Bij NPt ga je heel het subnet omzetten naar en ander IP in dat subnet

bv: fc00::/64 => 2001:fc::/64

fc00::1 => 2001:fc::1
fc00::abcd => 2001:fc::abcd

Dat in mijn ogen is niet pure NAT.

Wanneer is dit interessant, bv wanneer je een computer hebt die meerdere gateways heeft. Dan kan het zijn dat het routable IPv6 niet routeerbaar is door je router/connectie van je andere ISP en dan is het interessant om gebruik te maken van NPt.


Ik denk niet dat een statische prefix noodzakelijk is.

Voor NPt is statiche prefix vereist. Je moet letterlijk zeggen fc00::/64 op die interface map ik naar 2001:fc00::/64. Je kan dit eventueel dynamisch maar dat wil zeggen dat als je een stroom onderbreking hebt dat je dit moet aanpassen. Telkens weer per interface per /64.

Dus ja het kan dynamisch maar is wat werk.

Nu als je dat dynamisch doet gebruik je best Track interface zoals ik al eerder zei. Dan kan je gewoon de routable Prefix gebruiken. Alleen als je failovers wil gebruiken met gateway switching is het aangeraden om toch NPt te gebruiken anders werkt dat gewoon niet deftig op IPv6.

'k doe dit al jaar en dag dus 'k weet echt wel waar over ik het heb.


'k Heb uw vraag nog eens goed gelezen ik zou voor NPt gaan zo doe ik dat trouwens. Ik geef alles een ULA adres dan kan alles met elkaar pingen enz. En dan zet ik op de interface default gateway het ULA om naar GUA mits NPt werkt perfect. Als je hulp nodig hebt met je configuratie laat maar iets weten. Mijn router is trouwens ook gevirtualiseerd in bhyve draait op een vanilla freebsd installatie, mits vm- bhyve om het te configureren.

Wat ik wel moest doen was een 2de wan maken met track wan ip om het prefix binnen te halen van telenet.

En intranet heb ik opgelost door dns views te gebruiken.

[gert.jansen]

...

Bedankt voor je reactie.

Mijn oorspronkelijke plan was om te proberen er voor te zorgen dat alle toestellen op alle VLANs een GUA én een ULA adres kregen.
(behalve diegene die NIET op internet mogen)
GUA via Track Interface, ULA via eender welke manier.

Op deze manier gaat dat niet lukken, helaas. Dat ligt uiteindelijk aan een bug of feature in pfSense (of het onderliggende FreeBSD) [*]

De conclusie is dat ik een keuze ga moeten maken tussen:
1. GUA gebruiken via Track Interface en geen ULA
2. ULA gebruiken en via NPt werken
3. een andere ditributie zoeken die dit probleem niet heeft.


Ik probeer eerst nog even oplossing 3 met OPNsense maar ben bang dat daar hetzelfde probleem in zit.
In dat geval wordt het wellicht optie 2 (met pfSense waar al de rest al geconfigureerd is)

Wat ik wel moest doen was een 2de wan maken met track wan ip om het prefix binnen te halen van telenet.

Ik moet me nog verder inlezen in NPt (ik heb al wel een idee wat en hoe, maar nog niet alle details) dus misschien wordt deze opmerking straks vanzelf duidelijk.

Ik neem aan dat je bedoelt dat je - doordat je op alle interfaces ULA gebruikt en geen Track Interface - op die manier het veranderen van het prefix ook niet merkt, en geen idee hebt hoe dat nieuwe prefix eruit ziet?

Zou je dat ook kunnen oplossen door een dummy (ongebruikte) VLAN te maken waar dan wel Track Interface geconfigureerd is?

----
----

[*] Voor de geïnteresseerden: dit is wat er fout gaat in pfSense:

Elke VLAN interface staat ingesteld als Track Interface (WAN). Via RA krijgen de clients van die interface GUA adressen. Werkt prima.
Om de clients ook een ULA te geven heb ik het volgende ingesteld:

• extra subnet fddd:666:666:<VLAN ID>:: gedefinieerd op RA per interface => dit zorgt er voor dat de clients ook een ULA adres krijgen
• Virtual IP fddd:666:666:<VLAN ID>::1/64 aangemaakt op de interface, dit zorgt ervoor dat er op pfSense ook een route aangemaakt wordt voor fddd:666:666:<VLAN ID>::/64

Dit werkt perfect, tot pfSense een reboot krijgt.


Wat er dan gebeurt is dat de volgorde van de ipv6 adressen op de interface wijzigt. In plaats van GUA-ULA-LL wordt het ULA-GUA-LL.
Dat heeft als effect dat de clients geen GUA adres meer krijgen.
Blijkbaar heeft het te maken met de scripts die enkel werken op het eerst gevonden IP-adres, en dan stoppen.
Het lijkt erop alsof de logica voor TrackInterface dan (op de routerkant) wordt uitgevoerd op het verkeerde IPv6-adres.

Wanneer ik het Virtual IP weer weghaal, staat de GUA/Track Interface weer bovenaan, en krijgt de client weer een GUA adres.
Echter, zonder Virtual IP is er geen route voor het ULA adres op de router en werkt het pingen tussen de verschillende (VLAN) interfaces op ULA-adres niet meer.

Blijkbaar komt dit alleen maar voor in dit specifieke geval: Track Interface + ULA als additional subnet in RA + virtual IPs.
Wanneer ik Track Interface vervang door een static IPv6 (en additional subnet en virtual IP laat staan) heb ik dat probleem niet. De IPv6 adressen wisselen nog steeds van plaats na een reboot, maar de client ontvangt beide, en voor beide wordt een route aangemaakt.

[ITnetadmin]

NPT dat niet dynamisch kan, is weer een absurditeit die opgelost moet worden door de router fabrikanten.
Het *dient* net om je netwerk te beschermen tegen prefix changes.

Also:

NPt is niet pure nat, je gaat gewoon zeggen die surfix moet omgezet worden naar die surfix, dat wil zeggen dat iedereen nog steeds een eigen routable IPv6 krijgt en dat is niet zo bij NAT IPv4 daar wordt 1 routable IPv4 gedeeld met meerdere. Bij NPt ga je heel het subnet omzetten naar en ander IP in dat subnet

1) prefix, niet suffix
2) technisch detail, maar voor de volledigheid: nat is ook 1:1; wat routers gebruiken is eigenlijk PAT (network and port address translation).
NPT gaat idd je suffix behouden; je uitgedeelde prefix vanuit je ISP komt gewoon niet binnen en je router deelt zijn eigen prefix uit.

[Ofloo]

Ik neem aan dat je bedoelt dat je - doordat je op alle interfaces ULA gebruikt en geen Track Interface - op die manier het veranderen van het prefix ook niet merkt, en geen idee hebt hoe dat nieuwe prefix eruit ziet?

Dit is maar een veronderstelling, maar ik vermoed door dat ik alleen ULA gebruik en geen request doe bij telenet dat de router advertisement niet aan mij wordt toegewezen. Om de één of andere rede werkt het gewoon als ik toch een track ip doe.

'k Heb een static Prefix dus is niet dynamisch, maar het is ook een indicatie voor mij dat het werkt. Dus ik heb prefix 12341234::/56 dus 'k gebruik 12341234:ff::/56 als track.

Wat je eens moet doen is voor je ULA een static route toevoegen ik vermoed dat of een firewall rule met gateway ik vermoed dat het naar de default gateway gaat en dan niet meer terug keert naar je netwerk. Kijk anders eens met tcpdump op je interfaces. Volgens mij wil je router je trafiek naar ULA naar buiten toe routen.

Controleer ook of je reserve networks niet blokkeert op je interfaces.

Selectie_013.png

EDIT: static route gaat misschien niet maar firewall rule met als target traffic je ULA en dan een gateway wel.

[gert.jansen]

Wat je eens moet doen is voor je ULA een static route toevoegen ik vermoed dat of een firewall rule met gateway ik vermoed dat het naar de default gateway gaat en dan niet meer terug keert naar je netwerk. Kijk anders eens met tcpdump op je interfaces. Volgens mij wil je router je trafiek naar ULA naar buiten toe routen.

Controleer ook of je reserve networks niet blokkeert op je interfaces.

't is gewoon ergens een bug...

Een interface met enkel GUA (via Track Interface WAN) werkt perfect, clients kunnen communiceren met ipv6 intern en extern
Een interface met enkel ULA (static) werkt evengoed perfect.

't Gaat pas mis als ik de beide hierboven op 1 interface wil combineren (het *zou* nochtans moeten kunnen).

Dat plan heb ik dus laten varen, en ik heb gekozen voor de NPT oplossing die jullie hier voorstelden.

Ik geloof dat ik dat werkend heb gekregen. Clients op verschillende interfaces (VLANs) praten via hun ULA adres, en naar buiten toe wordt dat omgezet in een GUA adres (voor de interfaces waarvoor ik dat ingesteld heb).
Ik heb voor de test ook alle verkeer van buiten naar 1 bepaalde VLAN toegelaten, en dan kan ik de client op die VLAN ook op zijn GUA-adres pingen.
Lijkt me dus helemaal te gaan zoals het bedoeld was ...


Merci voor de hulp