Het grote IPv6 topic

[awenger]

Graag wil ik ook mijn IPv6 ervaring met jullie delen.
Al tijden gebruik in een oude Pentium III met linux-distro's zoals SmootWall, ClarkConnect, pfSense en IPCop als basis voor een router voor mijn thuisnetwerk. Mijn beste ervaringen heb ik met ClarkConnect en daarop heeft mijn router het laatste halfjaar dan ook zonder problemen gedraaid. Nadeel van deze distro's is het gebrek aan IPv6 connectiviteit. Blijkbaar staat de ontwikkeling daarvan nog in de kinderschoenen.

Kort geleden kwam ik erachter dat het mogelijk is om m.b.v. IPv6 gratis te downloaden van Usenet. Reden genoeg voor mij om ook eens met IPv6 te gaan experimenteren. Zo gezegd zo gedaan een tunnel aangevraagd bij SixXS. Omdat ik een dynamisch IPv4 adres heb (en ik mijn ISP niet bereid vond dat om te zetten naar een vast IPv4) was ik genoodzaakt te kiezen voor een AYIYA of heartbeat tunnel te kiezen.
Omdat AYIYA tunnels meer overhead veroorzaken en voor de plug-and-play n00bs zijn besloot ik als gevorderde n00b te kiezen voor een heartbeat tunnel. Helaas kreeg ik de AICCU client niet aan de praat op mijn OS X machine, het ding weigert om een extra interface aan te maken voor de tunnel. Via Windows verbinden via IPv6 werkte wel.

Geen ideale oplossing dus en zodoende kwam ik toch weer terecht bij mijn router om mijn thuisnetwerk IPv6 geschikt te maken. Na wat Google werk kwam ik uit bij een router distro waar in de laatste beta IPv6 connectivity via SixXS wordt geboden met een ingebouwde AICCU client, m0n0wall. http://www.m0n0.ch
Vorige week heb ik mijn ClarkConnect harde schijf vervangen door een CompactFlash kaart met daarop Monowall om alvast het OS te testen voor het routeren van mijn IPv4 verkeer. Ik ben erg tevreden met de performance van het systeem en de gebruiksvriendelijkheid ervan. Alles is in te stellen met behulp van een simpele, heldere User Interface via de browser. (De grote kracht van dergelijke distro's in mijn ogen, ik ben niet het type wat zelf iptables wil gaan wijzigen om poorten open te zetten etc.)
Het systeem is snel opgestart, het is namelijk minder dan 16MB groot. Zo kan je je oude CF kaartjes ook weer leven in blazen.
Omdat ik nog niet genoeg credits had om direct een subnet aan te vragen bij SixXS heb ik "Send IPv6 router advertisements" in eerste instantie uitgeschakeld. Maar de IPv6 tunnel was al wel actief. Via de "Diagnostics" van monowall kon ik in ieder geval pingen naar verschillende IPv6 sites. Ook kon SixXS mijn router pingen, zo was te zien in de logs aldaar.
Sinds vandaag beschik ik ook over een subnet. Het invullen van het IPv6 subnet en het aanzetten van "Send IPv6 router advertisements" was voldoende om al mijn computers IPv6 adressen te geven. Zowel op OS X als Windows Vista werkt dit direct en zonder problemen.

Al met al een hele eenvoudige manier om je thuisnetwerk IPv6 geschikt te maken. De meeste informatie over het installeren van monowall is te vinden op hun website. Voor het instellen van IPv6 i.c.m. een SixXS tunnel en subnet heb ik mijn informatie hier voornamelijk vandaan.
Als er mensen prijs stellen op een volledige Nederlandse tutorial, dan graag even een PM sturen. Dan zal ik deze in dit topic plaatsen.

[Raven]

Daar doelde ik op , al had ik wat duidelijker kunnen zijn

Routers, modems dus (en uiteraard de AP's, printers(ervers) e.d. ook).
Trouwens wel jammer dat pfSense nog geen IPv6 (out of the box) ondersteund...

[ Voor 62% gewijzigd door Raven op 17-08-2010 20:55 ]

[databeestje]

Shameless Plug: Ik ben de afgelopen week bezig geweest om wat ipv6 support in pfSense in te bouwen.
Ik ben inmiddels op het punt aangekomen dat ik het thuis op m'n Alix 2C3 kan gaan zetten.

Het verhaal om de pfSense install de andere broncode boom binnen te laten zuigen staat hier: http://forum.pfsense.org/....msg153037.html#msg153037

Af is het niet, maar iets boven niets geldt hier. De code stelt je nu in ieder geval in staat om een he.net ipv6 tunnel van tunnelbroker.net te termineren en het /64 subnet te gebruiken op het LAN.
Firewalling werkt iig ook, de route advertising daemon staat nog op de todo voor DNS servers. Stateless autoconf werkt wel iig.

[bdegroot]

databeestje schreef op vrijdag 29 oktober 2010 @ 16:50:
Shameless Plug: Ik ben de afgelopen week bezig geweest om wat ipv6 support in pfSense in te bouwen.
Ik ben inmiddels op het punt aangekomen dat ik het thuis op m'n Alix 2C3 kan gaan zetten.

Het verhaal om de pfSense install de andere broncode boom binnen te laten zuigen staat hier: http://forum.pfsense.org/....msg153037.html#msg153037

Af is het niet, maar iets boven niets geldt hier. De code stelt je nu in ieder geval in staat om een he.net ipv6 tunnel van tunnelbroker.net te termineren en het /64 subnet te gebruiken op het LAN.
Firewalling werkt iig ook, de route advertising daemon staat nog op de todo voor DNS servers. Stateless autoconf werkt wel iig.

Goed werk!!

Ik werk al jaren met Pfsense, maar alleen ipv6 support ontbreekt nog. Staat volgens mij voor versie 2.1 op de planning.

Pfsense is tenslotte een fork van M0n0wall en die ondersteunt al jaren ipv6. Kan je daar niet wat code van gerbuiken?

[Raven]

IPv6 ondersteuning zit er wel in, althans, in het onderliggende OS (FreeBSD). Maar pfSense zelf dus niet.
Heb hier v1.2.3 en wil deze howto een keer proberen.

[ Voor 8% gewijzigd door Raven op 29-10-2010 18:41 ]

[databeestje]

bdegroot schreef op vrijdag 29 oktober 2010 @ 17:34:
[...]


Goed werk!!

Ik werk al jaren met Pfsense, maar alleen ipv6 support ontbreekt nog. Staat volgens mij voor versie 2.1 op de planning.

Pfsense is tenslotte een fork van M0n0wall en die ondersteunt al jaren ipv6. Kan je daar niet wat code van gerbuiken?

Klopt inderdaad, we zitten inmiddels al redelijk dicht bij een RC release voor pfSense 2.0 Er zijn nog wel wat dingen die gepolijst moeten worden. Er worden er inmiddels al redelijk wat uitgezet voor productie. Het wordt inmiddels ook al ondersteund van de commerciele support.

Er zijn gewoon dingen die 1.2.3 niet kan welke wel mogelijk zijn met 2.0.

Ik heb het afgelopen week er nog over gehad maar we focussen de efforts eerst op 2.0, dan 2.1. Maar wees gerust. De ipv6 feature is het eerste wat aangepakt gaat worden voor 2.1.

Wat betreft die code van m0n0wall, nou, nee. Het kost me meer tijd om de code van m0n0wall te schoenlepelen in pfSense dan het zelf nieuw te schrijven. Met een weekje tijd en wat tussen de werkzaamheden door programmeren op het werk ben ik al een heel eind gekomen.

IPv6 support raakt gewoon alles wat je doet in pfSense, dus nee, ik schiet er niet veel mee op.

@raven: Die howto heb je met die git repo van mij dus niet meer nodig. Je kan nu gewoon in de UI een gif tunnel aanmaken op 2.0Beta 4, dan vervolgens als een opt interface toewijzen.
Vervolgens kan je een gateway aanmaken onder "routing" welke dan ook zichtbaar wordt in de UI en op de interfaces pagina.

Als je een bestaande pfSense 2.0 Beta 4 hebt van october 26 of later kan je via optie 12 "playback gitsync" uitvoeren. Dan geef je de url van mijn git repo op en heb je circa 5 minuten later de code op je firewall staan.

Het is nog niet helemaal duidelijk of we deze code boom straks weer mergen met mainline of dat dit geschrapt wordt. Daarvoor is het nog te vroeg. In mainline mocht mijn code iig niet

Voor volgende week staat het afmaken van de route advertising deamon op het plan.
Statische ipv6 configuratie op wan en lan werkte overigens al, ik heb met name die tunnel optie gebouwd omdat het gros van de providers in nederland geen native ipv6 heeft.

Overigens dezelfde kwaal die de andere devvers ondervinde, er zijn nog geen isps die zich ermee bezig houden.

Afgelopen week met onze account manager van de KPN gemailed over het FTTO product (we hebben er 2) en waarom er nog niet ipv6 netblokken gereserveerd zijn voor alle klanten met een bestaand ipv4 netblok.
De aanvraag voor een ipv6 netblok voor onze ftto aansluitingen is nog niet succesvol beantwoord. Het wordt opgenomen in de organisatie en we nemen je vraag serieus. Ze komen volgende week met een antwoord/reactie.

Ik had liever gezien dat ze met ipv6 netblokken aan kwamen

[Raven]

Net http://www.xaero.org/inde...-on-the-pfsense-firewall/ eens geprobeerd, de test-pc kan niet pingen/tracert'en ("rapporten: ongeldige bronroute opgegeven") over IPv6, ook niet browsen naar IPv6 sites en pfSense geeft dit in het logboek aan:

code:

rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[59373]: <getconfig> em0 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default

Ik denk dat er ergens een foutje in is geslopen, maar waar?

De gegevens van de tunnel:

code:

Server IPv4 address:    216.66.84.46
Server IPv6 address:    2001:470:1f14:e04::1/64
Client IPv4 address:    82.74.212.183
Client IPv6 address:    2001:470:1f14:e04::2/64 
Anycasted IPv6 Caching Nameserver:      2001:470:20::2
Anycasted IPv4 Caching Nameserver:  74.82.42.42
Routed /64:     2001:470:1f15:e04::/64

Note: em0 = LAN, em1 = WAN

code:

#!/bin/sh
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em0"
DFGW="2001:470:1f14:e04::1"

####### Configure the stuff

# Configure the interfaces
ifconfig $IFOUT create
ifconfig $IFOUT tunnel 82.74.212.183 216.66.84.46
ifconfig $IFOUT inet6 2001:470:1f14:e04::2 prefixlen 64
route -n add -inet6 default 2001:470:1f14:e04::1
ifconfig $IFOUT up

ifconfig $IFIN inet6 alias 2001:470:1f14:e04::2 prefixlen 64

# Set the default route
route -n add -inet6 default $DFGW

# Configure IPv6 forwarding
sysctl net.inet6.ip6.forwarding=1

# My /etc/rtadvd.conf looks like this
#
# bce1:\
#   :addrs#1:addr="2001:470:1f14:e04::":prefixlen#64:tc=ether:
#
# Startup rtadvd
/usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf $IFIN

code:

#!/bin/sh
#
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em0"

####### Configure the stuff

# Configure PF
# pfSense puts it's rules in /tmp/rules.debug for debugging purposes after boot
# We will use these rules, add IPv6 additions, read the config with pfctl and
# disable and enable PF
cat /tmp/rules.debug | sed "/User-defined rules follow/{
p;s/.*/\
pass in quick on $IFIN inet6 from any to any\\
pass out quick on $IFIN inet6 from any to any\\
pass out quick on $IFOUT inet6 from any to any\\
pass quick proto ipv6-icmp from any to any\\
# pass in on $IFOUT inet6 proto tcp from any to any port 22\\
/;}" > /tmp/rules.config-ipv6.txt

# Read the new PF configuration file
pfctl -f /tmp/rules.config-ipv6.txt
pfctl -d; pfctl -e

code:

em0:\
:addrs#1:addr="2001:470:1f14:e04::":prefixlen#64:tc=ether:

code:

Windows IP-configuratie
Ethernet-adapter LAN-verbinding:
        Verbindingsspec. DNS-achtervoegsel: local
        IP-adres. . . . . . . . . . . . . : 192.168.1.197
        Subnetmasker. . . . . . . . . . . : 255.255.255.0
        IP-adres. . . . . . . . . . . . . : fe80::217:3fff:fe9b:f056%4
        Standaardgateway. . . . . . . . . : 192.168.1.1
Ethernet-adapter LAN-verbinding 2:
        Status van medium . . . . . . . . : medium ontkoppeld
Tunnel-adapter Teredo Tunneling Pseudo-Interface:
        Verbindingsspec. DNS-achtervoegsel: 
        IP-adres. . . . . . . . . . . . . : fe80::ffff:ffff:fffd%6
        Standaardgateway. . . . . . . . . : 
Tunnel-adapter Automatic Tunneling Pseudo-Interface:
        Verbindingsspec. DNS-achtervoegsel: local
        IP-adres. . . . . . . . . . . . . : fe80::5efe:192.168.1.197%2
        Standaardgateway. . . . . . . . . :

code:

Interface 6: Pseudo-interface van Teredo Tunneling
  Guid {8793CB06-D619-460F-B8EE-E3D148261B88}
  zones: link 6 site 3
  netwerkkabel niet aangesloten
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  routeringsvoorkeur 2
  adres van Link-laag: 0.0.0.0:0
    preferred link-local fe80::ffff:ffff:fffd, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
  koppelt MTU 1280 (ware MTU-koppeling 1280)
  huidige hop-limiet 128
  bereiktijd 25000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 5: Ethernet: LAN-verbinding 2
  Guid {64CD5864-B715-4A09-ADD8-0A0512937F4F}
  netwerkkabel niet aangesloten
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  adres van Link-laag: 00-1f-d0-36-3e-59
    tentative link-local fe80::21f:d0ff:fe36:3e59, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1:ff36:3e59, 1 refs, laatste melding
  koppelt MTU 1500 (ware MTU-koppeling 1500)
  huidige hop-limiet 128
  bereiktijd 38000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 1
  standaardlengte van voorvoegsel van site 48
Interface 4: Ethernet: LAN-verbinding
  Guid {E3AFFD6F-06CC-4A4E-8E42-BA98E9CB8255}
  zones: link 4 site 2
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  adres van Link-laag: 00-17-3f-9b-f0-56
    preferred link-local fe80::217:3fff:fe9b:f056, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1:ff9b:f056, 1 refs, laatste melding
  koppelt MTU 1500 (ware MTU-koppeling 1500)
  huidige hop-limiet 128
  bereiktijd 16000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 1
  standaardlengte van voorvoegsel van site 48
Interface 3: Pseudo-interface voor 6to4-tunneling
  Guid {A995346E-9F3E-2EDB-47D1-9CC7BA01CD73}
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  routeringsvoorkeur 1
  koppelt MTU 1280 (ware MTU-koppeling 65515)
  huidige hop-limiet 128
  bereiktijd 21500 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 2: Pseudo-interface voor automatische tunneling
  Guid {48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  routeringsvoorkeur 1
  In EUI-64 ingesloten IPv4-adres: 0.0.0.0
  adres van Link-laag van router: 0.0.0.0
    preferred link-local fe80::5efe:192.168.1.197, levensduur infinite
  koppelt MTU 1280 (ware MTU-koppeling 65515)
  huidige hop-limiet 128
  bereiktijd 16000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 1: Loopback-pseudo-interface
  Guid {6BD113CC-5EC2-7638-B953-0B889DA72014}
  zones: link 1 site 4
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  adres van Link-laag: 
    preferred link-local ::1, levensduur infinite
    preferred link-local fe80::1, levensduur infinite
  koppelt MTU 1500 (ware MTU-koppeling 4294967295)
  huidige hop-limiet 128
  bereiktijd 41000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48

[ Voor 45% gewijzigd door Raven op 31-10-2010 18:35 ]

[Icingdeath]

Goed om te horen dat ipv6 support er dan eindelijk aan zit te komen voor Pfsense
Binnenkort maar bleeding edge draaien dan.

Het configureren van ipv6 in freebsd bij pfsense zoals in die link hierboven werkt goed, draait nu zo al een maand of 4 zonder problemen

Kan overigens wel merken of een site over ipv6 bereikbaar is, want die tunnel broker (he.net) die ik gebruik is hier behoorlijk traag.

[Raven]

boonie schreef op maandag 01 november 2010 @ 07:53:
Ik gebruik ook een HE tunnel en merk niets van traagheid. Mijn tunnel termineert in mijn Fritz!box. Voor de clients is het net een native verbinding.

Heb je ICMP voor V6 geblokkeerd waardoor path-mtu discovery niet werkt? Je zou je MTU eens tijdelijk kunnen verkleinen.

Heb je al eens ping testen gedaan?

Gebruik je XP? Daar zit iets niet lekker in waardoor je gelimiteerd bent op zo'n 300 tot 400 KB/s maar dat zou je niet moeten merken met surfen.

Aan wie vraag je dat?

In geval van mijn niet werkende verbinding, ping6 via Putty op pfSense:

code:

[[e-mail]]/root(1): ping6 -c 4 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:470:1f14:e04::2 --> 2a00:1450:8001::93
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1

--- ipv6.l.google.com ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

ICMP toegestaan, anders wilde HE niet eens een tunnel aanmaken.

Icingdeath schreef op zondag 31 oktober 2010 @ 23:34:
Goed om te horen dat ipv6 support er dan eindelijk aan zit te komen voor Pfsense
Binnenkort maar bleeding edge draaien dan.

Het configureren van ipv6 in freebsd bij pfsense zoals in die link hierboven werkt goed, draait nu zo al een maand of 4 zonder problemen

Kan overigens wel merken of een site over ipv6 bereikbaar is, want die tunnel broker (he.net) die ik gebruik is hier behoorlijk traag.

Hmm, zie jij dan toevallig wat ik verkeerd gedaan heb?

[ Voor 17% gewijzigd door Raven op 01-11-2010 23:31 ]

[databeestje]

Ik zal wel even een fatsoenlijk houtoe in elkaar knutselen waar volledig alle stappen instaan welke nodig zijn om vanaf een huidige 2.0-BETA4 mijn boom in te laden van http://rcs.pfsense.org/projects/pfsense/repos/pfSense-smos

Daarna kan ik de rest via de webui configureren. Thuis op de bank met M'n macbook werkt het in ieder geval prima. DHCPv6 voor de lan zijde nog niet werkend kunnen krijgen. De prioriteiten verschuiven dagelijks. De route advertising deamon doet het wel en stateless autoconfig doet zijn werk.

Inmiddels werkt static routing met ipv6 al wel, een klant in amerika heeft mijn ipv6 code nodig. Ze zaten er kennelijk nog al om te springen :-)

Ik heb het inmiddels ook voor elkaar gekregen om een CARP vip aan te maken via de webui voor het LAN. Hij is nog te pingen vanaf het internet ook. De volgende stap is een ipv6 CARP cluster maken voor failover.

Het gaat vooruit!

[Raven]

Raven schreef op maandag 01 november 2010 @ 23:23:
[...]
Aan wie vraag je dat?

In geval van mijn niet werkende verbinding, ping6 via Putty op pfSense:

code:

[[e-mail]]/root(1): ping6 -c 4 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:470:1f14:e04::2 --> 2a00:1450:8001::93
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote ipv6.l.google.com 16 chars, ret=-1

--- ipv6.l.google.com ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Ping6 naar ::1 geeft hetzelfde, dan heb ik de config echt verkloot denk ik dan

edit: pfSense -> System -> Advanced -> "Allow IPv6 traffic" stond uitgevinkt
Ping6'en naar ::1 en ipv6.google.com werkt, later van de week maar eens kijken of de clients er nu gebruik van kunnen maken.

[ Voor 36% gewijzigd door Raven op 03-11-2010 23:45 ]

[databeestje]

@raven: Even het een en ander aan het screenshotten geweest en dat in een kort begeleidend schrijven gestort. Geen idee of je het nog nodig hebt, misschien wel nuttig voor anderen die thuis een pfSense router hebben of er gewoon mee willen experimenteren.

Houtoe:
http://iserv.nl/files/pfsense/ipv6/

[Kompaan]

Ik heb thuis ook een pfSense routertje draaien, ik gaat dit ook maar eens proberen. Dankjewel.

[bdegroot]

databeestje schreef op donderdag 04 november 2010 @ 11:11:
@raven: Even het een en ander aan het screenshotten geweest en dat in een kort begeleidend schrijven gestort. Geen idee of je het nog nodig hebt, misschien wel nuttig voor anderen die thuis een pfSense router hebben of er gewoon mee willen experimenteren.

Houtoe:
http://iserv.nl/files/pfsense/ipv6/

Ik zie dat je met name werkt met de HE tunnels.
Nu maak ik gebruik van sixxs, en die techniek is net weer even anders. Is er een manier om dat ook werkend te krijgen?

Ik heb het nu custom made (met eigen scriptjes) draaien op mijn Pfsense bak, maar het zou mooi zijn indien dat in de interface wordt meegenomen (zoals bij M0n0wall reeds het geval is).

[Raven]

databeestje schreef op donderdag 04 november 2010 @ 11:11:
@raven: Even het een en ander aan het screenshotten geweest en dat in een kort begeleidend schrijven gestort. Geen idee of je het nog nodig hebt, misschien wel nuttig voor anderen die thuis een pfSense router hebben of er gewoon mee willen experimenteren.

Houtoe:
http://iserv.nl/files/pfsense/ipv6/

Ehm, tenzij jouw howto ondertussen ook geschikt is gemaakt voor v1.2.3 (was alleen voor v2 beta toch?) heb ik er niet veel aan . Heb nog niet gekeken of mijn testclient al een IPv6 adresje krijgt. Zo maar eens doen
Maar de tunnel werkt iig, heb meerdere IPv6 sites vanaf console onder pfSense kunnen ping6'en

[databeestje]

bdegroot schreef op donderdag 04 november 2010 @ 16:47:
[...]

Ik heb het nu custom made (met eigen scriptjes) draaien op mijn Pfsense bak, maar het zou mooi zijn indien dat in de interface wordt meegenomen (zoals bij M0n0wall reeds het geval is).

Ik moest ergens beginnen en dit was het. Als ik weet welke commando's er nodig zijn valt dat vast wel ergens in te passen. IK zal me even moeten verdiepen in het geheel.

Overigens staat een 6to4 adapter oid ook op het plan. Alleen zit CARP failover nu even net iets hoger in de lijst.

[Raven]

Mijn test-pc (met XP SP3) krijgt geen verbinding met IPv6 sites (Google even als voorbeeld):

code:

Microsoft Windows XP [versie 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>ping6 ipv6.google.com

Bezig met pingen van ipv6.l.google.com [2a00:1450:8001::63]
vanaf 2001:470:1f14:e04:fca2:5a6:af78:e7ad met 32 bytes aan gegevens:

Antwoord van 2001:470:1f14:e04:fca2:5a6:af78:e7ad: Doeladres niet bereikbaar.
Antwoord van 2001:470:1f14:e04:fca2:5a6:af78:e7ad: Doeladres niet bereikbaar.
Antwoord van 2001:470:1f14:e04:fca2:5a6:af78:e7ad: Doeladres niet bereikbaar.
Antwoord van 2001:470:1f14:e04:fca2:5a6:af78:e7ad: Doeladres niet bereikbaar.

Ping-statistieken voor 2a00:1450:8001::63:
    Pakketten: verzonden = 4, ontvangen = 0, verloren = 4
               (100% verlies),

C:\Documents and Settings\Administrator>

edit: Ook niet via de browser dus

Ik vermoed dat de firewall nog dwarszit, ondanks het aanvinken van "allow all IPv6 traffic":


edit: net even reboot van pfSense gedaan, zie deze melding nog wel in log:

code:

rtadvd[843]: <getconfig> em0 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default

Dat screenshot is ook vaag.
Net weer ping6jes zitten doen vanaf router zelf, die worden netjes beantwoord maar staan wel als blocked in firewall log

En ik ben net tot de ontdekking gekomen dat bij het starten van die 2 scripts het CF-kaartje schrijfbaar moet zijn en niet read-only.... (Draai embedded versie.)

[ Voor 21% gewijzigd door Raven op 04-11-2010 20:30 ]

[databeestje]

Wat je ziet is dat de XP PC router sollicitaties uit stuurt naar ff02::01. Dit is het multicast adres voor routers.

Check of rtadvd op je pfSense machien aan staat op je LAN interface.
ps auxww|grep rtadvd
Wat ik net bedenk is dat je firewall rules voor dit multicast adres aan zal moeten maken. In mijn versie worden deze specifieke regels al in de achtergrond aangemaakt.

Ik heb eerlijk gezegd geen idee of de ui in 1.2.3 je dat toestaat. Misschien dat een any any rule op je lan interface het wel op pikt. dat wil zeggen, elke bron, elke bestemming.

Als dat niet werkt zal je misschien toch aan 2.0 BETA 4 moeten. Het is inmiddels wel zo dat deze al op veel plaatsen in productie is. Dan met name bij klanten die een actief support contract hebben. Op het werk gebruiken we het voor onze SSL VPN server in combinatie met AD authenticatie. Viscosity op de Mac werkt hier erg goed mee, en nog beter nieuws is dat deze client naar windows komt!

Bewaar een 1.2.3 config.xml en houd de live cd bij de hand. Als je dat hebt kan je snel weer terug als 2.0 je niet bevalt. Als je de config.xml op een usb stick zet in een \conf directory dan pickt de live cd hem automatisch op. Deze wordt tijdens het installeren dan ook meteen meegenomen.

[Raven]

databeestje schreef op donderdag 04 november 2010 @ 20:33:
Wat je ziet is dat de XP PC router sollicitaties uit stuurt naar ff02::01. Dit is het multicast adres voor routers.

Check of rtadvd op je pfSense machien aan staat op je LAN interface.
ps auxww|grep rtadvd
Wat ik net bedenk is dat je firewall rules voor dit multicast adres aan zal moeten maken. In mijn versie worden deze specifieke regels al in de achtergrond aangemaakt.

Ik heb eerlijk gezegd geen idee of de ui in 1.2.3 je dat toestaat. Misschien dat een any any rule op je lan interface het wel op pikt. dat wil zeggen, elke bron, elke bestemming.

Als dat niet werkt zal je misschien toch aan 2.0 BETA 4 moeten. Het is inmiddels wel zo dat deze al op veel plaatsen in productie is. Dan met name bij klanten die een actief support contract hebben. Op het werk gebruiken we het voor onze SSL VPN server in combinatie met AD authenticatie. Viscosity op de Mac werkt hier erg goed mee, en nog beter nieuws is dat deze client naar windows komt!

Bewaar een 1.2.3 config.xml en houd de live cd bij de hand. Als je dat hebt kan je snel weer terug als 2.0 je niet bevalt. Als je de config.xml op een usb stick zet in een \conf directory dan pickt de live cd hem automatisch op. Deze wordt tijdens het installeren dan ook meteen meegenomen.

code:

[[e-mail]]/root(1): ps auxww|grep rtadvd
root     846  0.0  0.1  3156  1012  ??  Ss    8:08PM   0:00.14 /usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf em0
root   11999  0.0  0.0   376   256  p0  R+   10:09PM   0:00.00 grep rtadvd
[[e-mail]]/root(2):

em0 = LAN.

Uhm, dus dat ene vinkje van Allow IPv6 traffic (All IPv6 traffic will be blocked unless this box is checked) is niet voldoende?

Die any any rule staat al in een van die scripts (10_config-ipv6-pf.sh), zie Raven in "Het grote IPv6 topic"

Als het niet onder v1.2.3 zou werken, waarom is de howto die ik heb gebruikt dan specifiek gericht op v1.2.3?

edit: Hmm, net even Windows 7 geprobeerd (testte voorheen met XP), hier kan ik ook geen IPv6 sites bezoeken, maar krijg wel antwoord via een ping -6 naar ipv6.google.com, al zitten er wel een paar time-outs tussen.
En nu doelhost is niet bereikbaar

[ Voor 4% gewijzigd door Raven op 05-11-2010 17:39 ]

[databeestje]

Het is veruit de meest gemaakte fout die ik op de diverse fora heb gezien. Het routed subnet verschilt 1 karakter met het subnet dat voor de routing gebruikt wordt van de gif tunnel.

Ik heb kortstondig naar de aiccu utility gekeken op de wiki's maar nog niet direct een beeld kunnen vormen. De static tunnel config van Sixxs is overigens hetzelfde als bij Hurricane Electric. Dus dat scheelt weer.
Het automatische herconfigureer karakter van aiccu speelt wat parten in pfSense, dat wil zeggen, de staat van het systeem verandert en pfSense weet dat niet. Het ziet niet in de config.

Overigens krijg ik aankomende week mijn native xs4all ipv6 blok voor onze colocatie. Ik kijk er naar uit. Dan kan ik het eindelijk failover fatsoenlijk testen en onze eerste NS op ipv6 op het net toveren.

[databeestje]

Zoals al eerder werd aangegeven is het niet praktisch om met de /64 regel te breken. Dat is buiten de spevs waarna de hele zooi in elkaar dondert. Het goeie nieuws dat xs4all het geen punt vind om de /48 naar een ip naar keuze uit de /64 te sturen.

PfSense doos is nu succesvol online iig en ik kan ipv6 op het man netwerk.

Is er ook een mobiel got dat sneller werkt op de bb storm?

[Raven]

Roetzen schreef op donderdag 13 januari 2011 @ 18:12:
[...]


[...]

Misschien sla ik de plank volledig mis. maar ik bewtijfel toch of dat laatste wel klopt.

Wat XP niet ondersteunt is DHCP6. Dat betekent dat je niet automatisch de IPv6 adressen van de DNS servers krijgt toegewezen. Maar je kan ze wel handmatig invoeren. Zoals ik hier gedaan heb:

knipknip

Ehm... Dus eigenlijk zou ik dan geen IPv6 verbinding moeten hebben? Heb een HE tunnel in mijn pfSense router ingesteld, mbv een howto die in mijn eerdere posts is terug te vinden, waarna ik een "ipv6 install" bij mijn XP-test installatie deed. Daarna deed de verbinding het al, zonder ook maar iets in te stellen onder XP.

XP ondersteund dus wel DHCP6? Of snap ik het niet

[Raven]

Dan zal ik later maar eens kijken of dat onder FreeBSD ook kan.
Heb deze howto gebruik: http://www.xaero.org/inde...-on-the-pfsense-firewall/ voor de tunnel.

[ Voor 5% gewijzigd door Raven op 14-01-2011 20:00 ]

[jimmy87]

Ik heb dus dezelfde howto gebruikt als Raven, nog bedankt voor de link
Nu heeft mijn pfsense bakje mooi ipv6 maar hij deelt geen ips uit aan de workstations.

Ik heb de Allow ipv6 optie ingeschakeld staan.
Even de volgende gegevens, misschien zien jullie waaar ik wat fout heb gedaan want ik zie het niet meer

mijn HE.net info:

code:

Server IPv4 address: 216.66.84.46 
Server IPv6 address: 2001:470:1f14:91::1/64 
Client IPv4 address: 82.101.251.5 
Client IPv6 address: 2001:470:1f14:91::2/64 
Routed /64: 2001:470:1f15:91::/64

em0 = wan
em1 = lan

00_config-ipv6-if.sh

code:

#!/bin/sh
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em1"
DFGW="2001:470:1f14:91::1"

####### Configure the stuff

# Configure the interfaces
ifconfig $IFOUT create
ifconfig $IFOUT tunnel 82.101.251.5 216.66.84.46
ifconfig $IFOUT inet6 2001:470:1f14:91::2 prefixlen 64
route -n add -inet6 default 2001:470:1f14:91::1
ifconfig $IFOUT up

ifconfig $IFIN inet6 alias 2001:470:1f14:91::2 prefixlen 64

# Set the default route
route -n add -inet6 default $DFGW

# Configure IPv6 forwarding
sysctl net.inet6.ip6.forwarding=1

# My /etc/rtadvd.conf looks like this
#
# bce1:\
#   :addrs#1:addr="2001:db8:0:2::":prefixlen#64:tc=ether:
#
# Startup rtadvd
/usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf $IFIN

10_config-ipv6-pf.sh

code:

#!/bin/sh
#
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em1"

####### Configure the stuff

# Configure PF
# pfSense puts it's rules in /tmp/rules.debug for debugging purposes after boot
# We will use these rules, add IPv6 additions, read the config with pfctl and
# disable and enable PF
cat /tmp/rules.debug | sed "/User-defined rules follow/{
p;s/.*/\
pass in quick on $IFIN inet6 from any to any\\
pass out quick on $IFIN inet6 from any to any\\
pass out quick on $IFOUT inet6 from any to any\\
pass quick proto ipv6-icmp from any to any\\
# pass in on $IFOUT inet6 proto tcp from any to any port 22\\
/;}" > /tmp/rules.config-ipv6.txt

# Read the new PF configuration file
pfctl -f /tmp/rules.config-ipv6.txt
pfctl -d; pfctl -e

/etc/rtadvd.conf

code:

em1:\
:addrs#1:addr="2001:470:1f15:91::":prefixlen#64:tc=ether:

Ik dacht eerst misschien draait rtadvd niet maar dat is dus wel het geval.

code:

# ps auxww|grep rtadvd
root    1121  0.0  0.1  3156  1012  ??  Is    9:20PM   0:00.00 /usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf em1
root    1570  0.0  0.2  3508  2228  p0  RV    9:23PM   0:00.00 grep rtadvd (tcsh)
#

Het gaat hier allemaal om Windows 7 pc's.

[jimmy87]

Inmiddels werkt het
Iets met firewall op Windows pc die het tegenhield.

Als ik nu een ipv6 website wil opvragen of pingen werkt deze niet.
Ik heb die ipv6 optie enabled in pfsense.
Nu moeten er natuurlijk een aantal rules zijn voor dat verkeer maar die worden met dat 2de config bestand aangemaakt.

Pings geven aan de doelhost is niet bereikbaar of geven een time-out.

[ Voor 30% gewijzigd door jimmy87 op 16-01-2011 22:48 ]

[Raven]

Heb je heel toevallig ook de embedded/nanobsd versie van pfSense?

[ Voor 6% gewijzigd door Raven op 17-01-2011 11:03 ]

[jimmy87]

Raven schreef op maandag 17 januari 2011 @ 11:01:
Heb je heel toevallig ook de embedded/nanobsd versie van pfSense?

Nee helaas hier draait het op een 80GB Sata schijf.
Maar waar dacht je aan?

[Raven]

Embedded/NanoBSD heeft het fs (op een CF-kaart in mijn geval) readonly gemaakt, bij het uitvoeren van een van die 2 scriptjes moet er iets weggeschreven worden. Dat kan dus niet met een readonly fs

Hier moet ik dan eerst /etc/rc.conf_mount_rw uitvoeren, dan scripts runnen, gevolgd door /etc/rc.conf_mount_ro.
Na elke (her)start van pfSense dus, wat niet vaak voorkomt.

[ Voor 3% gewijzigd door Raven op 17-01-2011 21:53 ]

[jimmy87]

Volgens mij heb ik daar geen last van, de pfsense bak werkt al wel op ipv6 en rtadvd deelt ook gewoon ip's uit. Het lijkt net of er een paar dingen ontbreken ofzo.

[jimmy87]

Raven schreef op dinsdag 18 januari 2011 @ 09:40:
Hmm, in dat geval, zeker weten dat je het vinkje voor "Allow IPv6 traffic" hebt aangezet onder system -> advanced?

Of misschien dezelfde fout gemaakt als ik? (Een nummertje verkeerd...)

Hmm nee dat is het ook niet. Dat vinkje staat er ook inderdaad. Moet ik die proto 41 trouwens forwarden naar de pfsense bak zelf of kan ik die gewoon leeg laten?

[Raven]

Okee, bij mij juist andersom

Wel juiste externe ip ingesteld bij de tunnel bij HE?

Welke versie van pfSense heb je trouwens? v1.2.3 of een v2 beta?

[ Voor 27% gewijzigd door Raven op 18-01-2011 13:00 ]

[Snow_King]

jimmy87 schreef op dinsdag 18 januari 2011 @ 21:58:
Ipv4 adres van HE is wel te pingen en fs is volgens mij writable, dit krijg ik als ik fstab opvraag namelijk:

# cat fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/ad0s1a / ufs rw 1 1

Ik heb even een screenshot gemaakt van hoe de netwerk instellingen eruit ziet op een Windows 7 client.

[afbeelding]

Wat ik me afvraag is die gateway en geen dns adres Hoe staat dit bij jou?

Die gateway klopt, dat is je link-local adres van de gateway, niets mis mee.

De DNS wordt standaard niet door radvd uitgestuurd, dus dat is ook in orde.

Ik denk dat het in de routering fout gaat in de pfSense. Ik gebruik echter de zelfde scripts en die werken prima.

[databeestje]

Ik zie hier een vergelijkbaar probleem als waar ik zelf ook tegenaanliep. Wat ik heb gedaan is gebruik maken van ULA adressen op de LAN netwerken, bij Sixxs even een unieke ULA geregistreerd en een ::/48 toegewezen gekregen.

Daarnaast heb ik in mijn pfSense source tree "Network Prefix Translation" ondersteuning ingebouwd.

Met andere woorden, ik kan weer gewoon policy routing en multiwan doen voor de hele toko. En pfSense bepaalt waar het verkeer heen gaat op 1 centrale plaats. Statisch routes en firewall rules regelen alles. Wel zo beheersbaar.

Wat Network Prefix Translation (NPt voorheen NAT66 genoemd) doet is het vervangen van het linker 64 bit deel door het global unicast network prefix, de rechter 64 bits, het computer adres blijft hetzelfde.

Wat dit realiseert is dat ik op alle 3 de WAN verbindingen (1 native ::/56 en 2 HE.net ::/48's) verbinding naar binnen en buiten kunnen maken. Het is dus geen Port translatie maar enkel een adres mapping. Hierdoor blijft end-to-end connectiviteit gewaarborgt en is het gehele netwerk via alle 3 verbindingen te bereiken.

Omdat van de 3 wan verbindingen deze verschillen in snelheid kan ik door policy routing alles per default de snelle pijp uit sturen.

Ik heb wel gekeken naar de PI space voor IPv6 en IPv4 maar dat is een beetje lastig scenario aan het worden met de huidige crunch voor ipv4. Daarnaast moet het ook maar zo zijn dat de ISP's BGP ondersteunen, en een ::/56 wordt ook niet door alle Peers in de BGP table opgenomen.

[databeestje]

Heeft iemand hier goede documentatie met betrekking tot de DHCP-PD spec? Ik moet in pfSense hier support voor gaan bouwen maar Ziggo doet hier uiteraard niet aan. Met het bouwen van een VMtje heb ik wel een start maar ik moet dus ook een server opzetten die dus prefixes aan clients gaat uitdelen en een pfSense client die er een aanvraagd en op het Lan configureerd.

Pointers? Ik weet eigenlijk niet eens of het kan met de ISC dhcpd

[databeestje]

TrailBlazer schreef op woensdag 26 januari 2011 @ 22:13:
De default firewall zal hoogstwaarschijnlijk voor ipv6 net zo veilig worden als de huidige nat firewalls. Daar zou ik me echt geen zorgen over maken.

Dat kan je hopen. Vrijwel alle thuis routers met firmwares enzo zie ik zonder firewall rules.

Ik ben thuis wel blij met m'n pfSense, die heeft tenminste gewone firewall rules voor inbound en outbound verkeer.

De wereld zal echt wel aan de fatsoenlijke firewalls moeten, er zal ook wel weer een variant op uPNP gemaakt moeten worden om de firewall rules aan te maken op je router. Anders komt je Xbox echt niet online en zal niemand je game kunnen joinen.

De NAT44 pinhole truck die skype, xbox en de rest gebruiken gaat echt niet werken met een normaal gerouteerd netwerk op ipv4 of ipv6. Je moet dan echt een fatsoenlijke firewall rule hebben die het verkeer naar binnen toe doorlaat. Het begrip "port forward" zal hier wel weer voor misbruikt gaan worden.

[zx9r_mario]

Ik wil mijn zyxel ipv4 modem vervangen door m0n0wall of pfsense v1 icm sixxs/he tunnel.

m0n0wall heeft standaard ipv6. Pfsense moet ipv6 nog geactiveerd worden. Welke kan ik het beste gebruiken en heeft pfsense ook firewall rules voor ipv6?

[Raven]

zx9r_mario schreef op donderdag 27 januari 2011 @ 12:57:
Ik wil mijn zyxel ipv4 modem vervangen door m0n0wall of pfsense v1 icm sixxs/he tunnel.

m0n0wall heeft standaard ipv6. Pfsense moet ipv6 nog geactiveerd worden. Welke kan ik het beste gebruiken en heeft pfsense ook firewall rules voor ipv6?

pfSense ondersteund IPv6 niet, pas vanaf 2.1 wel, het onderliggende OS van pfSense v1.2.3 ondersteund het echter wel. Daar is een howto voor (blader mijn posts maar eens door in dit topic ) maar hoe het met firewall rules zit weet ik niet.

[zx9r_mario]

Ik heb wat firewall's bekeken. M0n0wall is blijkbaar de enige die ipv6 goed ondersteund (ook webbased ipv6 firewall rules). Pfsense 2.0 ondersteund ipv6 wel, maar dan moet je in de console gaan werken.

UTM zoals Untangle en Endian ondersteunen geen ipv6, dus blijft voorlopig alleen M0n0wall als enigste over.

Iemand nog suggesties?

[databeestje]

@Zsub: Nog geen tijd gehad, ik probeer eerst dhcpv6 server aan te zwengelen. Als ik dat werkend heb kan ik gaan proberen daar een dhcp-pd in te werken.

Als dat gedaan is kan ik gaan werken aan dhcpv6 client support.

zx9r_mario schreef op vrijdag 28 januari 2011 @ 13:08:
Ik heb wat firewall's bekeken. M0n0wall is blijkbaar de enige die ipv6 goed ondersteund (ook webbased ipv6 firewall rules). Pfsense 2.0 ondersteund ipv6 wel, maar dan moet je in de console gaan werken.

UTM zoals Untangle en Endian ondersteunen geen ipv6, dus blijft voorlopig alleen M0n0wall als enigste over.

Iemand nog suggesties?

Mijn pfSense 2.0 branch [1] met IPv6 ondersteuning werkt met static IPv6 configuratie en firewall rules werken gewoon via de WebUI. Enige vorm van een dynamische WAN met IPv6 ondersteuning zit er nog niet in. Daarvoor moet je echt bij m0n0 zijn.

In de Xs4all Colo gebruik ik sinds november 2010 mijn IPv6 code op pfSense 2.0 in een carp configuratie. Afgelopen week heb ik de failover getest en dat bleek ook nog te werken. Dit is uiteraard een static IP config, maar uiteraard prog ik eerst wat ik nodig heb.

edit: De url met de images uit de ~sullrich directory zijn inderdaad images die gebouwd zouden moeten zouden zijn met de code uit mijn git repo. Dat is iets sneller als 2.0 installeren en dan via de console "playback gitsync" te gebruiken. Uiteindelijk moet je toch nog een gitsync doen om bij te blijven, dus zoveel maakt dat ook niet uit. [b]Deze blijken dus niet te werken, nieuw url volgt nog[b]

Er is een protocol in de dropdown bijgekomen die IPv4 of IPv6 aangeeft, deze moet wel goed staan.

[1] http://iserv.nl/files/pfsense/ipv6/ https://rcs.pfsense.org/projects/pfsense/repos/pfSense-smos

[ Voor 20% gewijzigd door databeestje op 28-01-2011 14:47 ]

[zx9r_mario]

Als ik een ipv6 adres invul binnen pfsense 2.0b (laatst recente) in een rule, dan is het adres ongeldig

PS. Gebruik je een custom pf met ipv6 : http://cvs.pfsense.org/~sullrich/ipv6/

[ Voor 28% gewijzigd door zx9r_mario op 28-01-2011 14:13 ]

[databeestje]

zx9r_mario schreef op vrijdag 28 januari 2011 @ 14:06:
Als ik een ipv6 adres invul binnen pfsense 2.0b (laatst recente) in een rule, dan is het adres ongeldig

PS. Gebruik je een custom pf met ipv6 : http://cvs.pfsense.org/~sullrich/ipv6/

Hartelijk dank, ik kom er dus net achter dat de bovengenoemde images niet met de juiste Git repo gebouwd zijn. Ik heb Scott een mail gestuurd om deze te verwijderen. Jim is nu nieuwe aan het bouwen die het hopelijk wel hebben.

Nogmaals bedankt voor de feedback.

[jimmy87]

Raven en wat anderen hebben mij eerder geholpen. Toen was alles werkend ook op de clients.
Inmiddels heb ik het net nog eens getest en nu is de boel niet meer te pingen.

Op de pfsense machine kan ik bijv ipv6.google.com nog wel pingen. Maar op de clients niet meer, ik heb verder niets veranderd aan de config.

Firewall van mijn client staat uit, en ik weet niet meer waar het probleem nu ligt. Iemand die mij hierin verder kan helpen ?

Mijn pc krijgt wel gewoon een ipv6 ip, ratvd werkt dus wel.

[ Voor 6% gewijzigd door jimmy87 op 28-01-2011 21:23 ]

[databeestje]

In het geval van pfSense, check of het ipv6 forwarding sysctl aan staat, allow IPv6 op de advanced page aan staat en er een firewall rule op het lan is voor any -> any

In mijn pfsense 2.0 branch kan je een ipv6 firewall rule maken op lan voor lan net -> any.
Daar kan je ook de status iets beter bekijken van de verbinding(en).

De images van Jim zijn inmiddels klaar http://cvs.pfsense.org/~jimp/ipv6/

[ Voor 10% gewijzigd door databeestje op 28-01-2011 23:11 ]

[jimmy87]

databeestje schreef op vrijdag 28 januari 2011 @ 23:10:
In het geval van pfSense, check of het ipv6 forwarding sysctl aan staat, allow IPv6 op de advanced page aan staat en er een firewall rule op het lan is voor any -> any

In mijn pfsense 2.0 branch kan je een ipv6 firewall rule maken op lan voor lan net -> any.
Daar kan je ook de status iets beter bekijken van de verbinding(en).

De images van Jim zijn inmiddels klaar http://cvs.pfsense.org/~jimp/ipv6/

Allow ipv6 stond al aan want het heeft wel gewerkt.
Evenals de rule voor any -> any

Hoe kan ik die laatste controleren?

[databeestje]

nhimf schreef op vrijdag 04 februari 2011 @ 12:39:
Het valt me erg op dat fabrikanten heel erg onduidelijk zijn over ipv6 en welke apparaten wat wel en niet ondersteunen.
Alle hulp hierbij is welkom :-)

Wat ik thuis gebruik is een PCEngines.ch Alix 2D3 met pfSense op een CF kaart.
Kosten van de Alix is ~90 euro met een 10tje verzendkosten vanuit zwitserland. CF card is een schijntje.

Daar draai ik pfSense op, de huidige 1.2.3 ondersteunt het nog niet, de 2.0 beta ook niet met uitzondering van mijn experimentele ipv6 branch.

Wat ik de meeste ISPs zien doen is een /56 toewijzen en routeren via het connectie subnet naar de ::2, de isp is dan meestel ::1 (de gateway).

Dit is in ieder geval zoals Unet het doet met zijn native zakelijke connectiviteit.

Leuk grafiekje gevonden op http://ipv6ripeness.ripe.net/

nederland grafiekje

[ Voor 20% gewijzigd door databeestje op 04-02-2011 13:34 ]

[nhimf]

databeestje schreef op vrijdag 04 februari 2011 @ 13:18:
[...]


Wat ik thuis gebruik is een PCEngines.ch Alix 2D3 met pfSense op een CF kaart.
Kosten van de Alix is ~90 euro met een 10tje verzendkosten vanuit zwitserland. CF card is een schijntje.

Daar draai ik pfSense op, de huidige 1.2.3 ondersteunt het nog niet, de 2.0 beta ook niet met uitzondering van mijn experimentele ipv6 branch.

Wat ik de meeste ISPs zien doen is een /56 toewijzen en routeren via het connectie subnet naar de ::2, de isp is dan meestel ::1 (de gateway).

Dit is in ieder geval zoals Unet het doet met zijn native zakelijke connectiviteit.

Leuk grafiekje gevonden op http://ipv6ripeness.ripe.net/

nederland grafiekje

Het komt er eigenlijk op neer dat ik dus twee reeksen toegewezen krijg, waarvan ikzelf er maar echt kan gebruiken. Het ip op de externe kant van de router heeft een IP in het "Tussen isp en CPE" reeks en de interne kant van de router en mijn eigen netwerkje krijgen dus ip's in de "Gebruiks" reeks.

Eigenlijk iets als:

(ISP router) ----- IP reeks 1 ----- (CPE) -------- ip reeks 2 ---- (PC)

Uiteraard is reeks 2 gewoon extern bereikbaar.

[databeestje]

Roetzen schreef op dinsdag 08 februari 2011 @ 17:15:
Dat laatste lokt me niet erg en ik had gehoopt de aanschaf van een nieuwe router nog even uit te stellen tot de prijzen wat zakken. Nu zijn routers met IPv6 ondersteuning nog relatief duur.

PCengines.ch Alix 2D3 met pfSense of m0n0wall? Kost ~90 euro met een tientje verzendkosten.

[YaNightmare]

Hallo allemaal,

Ik heb "even" een vraagje, ben een beetje het bomen bos weg kwijt ;-)

Ik heb een fiber verbinding (via Glasvezelnet KPN, met als provider UNET)

Op mijn genexis komt op poort 1 internet binnen (50Mbit) met PPPoE

Nu heb hier hierachter momenteel de volgende config:
Linksys WRT610N v2 met dd-wrt
Ik heb een vast wan ip (/32)
hierachter heb ik een /28 ipv4 public subnet op een aparte poort, de rest is gewoon NAT (wireless en pcs)

Het subnet word gebruikt voor een aantal servers (download, mail, web etc), stuk of 6 momenteel

Probleem:
Nu heb ik sinds vandaag ook een IPv6 subnet via UNET (/56), deze word via DHCPv6 en Router Advertisement uitgedeeld.

Ik wil native IPv6 kunnen draaien (dd-wrt kan dit alleen aan de NAT kant, niet native over WAN als ik alles goed begrijp).

Ik heb hiervoor een aparte machine (1,7 Ghz celeron, 512mb, 120Gb hdd (raid1) 3x NIC)

Mijn eisen zijn:
- Firewall config enkel op de router (de servers moeten extern bereikbaar blijven op zowel ipv4 en ipv6 maar geen firewall hebben) ik gok dat ik dan hoe dan ook 1:1 NAT moet gaan gebruiken hiervoor
- Intern netwerk (laptops, xbox etc mag allemaal een standaard reeks hebben, liefst ook ipv6 erbij).

Ik heb zitten kijken naar pfSense (mede door Databeestje zijn ontwikkelingen) maar ik kom er niet uit of bovenstaande eisen wel haalbaar zijn met pfSense, ipv4 moet wel lukken, maar ipv6 erbij word misschien moeilijk.

Tevens verschillende *NIX distro's bekeken, maar de meeste ondersteunen geen ipv6 of als ze dit wel doen ondersteunen ze mijn eisen niet.

Ik ben nu een beetje ten einde qua ideeen, ben ik onreeel of mis ik iets wat voor de hand ligt ?

Mocht iemand een advies hebben of een oplossing hoor ik dit heel graag !

PS, alhoewel mijn eisen zijn hoe ik het het liefst heb ben ik zeker voor rede vatbaar om een andere implementatie te gebruiken, zolang ik mijn servers maar verschillende IP's kan geven (evt VIP bv).

als er meer info nodig is hoor ik het graag.

[databeestje]

@Yanightmare: Het grote probleem met de FTTO is dat de MTU 1492 is, de router van de KPN doet dan ook mss clamping op 1452 bytes zodat tcp verkeer op IPv4 toch werkt. Het kan werken, dat hoop ik tenminste, maar de eindeloze problemen die ik heb ondervonden op onze 2 FTTO verbindingen is knudde.

Dat de KPN geen native v6 kan aanbieden is overigens de overtreffende trap.

Je merkt snel genoeg of het wel en niet werkt, het raadplegen van dumpert.nl is genoeg om in de gaten te hebben of je een MTU issue hebt. Ik heb de MTU van de client systemen naar 1432 gezet. Dan werkt het wel.

Je krijgt van UNET netjes een /56 toegewezen, dat is oke. Als het goed is kan je met een statische route op de wrt610 aangeven dat deze de netwerken door moet sturen naar het ipv6 adres van je router/firewall intern die voor je servers zit.

Ik zag je post ook op het pfSense forum, deze versie is water beter leesbaar. Idealister wil je gewoon een ethernet router zoals de wrt610n die allebei doet. Helaas gaat linksys nooit een firmware voor dat ding uitbrengen. Ik gebruik de mijne thuis dan ook alleen als een accesspoint.

Internet -> wrt610n -> pfSense -> servers
de wrt610n zal dus statische routes hebben die verwijzen naar pfSense(of een ander, m0n0wall)
wrt610n = 2a02:<foo>:0100::1 /64
pfSense wan = 2a02:<foo>:0100::2 /64
2a02:<nogiets>::/56 via 2a02:<nogiets>::2
pfSense lan = 2a02:<foo>:0101::1 /64

Wat de linksys dan zal doen is alles van die /56 doorsturen naar pfSense je kan dan /64 netwerken uit deze /56 range gebruiken voor de andere netwerken, zoals 0101 voor het lan en 0102 voor het DMZ. Het is een router, NAT doen we niet meer (pssst, het kan wel, maar we doen het niet).

Je situatie wordt er een eind makkelijker op als je de wrt610n vervangt door een enkele router welke gewoon beide kan.

Mijn ervaring met Unet is dat zij op jouw verzoek best wel een statische route willen maken om de /56 naar de ::2 te sturen.

[YaNightmare]

@Databeestje Thnx ! ik ga hier eens inkijken, ik wou eigenlijk de WRT610n achter pfsense hangen als switch, puur voor de wireless ^^,

Ik heb geen KPN modem, fiber word afgeleverd op de Genexis, is een custom oplossing (heb ~ 5 jaar bij UNET gewerkt, dus vandaar dat ik de setup zo voor elkaar heb, pssstt niet doorvertellen ;-) ) evt een statische route zal dan ook geen probleem zijn

En dat MTU probleem waar je het over hebt heb ik vanaf thuis niet, echter wanneer ik mijn verkeer tunnel door SSH naar een van de servers en vervolgens ga browsen (wat je bijvoorbeeld op je werk zou doen als je niet wil dat systeembeheer ziet wat je aan het doen bent ;-) heb ik wel MTU problemen (enkel met FF4beta, met 3.6 geen enkel probleem).

iig, uit jou verhaal begrijp ik dat de switch naar pfsense een goede zal zijn ? kom ik iig een stukje dichterbij ?

NAT op IPv6 snap ik ;-) maar IPv4 wil ik nog steeds werkend houden dus ik zal een tussenoplossing moeten vinden daarvoor ;-)

Bedankt voor de uitleg, word "langzamerhand" duidelijker, ben behoorlijk roestig met dit soort oplossingen, linux & DSB setups zijn appeltje eitje, maar dit gesubnet en zeker met IPv6 is nog een hersenkraker voor me, maar ik leer weer bij

[databeestje]

@Yanightmare: pfSense, net als m0n0wall is een Dual Stack oplossing, het doet tegelijkertijd IPv4 en IPv6 verkeer in 1 doos, 1 set firewall rules etc.

m0n0wall is overigens inmiddels al veel verder en in principe feature complete. Die boom van mij is daar nog lang niet klaar voor. Zolang het een statische config is werkt het wel met de experimentel pfSense code. Al het andere is er nog niet.

Ik denk dat gezien jouw vragen en firewall rules m0n0wall wel goed genoeg is. Draait ook op een PC, maar een klein Intel Atom doosje is ook genoeg voor 200 mbit full duplex. Heeft ook een WebUI en een config.xml file.

[YaNightmare]

Ok thnx, ik ga wel even m0n0wall installeren en eens testen !

ps, ik wil graag pfSense runnen, het ziet er veel beter uit en gezien het een AT systeem is is het een tikkie overkill voor m0n0 misschien dat ik uiteindelijk kan switchen wanneer pfSense 2.1 beta er is met (hopelijk) ipv6 support

[databeestje]

Je kan prima nat66 gebruiken, op het werk gebruik ik een ULA range voor het lan, deze wordt bij het verlaten van een van onze 3 verbindingen vertaald naar het juiste global prefix van de betreffende lijn.

Werkt prima. Dit is overigens 1:1 nat, dus inkomend verkeer werkt prima met een bijpassende firewall rule.

pfSense ftw.

En nee, met de verbindingen die we hebben is BGP geen optie.

[databeestje]

Roetzen schreef op zondag 27 maart 2011 @ 11:48:
Eh.. volgens mij haal je IPsec en VPN door elkaar....

Toegegeven, het een en het ander zijn niet onlosmakelijk met elkaar verbonden, maar dat wil nog niet zeggen dat het niet veel tegelijkertijd van toepassing is.

Het hele nat uitroeien lijkt op een religieuze oorlog. Ik zie het wat grijzer, hier en daar is er best wel nut voor. De perfecte netwerken zonder rare conflicten bestaan niet, soms moet je door hoepels springen, anders wordt er soms geen geld verdient.

Je wil connectie failover niet door alle systemen onderling laten uitvechten als de upstream router uitstekend in staat is het de juiste verbinding uit te sturen.

De crux is dat voor veel ISP global prefixes deze onlosmakelijk met de verbinding verbonden zijn, en tenzij je echt de resources hebt je ook internet verbindingen met BGP kan krijgen.

Alle apparaten zelfstandig dit uit laten zoeken lijkt me beheers technisch een slecht idee. Outages komen voor, ook bij glas. Afgelopen week nog een half uur geen internet omdat een graaf machientje de straat verderop de stroom kabel van de PoP had geraakt.

Veel software en hardware is ook nog niet in staat met meerdere prefixes om te gaan, zeker simultaan. En wachten tot ze het wel kunnen is een beetje kip en ei.

Laten we voort maken. Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

[bdegroot]

databeestje schreef op zondag 27 maart 2011 @ 17:22:
[...]
Laten we voort maken. Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

Ik kan je helpen met Sixxs credits! Ik heb er genoeg.
Het zou heel mooi zijn als Sixxs ondersteuning in PfSense komt!

PM maar indien ik je kan helpen.

[Roetzen]

databeestje schreef op zondag 27 maart 2011 @ 17:22:
Het hele nat uitroeien lijkt op een religieuze oorlog.

Nah, geloof is iets als vaststaand feit ervaren zonder enig bewijs. Geloof is wat mij betreft niet aan de orde bij de wens van NAT af te komen. NAT is een kludge. Nodig bij IPv4 om het gebrek aan adressen te omzeilen. Het werkt, meestal, maar wel met veel kunst en vliegwerk. Voor IPv6 is het niet nodig omdat er geen gebrek aan adressen is. Je kunt weer terug naar volledige end to end connectivity zoals het internet oorspronkelijk bedoeld was en daarmee vermijd je een boel problemen. Bij IPv6 is NAT een onnodige complicatie. Als techneut en wetenschapper zie ik die liever verdwijnen.

soms moet je door hoepels springen, anders wordt er soms geen geld verdient.

Als je commercieel bezig bent, zou je juist de zaak simpel willen houden. Onnodige kludges leiden alleen maar tot meer problemen en problemen oplossen kost geld.

Outages komen voor, ook bij glas. Afgelopen week nog een half uur geen internet omdat een graaf machientje de straat verderop de stroom kabel van de PoP had geraakt.

Als je commercieel bezig bent wil je natuurlijk graag dat half uur overbruggen. Maar wat ik dan niet begrijp is...

Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

... waarom je dan met SIxXs in zee gaat. SixXs is draait opvrijwilligers. Ik ben blij met ze, maar ik ben met VUT en voor mij is het aleen nog maar hobby. Ik kan leven met vrijwilligers die geen 24/7 ondersteuning bieden. Ik raak geen klanten kwijt als de zaak een dag plat ligt. Als ik nog commercieel bezig was, dan zou ik het ook professioneel aanpakken en BGP regelen. Sja, dat kost dan iets meer, maar qualiteit kan niet gratis zijn.

Osiris schreef:
Je kunt geen SixXS-credits naar elkaar overschrijven naar mijn weten.

Inderdaad dat kan niet.

Dat puntensysteem heeft mij overigens ook wat afstand doen nemen van SixXs. Aan de ene kant kan ik het wel begrijpen dat ze ondoordachte acties wat willen afremmen, aan de ander kant snap ik niet waarom het 50 punten moet kosten om een subnet terug te geven wat ik bij nader inzien niet meer nodig heb. Sja, dus houd ik het maar...

[databeestje]

Roetzen schreef op maandag 28 maart 2011 @ 13:39:

... waarom je dan met SIxXs in zee gaat. SixXs is draait opvrijwilligers. Ik ben blij met ze, maar ik ben met VUT en voor mij is het aleen nog maar hobby. Ik kan leven met vrijwilligers die geen 24/7 ondersteuning bieden. Ik raak geen klanten kwijt als de zaak een dag plat ligt. Als ik nog commercieel bezig was, dan zou ik het ook professioneel aanpakken en BGP regelen. Sja, dat kost dan iets meer, maar qualiteit kan niet gratis zijn.

Sorry voor de verwarring, 2 losse onderwerpen. Op de zaak hebben we 1 native ipv6 verbinding vna Unet, dus dat valt wel mee. Unet is ook we bereid om BGP aan te gooien. Probleem is dat ik dan nog steeds met 2 kpn glas verbindingen zit waar het niet mee kan.

Die ondersteuning voor Sixxs heeft niets specifiek te maken met het NAT verhaal. Het is meer dat er een schare pfSense gebruikers is die het toch wil gebruiken. Het zal toch een keer gemaakt moeten worden.
Programmeren gebeurt meestal om persoonlijke behoeftes, dit is er niet een van.

Er zijn nu een aantal providers waarbij je als alternatief een tunnel broker van de provider krijgt voor het termineren van de IPv6. Dat is gelukkig een goede oplossing voor migratie tot alles in het pad het fatsoenlijk ondersteund.

Ik ben een enorme tijd kwijt geweest samen met Unet om IPv6 fatsoenlijk afgeleverd te krijgen op locatie. Het BBned netwerk hielp niet echt mee. Gelukkig is het dankzij de inzet van Unet toch gelukt. Hulde.

[Roetzen]

databeestje schreef op maandag 28 maart 2011 @ 14:16:
Sorry voor de verwarring, 2 losse onderwerpen.

Sorry voor het verkeerd begrijpen.

Op de zaak hebben we 1 native ipv6 verbinding vna Unet, dus dat valt wel mee. Unet is ook we bereid om BGP aan te gooien.

Nou, dan heb je het al voor 33% voor elkaar..

Probleem is dat ik dan nog steeds met 2 kpn glas verbindingen zit waar het niet mee kan.

Je loopt in elk geval lekker voorop. Er zijn zat bedrijven die nog helemaal niet met IPv6 bezig zijn. Jij bent al met multi homing bezig...

Die ondersteuning voor Sixxs heeft niets specifiek te maken met het NAT verhaal. Het is meer dat er een schare pfSense gebruikers is die het toch wil gebruiken. Het zal toch een keer gemaakt moeten worden.
Programmeren gebeurt meestal om persoonlijke behoeftes, dit is er niet een van.

Ah, je bent voor de goede zaak bezig.

Er zijn nu een aantal providers waarbij je als alternatief een tunnel broker van de provider krijgt voor het termineren van de IPv6. Dat is gelukkig een goede oplossing voor migratie tot alles in het pad het fatsoenlijk ondersteund.

Dat een aantal providers zelf tunnels gaat aanbieden is natuurlijk mooi, maar er zijn er nog te veel die achter blijven en over het geheel gaat de introductie van IPv6 veel te traag naar mijn smaak. De goeden niet te na gesproken natuurlijk..

Ik ben een enorme tijd kwijt geweest samen met Unet om IPv6 fatsoenlijk afgeleverd te krijgen op locatie. Het BBned netwerk hielp niet echt mee. Gelukkig is het dankzij de inzet van Unet toch gelukt. Hulde.

Waarvan akte!

[databeestje]

AmonTobin schreef op vrijdag 08 april 2011 @ 23:16:

Edit: Hmmn, volgens mij zit ik wat zaken door elkaar te halen. 6to4 is schijnbaar wat anders dan wat zo'n ipv6 tunnel broker als Hurricane Electrics aanbiedt. Ik ga even verder zoeken.

Wat hurricane electric en Sixxs onder andere doen is 6in4. Dat is dus een Tunnel over IPv4 waar je het v6 verkeer in vervoert. Dit gebeurt eigenlijk altijd met een "tunnelbroker" waarschijnlijk een mooie router met een gigabit poortje. Geen encryptie oid dus redelijk snel allemaal.

Ik geloof dat 6to4 iets anders is.... snor snor ... aha, het is echt iets anders, het gebruikt anycasting waardoor je op de eerste de beste 6to4 relay het ipv6 internet op gaat. Je lokale PC heeft dan al IPv6 aanstaan, de meeste routers adverteren dit overigens niet. Het zou wel kunnen.

Ik zal eens zien of dat in pfSense kan. Op die manier kan je zonder tunnel broker ook op het ipv6 internet komen.

Betrouwbaarheid van het geheel is overigens wel sterk afhankelijk van de Publieke 6to4 relays. Gelukkig hebben we in Nederland een Surfnet relay dichtbij.

[databeestje]

Osiris schreef op zondag 17 april 2011 @ 00:11:
Sorry, VPN + IPv6 heb ik zelf ook nog geen ervaring mee verder.

in de huidige pfSense 2.0 IPv6 code heb ik al wel support gemaakt voor IPv6 in combinatie met IPsec. Dus een v6 tunnel via v4 eindpunten, of een v4 tunnel over v6 eindpunten. Het is kennelijk de enige VPN oplossing die wel een beetje op de toekomst was voorbereid. (ipsec-tools uit het BSD kamp).

OpenVPN heb ik naar gekeken maar daar moet ik een compleet gepatchte Openvpn install van maken. Deze ondersteunt wel IPv6 voor het transport maar niet door de eigenlijke VPN verbinding zelf. Heeft in ieder geval veel meer voeten in de aarde dan de IPsec tools.

Ik durf dan ook niet te zeggen of het ombouwen van de server component genoeg is om de clients een IPv6 adres toe te wijzen.

PPtP raak ik niet aan. Niet mijn ding.

[databeestje]

De situatie met de peering is een beetje naar. Cogent en HE willen bijvoorbeeld ook niet peeren. De reden die Cogent (ook Level3?) aandraagt is dat het een kleine (IPv4) speler is en dus moet betalen.

De situatie met IPv6 is daarentegen weer andersom, daar is HE een van de grootsten met het aantal IPv6 prefixes.

Hurricane Electric heeft al eens een heuze taart opgestuurd naar Cogent, hij zal vast wel opgegeten zijn, maar aan de peering veranderde niets.

Afgelopen weekeinde heb ik de OpenVPN met IPv6 payload patches ook in pfSense geimporteerd. Config maken lukt ook al maar ik krijg er nog geen verkeer overheen. Ik zal nog wel wat rules in de achtergrond moeten maken denk ik.

Traceroute is wild. Helemaal de Oceaan over en weer terug. Top!

code:

$ traceroute 2001:4c08:2001:10::2
traceroute to 2001:4c08:2001:10::2 (2001:4c08:2001:10::2), 30 hops max, 80 byte packets
 1  fde9:556:866f:1::1 (fde9:556:866f:1::1)  0.225 ms  0.216 ms  0.211 ms
 2  fde9:556:866f:9800::241 (fde9:556:866f:9800::241)  0.483 ms  0.481 ms  0.583 ms
 3  2a02:120:200:1cc::1 (2a02:120:200:1cc::1)  3.298 ms  3.386 ms  3.385 ms
 4  2a02:120:200:1::1 (2a02:120:200:1::1)  8.272 ms  8.271 ms  8.477 ms
 5  ams-unet-tc1-dx01-vl160.network.unet.nl (2a02:120:0:200::1:39)  9.240 ms  9.450 ms  9.690 ms
 6  ams-unet-nik-cx02-vl485.network.unet.nl (2a02:120:0:200::1:35)  9.837 ms  9.675 ms  9.907 ms
 7  ams-unet-nik-br01-gi3-1.network.unet.nl (2a02:120:0:200::1:15)  9.905 ms  9.126 ms  9.597 ms
 8  ams-unet-sar-br01-gi3-13.network.unet.nl (2a02:120:0:200::1:5)  8.840 ms  8.682 ms  8.908 ms
 9  2001:450:2002:1b6::1 (2001:450:2002:1b6::1)  8.505 ms  7.964 ms  8.208 ms
10  xe-8-0-0.edge1.SanJose3.Level3.net (2001:1900:4:3::129)  101.918 ms  101.002 ms  101.044 ms
11  vl-52.car1.Chicago1.Level3.net (2001:1900:10:2::3)  102.642 ms vl-51.car1.Chicago1.Level3.net (2001:1900:10:1::3)  102.148 ms  101.411 ms
12  vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22)  103.521 ms  103.502 ms  104.082 ms
13  vl-4081.car1.NewYork2.Level3.net (2001:1900:4:1::f5)  104.318 ms  103.858 ms  103.450 ms
14  vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101)  274.481 ms  273.924 ms  270.443 ms
15  vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11)  103.023 ms  104.181 ms  104.049 ms
16  vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106)  104.294 ms vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102)  106.441 ms vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106)  103.806 ms
17  vl-4060.edge4.Amsterdam1.Level3.net (2001:1900:5:1::206)  112.147 ms  111.584 ms  173.366 ms
18  vl-4080.edge4.Amsterdam1.Level3.net (2001:1900:5:1::10d)  111.909 ms  112.193 ms vl-4080.edge3.Amsterdam1.Level3.net (2001:1900:5:1::109)  111.456 ms
19  router-l3-1.thepeoplesvalley.net (2001:1900:5:2:2::d2)  111.944 ms  113.079 ms  132.739 ms
20  2001:4c08:2001::1 (2001:4c08:2001::1)  133.008 ms  132.949 ms  131.757 ms
21  2001:4c08:2001:10::2 (2001:4c08:2001:10::2)  128.748 ms  122.752 ms  121.988 ms

[ Voor 62% gewijzigd door databeestje op 27-04-2011 13:22 ]

[Raven]

Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

[CyBeR]

Raven schreef op vrijdag 20 mei 2011 @ 16:25:
Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

Nee, een dergelijke tunnel wordt door de software gezien als gelijk aan native. Het is alleen 6to4 en teredo (waarbij je een adres in eerder genoemde ranges hebt) wat, normaal gesproken, geen voorrang krijgt.

[zzattack]

Raven schreef op vrijdag 20 mei 2011 @ 16:25:
Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

Al lang? Build van Seth gebruikt of gitsync? Ik krijg geen enkele ipv6 build stabiel
De webui wordt na een aantal dagen unreachable maar routen blijft goed gaan. WebUI restarten helpt niet. SSH werkt soms iets langer, maar wat later kunnen shared libraries niet meer geladen worden en kan ik zelfs niet meer in pfSense sshen. Ik wacht wel op 2.1 voorlopig.

[ Voor 25% gewijzigd door zzattack op 20-05-2011 16:44 ]

[Raven]

Deze gebruik ik: http://www.xaero.org/inde...-on-the-pfsense-firewall/ icm pfSense 1.2.3.
Moet alleen nog even paar commands (/etc/rc.conf_mount_rw en /etc/rc.conf_mount_ro) aan de scriptjes toevoegen omdat het FS als RW gemount moet zijn tijdens het uitvoeren van de scripts. Daar ik de embedded versie van pfSense draai is het FS als RO gemount...

Ehm, gebruik die al een tijdje, maar zo vaak bezoek ik geen IPv6 sites. Was alleen om te kijken of ik mijn LAN alvast klaar kon maken voor IPv6. Sindsdien nog niet echt veel mee gedaan

edit: wtf, die scriptjes zijn niet meer aanwezig. Dan maar opnieuw maken.

Jaap-Jan schreef op vrijdag 20 mei 2011 @ 16:31:
Een 6in4- tunnel is bijna net zo goed als native, dus krijgt voorrang. Het gaat om de technieken 6to4 en Teredo, of in het algemeen: protocollen die IPv6- connectiviteit bieden zonder expliciet tunnels te hoeven configureren.

CyBeR schreef op vrijdag 20 mei 2011 @ 16:33:
[...]


Nee, een dergelijke tunnel wordt door de software gezien als gelijk aan native. Het is alleen 6to4 en teredo (waarbij je een adres in eerder genoemde ranges hebt) wat, normaal gesproken, geen voorrang krijgt.

Okido

edit: scriptjes weer aangemaakt, dit keer zonder die veelgemaakte fout
Router kan pingen naar ipv6.google.com, pc's krijgen IPv6 adres toegewezen maar kunnen niet van de tunnel gebruik maken. Pingen geeft timeouts of doelhost niet bereikbaar, maar IPv6 adres van de te pingen site is blijkbaar wel opvraagbaar. Pfffff....

edit2: Onder 7 werkt het , is dus iets met XP, maar wat. Vorige keer hoefde ik daar niks in te stellen
edit3: En nu werkt het ineens niet meer onder 7, wtf is dit nu weer....
edit4: dan werkt het ineens weer wel, dan niet, wel, niet, maar router heeft continu connectie
edit5:

Hele diepe zucht

Had de commando's om het FS als RW en RO te mounten aan de scripts toegevoegd, dat was blijkbaar geen goed idee. Dat zorgde ervoor dat het niet werkte. Maar nu moet ik dus na elke reboot van de router (gebeurt gelukkig niet zo vaak) met de hand het FS als RW mounten, beide scripts runnen, FS weer als RO mounten, niet echt handig

[ Voor 54% gewijzigd door Raven op 20-05-2011 22:46 ]

[databeestje]

Ik kan geen support geven op 1.2.3 met wat zelfbouw scripts. Ik weet dat het in de 2.0 ipv6 code wel een stuk beter gaat. Daarvoor kan je gewoon in het pfSense forum terecht in het IPv6 board.

In ander nieuws, DHCP-PD wordt ondersteunt op de WAN interface met mijn image. Ik ben inmiddels ook zo ver dat je op de LAN dhcp 6 server ook prefix delegatie kan doen.

1 openstaand issue is dat met de HE of Sixxs tunnel de default gateway soms kan wegvallen. Deze open issue zal binnenkort worden opgepikt.

Ik ben nog opzoek naar een vrijwilliger die native ipv6 krijgt op een ADSL in combinatie met PPPoE of een dergelijke verbinding van Xs4all, BusinessConnect, Unet of Signet. Dit om de DHCP-PD support af te kunnen maken en veldtesten.

[Raven]

Hmm, okee. Mocht ik ooit overstappen op 2.* dan zal ik daar eens naar kijken.
Maar (nu ietwat offtopic) zit er aan te denken pfSense aan de kant te gooien en over te stappen op Zentyal, dit vanwege de gebrekkige wifi support in FreeBSD. Voor zover ik kan terugvinden moet ik daar ook een zelfbouw script gebruiken om IPv6 werkend te krijgen. Daar kijk ik later wel naar.

[zenith]

wanneer komt pfsense met ipv6 support? (in de GUI enzo)

[ Voor 18% gewijzigd door zenith op 22-05-2011 20:48 ]

[zenith]

databeestje schreef op zaterdag 21 mei 2011 @ 21:55:
Ik kan geen support geven op 1.2.3 met wat zelfbouw scripts. Ik weet dat het in de 2.0 ipv6 code wel een stuk beter gaat. Daarvoor kan je gewoon in het pfSense forum terecht in het IPv6 board.

In ander nieuws, DHCP-PD wordt ondersteunt op de WAN interface met mijn image. Ik ben inmiddels ook zo ver dat je op de LAN dhcp 6 server ook prefix delegatie kan doen.

1 openstaand issue is dat met de HE of Sixxs tunnel de default gateway soms kan wegvallen. Deze open issue zal binnenkort worden opgepikt.

Ik ben nog opzoek naar een vrijwilliger die native ipv6 krijgt op een ADSL in combinatie met PPPoE of een dergelijke verbinding van Xs4all, BusinessConnect, Unet of Signet. Dit om de DHCP-PD support af te kunnen maken en veldtesten.

als je wilt kun je een dsl lijn afnemen bij businessconnect en werken we samen om je ipv6 aan de praat te krijgen. (legt wel een beetje aan je CE)

[Raven]

zenith schreef op zondag 22 mei 2011 @ 20:44:
wanneer komt pfsense met ipv6 support? (in de GUI enzo)

2.1, maar dat duurt nog even, eerst nog genoeg bugjes voor 2.0 te fixen: http://redmine.pfsense.org/projects/pfsense/roadmap (Er staan er bijna 2* zo veel open als maand of wat terug )

[ Voor 61% gewijzigd door Raven op 22-05-2011 20:54 ]

[zenith]

Raven schreef op zondag 22 mei 2011 @ 20:51:
[...]

2.1, maar dat duurt nog even, eerst nog genoeg bugjes voor 2.0 te fixen: http://redmine.pfsense.org/projects/pfsense/roadmap (Er staan er bijna 2* zo veel open als maand of wat terug )

gaat lekker inderdaad! tnx!

[databeestje]

zenith schreef op zondag 22 mei 2011 @ 20:47:
[...]


als je wilt kun je een dsl lijn afnemen bij businessconnect en werken we samen om je ipv6 aan de praat te krijgen. (legt wel een beetje aan je CE)

Ik kan natuurlijk wel een lijn afnemen, maar dan zit ik weer vast aan 30 per maand extra. Dat is me net iets te gortig. Ik verdien verder niet aan het pfSense verhaal.

We zijn tegenwoordig naar github verhuist. http://github.com/smos/pfsense-ipv6 daar kan je de repo terugvinden. Ik merge regelmatig de master branch in waardoor de IPv4 bits in ieder geval ook uptodate blijven. Inmiddels helpen een paar van de andere developers her en der mee. Op mijn eigen website kan je ook kant en klare images met support vinden. http://iserv.nl/files/pfsense/ipv6/rc1/

Ik wacht wel even totdat ik een pfSense gebruiker opduik die toegang geeft tot zijn install voor een gratis "databeestje special" zoals we dat in het dev@ kanaal noemen.

[Raven]

Heb net even alle sites die volgens http://ipv6eyechart.ripe.net/ meedoen aan IPv6 day even bekeken mbv Firefox 4 en deze addon: https://addons.mozilla.org/en-us/firefox/addon/showip/

Google -> IPv6
Yahoo -> IPv6
Facebook -> IPv6
YouTube -> IPv6
MS Bing -> IPv6
MS Xbox -> IPv6
AOL -> IPv6
Mapquest -> IPv6
T-Online -> IPv6
Cisco -> IPv6
Juniper -> IPv6
Huawei -> IPv6
US Dep Commerce -> IPv6


Van de sites die boven bovenstaande lijst staan, zijn er 2 die het moeilijk hebben: IPv6 Matrix en CNR-IMAA. Zijn niet voorruit te branden en geven meestal fout aan op http://ipv6eyechart.ripe.net/, rest all in the green

Dit viel me trouwens nog op:

http://test-ipv6.com/

Uw score
10/10	voor je IPv4 stabiliteit en gereedheid als websites op zowel IPv4 als IPv6 bereikbaar zijn.
9/10	voor je IPv6 stabiliteit en gereedheid als websites enkel op IPv6 bereikbaar zijn.

Test met een IPv4 DNS record 	  		[green]goed[/] (0.397s) gebruik makend van ipv4
Test met een IPv6 DNS record 	  		[green]goed[/] (0.336s) gebruik makend van ipv6
Test met een Dual Stack DNS record 		[green]goed[/] (0.362s) gebruik makend van ipv6
Test met een Dual Stack DNS en grote packets 	[green]goed[/] (0.193s) gebruik makend van ipv6
Test IPv4 zonder DNS 	  			[green]goed[/] (0.341s) gebruik makend van ipv4
Test IPv6 zonder DNS 	  			[green]goed[/] (0.334s) gebruik makend van ipv6
Test IPv6 met grote packets 	  		[green]goed[/] (0.167s) gebruik makend van ipv6
Test of uw ISP's DNS server IPv6 gebruikt 	[red]bad[/] (0.006s)

Op mijn computers heb ik als DNS de pfSense router ingesteld, de pfSense router maakt gebruik van 208.67.222.222 en 208.67.220.220, a.k.a. OpenDNS.
Als ze naar de DNS van Ziggo kijken.... die doet nog niet aan IPv6 volgensmij, of wel ondertussen?

[Raven]

Zsub schreef op dinsdag 19 juli 2011 @ 14:06:
[...]


Loadbalancing over die drie tunnels? Serieus, trouwens, met alle mensen die hier posten dat hun tunnel niet hun volledige internetsnelheid aankan, ik zie wel hoe dat zou kunnen werken

Ah okay. Geen idee of pfSense (gebruik ik icm HE) dat kan....
Maar ben op zoek naar een ander OS daar pfSense/FreeBSD geen ondersteuning bied voor "N".

[databeestje]

In pfSense IPv6 code boom zit NPT ondersteuning. Dit is IPv6 NAT waarmee je 1:1 netblokken "vertaald".

Op deze manier kan je dus meerder IPv6 tunnels of native tegelijk gebruiken. Op het werk heb ik dit ook getest met 3 verschillende IPv6 prefixes. Dit is vergelijkbaar met de multi wan zoals we dat kennen in IPv4 land met als groot verschil dat de IPv6 machine die erachter zit op alle 3 de netwerken ook daadwerkelijk bereikbaar is.

Inmiddels is mijn IPv6 code boom in de pfSense master boom teruggevouwen waardoor dit automatisch onderdeel wordt van versie 2.1.

[databeestje]

In pfSense 2.1-DEVELOPMENT heb ik DHCP-PD support toegevoegd. Mensen die een aansluiting hebben van een provider die native ipv6 aanbiedt via ethernet of met PPPoE (DSL).

Ik zoek nog mensen voor terugkoppeling om te verifieren of het in de echte wereld ook werkt. Op mijn Cisco 1811 in de lab setup werkt DHCP6 in ieder geval wat me goede hoop geeft.

op http://files.pfsense.org/jimp/ipv6/

[Raven]

Vandaag iets vaags gehad. Op een pc ESET Smart Security zo ingesteld* dat ie ook uitgaande verbindingen blocked maar wel vraagt of een app wel verbinding mag maken met de buitenwereld. Dat ging goed.
(*De interactieve modus dus ipv automatische.)

Maar de IPv6 tunnel kon ineens niet meer gebruikt worden Dacht eerst dat het aan ESET lag, omdat het precies na het veranderen van het gedrag van de firewall optrad, bleek dat niet het geval. Andere pc had het ook. Gekke was, router kon gewoon van de tunnel gebruik maken (pingen naar buiten lukte) en de pc's kregen een IPv6 toegewezen. Verder niks raars gezien.

Toen de 2 scripts die ik gebruik om pfSense van de HE-tunnel te voorzien weer uitgevoerd en nu werkt het weer. Vaag

[ Voor 3% gewijzigd door Raven op 02-09-2011 21:57 ]

[Raven]

Hier vandaag iets vaags tegengekomen.

Als ik met IPv6 enabled (onder XP) met Outlook probeer te werken kan deze wél testmails versturen maar e-mails ophalen kan niet vanaf de emailserver van eigen domeinnaam, de 0x800ccc0f fout.

Bij taak 'servernaam - Verzenden en ontvangen' is een fout opgetreden (0x800ccc0f): 'De verbinding met de server is onderbroken. Als het probleem blijft bestaan, neemt u contact op met de serverbeheerder of internetprovider (ISP).'

Telnet naar de emailserver via cmd werkt ook niet (knipperende underscore), maar vanaf mijn pfSense router wél Host ziet mijn ip niet in de logboeken voorbij komen, dus het gaat aan deze kant mis lijkt het.
IPv6 uninstall en Outlook werkt meteen normaal.

edit: Telnet onder 7, met de firewall in interactieve modus, laat zien dat telnet eerst via IPv6 probeert verbinding te maken en een paar sec later met IPv4 dat wél lukt.
Waarom kapt XP ermee als er geen antwoord is via IPv6?

edit2: Host heeft teruggemailt, bleek dat de SMTP server wél luisterde naar IPv6 maar de POP3/IMAP server niet, dat is nu gefixed .

Blijft de vraag waarom XP niet IPv4 probeerde nadat het via IPv6 niet lukte.

[ Voor 36% gewijzigd door Raven op 08-09-2011 11:00 ]

[Raven]

Ik zit nu zonder IPv6-tunnel helaas daar ik voor het huidige OS van mijn mITX router nog geen howto heb kunnen vinden. pfSense zorgde er met 10k DHCP requests in 30min voor dat mijn ISP de verbinding dichtgooide, hier kon ik geen oorzaak van vinden en een re-install hielp niet dus ik zit nu met IPFire te werken waar net als bij pfSense geen ondersteuning voor IPv6 aanwezig is.

Nou ja geen, bij pfSense bleek het onderliggende OS (FreeBSD) het wel te ondersteunen en daar had ik een mooie howto voor gevonden. Of iets vergelijkbaars voor IPFire beschikbaar is weet ik niet.

[WoC]

Raven schreef op donderdag 10 november 2011 @ 15:00:
...pfSense zorgde er met 10k DHCP requests in 30min voor dat mijn ISP de verbinding dichtgooide, hier kon ik geen oorzaak van vinden en een re-install hielp niet...

Hoe krijg je dat voor elkaar? pfSense draait standaard geen DHCP server op de WAN poort.

...Of iets vergelijkbaars voor IPFire beschikbaar is weet ik niet...

Das toch gewoon een Linux implementatie? Niet gelezen, maar via de wiki dit (Duitse) documentje gevonden. Succes!

[Raven]

Uhm, volgensmij snap je me niet goed . Er zit geen DHCP server op de WAN-poort, maar pfSense moet wel requests sturen omdat het IP van de ISP via DHCP wordt verkregen. Van wat ik heb begrepen reageerde pfSense niet (meer) op de response van de ISP's DHCP-server die na elke DHCP aanvraag werd verstuurd.
Zoiets gebeurde er dus:

pfSense: ik wil een IP-adres
ISP's DHCP-server: hier heb je een adres
pfSense: negeert antwoord en vraagt nog een keer een IP-adres

En dat telkens overnieuw.

Die howto heb ik gezien, maar daar moet je aan het (her)compileren als ik het goed begrijp, bij pfSense was het zo simpel als 2 scriptjes en 1 config file schrijven.

[ Voor 33% gewijzigd door Raven op 11-11-2011 10:00 ]

[WoC]

Raven schreef op vrijdag 11 november 2011 @ 09:56:
Uhm, volgensmij snap je me niet goed . Er zit geen DHCP server op de WAN-poort, maar pfSense moet wel requests sturen omdat het IP van de ISP via DHCP wordt verkregen. Van wat ik heb begrepen reageerde pfSense niet (meer) op de response van de ISP's DHCP-server die na elke DHCP aanvraag werd verstuurd.

Iets te snel gelezen... Maar ik begrijp wat je bedoelt. Toch vind ik het vreemd, pfSense kan prima als cliënt dienen. Je modem voor de pfSense bak al eens herstart? Maar goed, dit is verder off-topic hier.

Die howto heb ik gezien, maar daar moet je aan het (her)compileren als ik het goed begrijp, bij pfSense was het zo simpel als 2 scriptjes en 1 config file schrijven.

Hmm, ja, kan me voorstellen dat je daar niet aan wilt beginnen (vandaar wellicht je pfSense probleem verder troubleshooten, nieuwe image plaatsen, etc). Je zou ook kunnen kijken naar M0n0wall. pfSense is hier van afgeleid, maar m0n0wall heeft al standaard IPv6 ondersteuning aan boord. Wel wat beperkter qua features, maar als dit goed werkt, zou je daarna ook weer makkelijk terug moeten kunnen naar pfSense.

[Raven]

offtopic:
Ik heb de modem meermaals geherstart, pfSense bijgewerkt naar v2, dan nog een schone installatie gedaan, de NIC's in de config omgewisseld (probleem ging mee naar de andere NIC), andere kabel naar de modem geprobeerd, niks hielp. Pc met Windows rechtstreeks aan modem en het werkt gelijk, na install IPfire op router-pc werkte het ook meteen.
Ik ben trouwens niet van plan pfSense er weer op te doen, als dit probleem langer blijft doorgaan duurt de block van ISP ook langer....

m0n0wall is ook gebaseerd op FreeBSD, ik was nou juist al van plan om te overstappen op een op Linux gebaseerd OS....

[ Voor 12% gewijzigd door Raven op 12-11-2011 13:59 ]

[databeestje]

Sinds gisteren heeft Facebook voor de meeste dingen behalve chat IPv6 aangeschakeld in de weg naar 6 juni.

Ook de CDN van akamai ziet nu aanzienlijk meer hits door deze actie.
http://www.akamai.com/ipv6

pfSense 2.1 is ook met BETA0 getagged, we gaan alleen de release echt niet halen voor 6 juni. We zien op onze mirrors inmiddels dik 6% IPv6 traffic, maar dat is dan ook niet echt doorsnee publiek.

Presentatie van BSDCan is hier YouTube: pfSense 2.1: IPv6 and more

[databeestje]

in pfSense is NPt wel mogelijk, voor het vertalen van prefixen naar meerdere netwerken. Het is dan wel zo gemaakt dat het mogelijk is om een prefix te "vertalen" maar het expliciet niet mogelijk is om NAPT toe te passen. (Dwz prefix achter 1 adres).

En ja, ik kan bevestigen dat wederom Voip, FTP (die in a fire please) en een paar andere protcollen er problemen mee hebben. Echter, je bent wel zichtbaar op beide prefixes vanuit het internet, en dat, is anders dan de huidige situatie in IPv4 waar NAPT en niet 1:1 de norm is.

Ik zie thuisgebruikers en hele kleine toko's die nu een DualWan router hebben (kabel,adsl of 3G stick), zonder deze "functionaliteit" ontneem je ze min of meer een feature, dat gaat er altijd slecht in. Kom je in hele rare discussies terecht die je kunt winnen. Geen succes.

Ben je een groot bedrijf dan ben ik van mening dat men maar BGP moet nemen, als ze dat niet begrijpen zou ik aansturen op een nieuwe netwerkbeheerder.

[databeestje]

Let wel dat er inmiddels sprake is van het "Sunsetting" van Teredo door Microsoft zelf. Als je het een paar weken geleden geprobeerd had was er lang niet zoveel Teredo te zien, toen stonden de servers hiervoor "uit".

https://isc.sans.edu/diar...Server+%22Sunset%22/16153

Ik gebruik zelf OpenVPN in combinatie met pfSense, daar zit OpenVPN 2.3 in en kan dual-stack. Vondt ik zelf de makkelijkste methode, werkt zelfs dual stack met mijn Android 4.1 telefoon. Erg fijn. Ook Viscosity doet tegenwoordig probleemloos Dual Stack met Windows en op de Mac.

Ik gebruik thuis een HE.net tunnel, en verbind met OpenVPN daarheen. Een volledige /48 die ik op kan delen.

Nu maar hopen dat ISPs het begrijpen en een /56 uitdelen aan de gebruikers. Anders falen de providers gewoon opnieuw.

[Raven]

pfSense blokkeerde het toen ik het gebruikte. Máár er was in de betreffende versie (v1.2.3 van 2009) wél een vinkje te vinden om dat soort verkeer toe te staan.

Zojuist maar even mijn FEL-VM opgestart en geprobeerd de tunnel daar op te zetten...... Ik zie een bewegende schildpad op kame.net Wel Google voor moeten gebruiken, Fedora staat niet in het lijstje met besturingssystemen bij de configuratie-info op tunnelbroker.net
edit: Gelijk daar maar een verzoek ingediend info om Fedora erbij te vermelden.

[ Voor 25% gewijzigd door Raven op 19-09-2013 21:05 ]

[databeestje]

Snow_King schreef op dinsdag 31 december 2013 @ 13:16:
[...]
Ach, wij zette vorige week op een Extreme Networks 48 Poorts 10Gbit switch IPv6 aan, spontane reboot.

Die switch doet ook een klein stukje interne Layer 3 routering voor IPv4 en IPv6. Dat ging dus niet lekker, zodra de RA's aan ging nokte de switch er mee.

Soms vraag je jezelf wel eens af of iemand het wel getest heeft bij het bedrijf of dat ze alleen de checkbox matrix compleet aan het maken waren.

Note: www.cbs.nl gebruikt een Juniper die 46 NAT doet om deze website beschikbaar te maken over IPv6. Helaas zet de Juniper het "Frag" bitje voor alle pakketten inclusief de eerste "Ack" die we webserver terugstuurt. Er is nog veel apparatuur, firewalls en CPE bijvoorbeeld welke deze IPv6 fragmenten laten vallen en je feitelijk slecht op de CBS website komt.

Met sommige internet providers, zoals Lijbrandt, geeft dit dan ook problemen. Zo ook onze firewall (pfSense) voor ons kantoor. Niet iets wat je makkelijk kan oplossen.

Een echte load balancer staat wel in de planning voor het CBS, maar dat kan nog even duren.

Een goed voorbeeld van een slechte IPv6 implementatie, niet "gewoon" dual-stack maar een of andere vendor implementatie die je op de blauwe ogen moet vertrouwen. De implementatie is wel volgens "RFC" maar die kunnen overwegend op meerdere manieren uitgelegd worden. Niet voor productie gebruiken dus.

[databeestje]

Verwijderd schreef op woensdag 19 maart 2014 @ 14:11:
Gezocht en nog niet gevonden: Ik heb al een HE Tunnelbroker account jaren lang draaien (via Solcon ADSL plus een Netgear DG834 in DMZ mode + een eigen Linux router). Ik heb liever native IPv6 maar dat was niet mogelijk.

Ik denk nu aan een overstap naar UPC zakelijk Alles-in-Een want er is geen glasvezel in mijn straat (ook geen plannen voor) en geen sneller alternatief dan de huidige 8Mbps ADSL2+.

Vraagje: gaat "Protocol 41" door de DMZ mode in de UPC DPC3925 router in NAT / router mode?

Of is DMZ mode alleen UDP/TCP/NAT? En moet ik dus dan de extra 10 Euro per maand betalen voor 5 IPv4 adressen zodat de DPC3925 in bridge mode zit en ik mijn eigen 6to4 router kan gebruiken?

Bedankt!

Je kan het modem ook in bridge mode laten zetten, een collega van mij doet dat ook. Die gebruikt zijn eigen router (Draytek) in combinatie daarme (slecht wireless).

Daarvoor hoef je dus niet extra te betalen, het kost je wel een belletje naar de helpdesk. Het eerste mac adres dat actief is na een power cycle moet bij de helpdesk geactiveerd worden. Dit hebben we jarenlang op het werk gebruikt in combinatie met een 120/10 aansluiting en een pfSense router op een Cisco Docsis 3 modem.

pfSense ondersteunt zowel native als IPv6 tunnels.

[Verwijderd]

databeestje schreef op woensdag 19 maart 2014 @ 20:16:
[...]

Je kan het modem ook in bridge mode laten zetten, een collega van mij doet dat ook. Die gebruikt zijn eigen router (Draytek) in combinatie daarme (slecht wireless).

Daarvoor hoef je dus niet extra te betalen, het kost je wel een belletje naar de helpdesk. Het eerste mac adres dat actief is na een power cycle moet bij de helpdesk geactiveerd worden. Dit hebben we jarenlang op het werk gebruikt in combinatie met een 120/10 aansluiting en een pfSense router op een Cisco Docsis 3 modem.

pfSense ondersteunt zowel native als IPv6 tunnels.

Super. Bedankt voor de informatie. Op de volgende pagina http://www.callvoip.nl/cv...pc-cisco-modem-router.pdf zeggen zij dat UPC wilt dat je de 5 extra IPs koopt voor dat zij standaard je router in modem transparent mode wilt zetten, maar misschien probeer ik het gewoon met de helpdesk.

Kompaan schreef op woensdag 19 maart 2014 @ 20:17:
[...]

Geen idee,maaaaar....

nieuws: UPC en Ziggo stellen invoering ipv6 uit

Volgens dat artikel:

[...]


Dus misschien krijg je wel native IPv6 daar? Misschien even bij Ziggo zelf vragen?

Ik heb al aan UPC inderdaad gevraagd maar zij wisten van niks. Het komt misschien ooit. In ieder geval, zij hadden echt geen idee wat "protocol 41" was. Ik heb ooit gesolliciteerd bij UPC als project manager voor de IPv6 uitrol Dat was lang geleden. Tot native IPv6 komt kan ik zo wie zo goed via HE Tunnelbroker blijven draaien.

[moppentappers]

Ja, ik had eerst sixxs geprobeerd, alleen daar kreeg ik mijn tunnel niet mee werkend vanaf pfsense, vast iets heel doms over het hoofd gezien, maar met hurricane electric werkte het meteen.

[Raven]

moppentappers schreef op maandag 23 juni 2014 @ 00:53:
Ja, ik had eerst sixxs geprobeerd, alleen daar kreeg ik mijn tunnel niet mee werkend vanaf pfsense, vast iets heel doms over het hoofd gezien, maar met hurricane electric werkte het meteen.

Ondersteund pfSense ipv6 out of the box tegenwoordig? Toen ik het nog gebruikte (zo rond v1.2.3), moest je zelf een script aanmaken voor de tunnel. Overigens was dat makkelijker dan IPFire, daar hebben de devvers ipv6-features uit de kernel gesloopt, maar wel deels toegevoegd als losse geblokkeerde modules.

Heb het wel werkend gekregen, en een howto geschreven + radvd-addon gemaakt, maar wat een gedoe zeg Overigens ken ik alleen HE-tunnels, sixxs nooit geprobeerd dus geen idee of het wel/niet hoort te werken icm pfSense/IPFire. HE werkt iig prima bij beide.

[databeestje]

moppentappers schreef op maandag 23 juni 2014 @ 00:53:
Ja, ik had eerst sixxs geprobeerd, alleen daar kreeg ik mijn tunnel niet mee werkend vanaf pfsense, vast iets heel doms over het hoofd gezien, maar met hurricane electric werkte het meteen.

Als het een statische tunnel is zou het wel moeten werken, zo heb ik al een paar jaar een tunnel naar de Haarlem PoP.

Raven schreef op maandag 23 juni 2014 @ 10:55:
[...]

Ondersteund pfSense ipv6 out of the box tegenwoordig? Toen ik het nog gebruikte (zo rond v1.2.3), moest je zelf een script aanmaken voor de tunnel. Overigens was dat makkelijker dan IPFire, daar hebben de devvers ipv6-features uit de kernel gesloopt, maar wel deels toegevoegd als losse geblokkeerde modules.

Heb het wel werkend gekregen, en een howto geschreven + radvd-addon gemaakt, maar wat een gedoe zeg Overigens ken ik alleen HE-tunnels, sixxs nooit geprobeerd dus geen idee of het wel/niet hoort te werken icm pfSense/IPFire. HE werkt iig prima bij beide.

Vanaf versie 2.1, release datum 13 september 2013. https://blog.pfsense.org/?p=712

Inmiddels zitten we op 2.1.3

[ Voor 48% gewijzigd door databeestje op 23-06-2014 11:57 ]

[Raven]

databeestje schreef op maandag 23 juni 2014 @ 11:56:
[...]

Vanaf versie 2.1, release datum 13 september 2013. https://blog.pfsense.org/?p=712

Inmiddels zitten we op 2.1.3

Ah

offtopic:
Goed, maar nog geen reden om terug te gaan, als de *BSD Atheros drivers nog steeds zo bagger zijn en pfSense ineens weer spontaan besluit 10k dhcp-requests in 30 min naar mijn ISP te sturen

[databeestje]

Raven schreef op maandag 23 juni 2014 @ 13:32:
[...]

Ah

offtopic:
Goed, maar nog geen reden om terug te gaan, als de *BSD Atheros drivers nog steeds zo bagger zijn en pfSense ineens weer spontaan besluit 10k dhcp-requests in 30 min naar mijn ISP te sturen

2 verschillende dingen denk ik, de DHCP requests naar de ISP gaan toch niet via de wireless interface? Of gebruik je een WISP. Daarnaast gebruik ik thuis 2 Linksys routers als accesspoints, 1 in de huiskamer en 1 op zolder. Geen behoefte aan wireless in de meterkast

Wel afscheid van 1 van een ouder AP genomen, deze had wat moeite met multicast (== IPv6)

[Raven]

Jep, 2 verschillende dingen. Het eerste was dat de Atheros driver niet alleen zeer bagger was, maar ook nog eens geen 802.11n features had terwijl dat al wel een hele tijd in Linux was te vinden. Het andere was vermoedelijk een bug in pfSense, maar zelfs een schone install hielp niet. Dan maar naar een op Linux gebaseerd OS.

[ Voor 3% gewijzigd door Raven op 23-06-2014 13:56 ]

[LordMatanza]

Ik heb een vraagje, ik heb momenteel een XS4ALL VDSL verbinding op een Fritz!Box 7360.
Daarachter heb ik een pfSense router/firewall hangen met 4 VLAN's met ieder een eigen IPv4 subnet.
De pfSense router is via een "exposed host" configuratie beschikbaar voor verkeer vanaf het internet.
Nu krijg ik bij mijn VDSL verbinding ook een /48 IPv6 subnet .
Wanneer ik dit subnet wil gaan verdelen over de VLAN's achter mijn firewall, raak ik de weg een beetje kwijt.
De firewall krijgt enkel een /64 subnet aangereikt van de FritzBox, ik kan dus niet verder opsplitsen richting mijn VLAN's .

Hoe raden jullie mij aan om de VLAN's toch van IPv6 te voorzien?

[Snow_King]

Paul schreef op woensdag 29 oktober 2014 @ 07:39:
Werkt dat ook nog als je 3-in-1 (of zelfs maar 2-in-1, met telefonie erbij) hebt? Of moet je dan weer met allemaal kastjes in de weer om weer telefonie terug te krijgen?

Dat is wel lastig denk ik. Je kan in de Fritzbox geen (statistische) IPv6 routes maken denk ik?

Anders kon je een /56 richting de pfSense routeren vanaf de Fritzbox richting de pfSense en daarna weer ophakken in /64's.

[Verwijderd]

Snow_King schreef op woensdag 29 oktober 2014 @ 07:47:
[...]
Dat is wel lastig denk ik. Je kan in de Fritzbox geen (statistische) IPv6 routes maken denk ik?

Anders kon je een /56 richting de pfSense routeren vanaf de Fritzbox richting de pfSense en daarna weer ophakken in /64's.

Mag toch hopen van wel dat je statische routes kunt aanmaken gezien de tijd die ze al op de markt zijn en met Xs4all. Ik heb zelf geen fritzbox dus kan het niet bekijken.

Anders zou je verwachten dat de fritzbox router op zijn minst RA's aanneemt uit het lan en deze in zijn routing tabel opneemt.

/Edit
Volgens https://www.sixxs.net/wik...2._Add_static_IPv6_routes moet het iig via de cli kunnen.

En op http://en.avm.de/nc/servi...e-FRITZ-Box-home-network/

In the "Additional IPv6 Routers in the Home Network" section, enable the option "Allow IPv6 prefixes announced by other IPv6 routers in the home network".

[ Voor 25% gewijzigd door Verwijderd op 29-10-2014 11:19 ]

[databeestje]

Nou ja, mogelijk en actief is een verschil. Wat mij betreft mogen ze de bridge modems eerst activeren, daar zit waarschijnlijk een windows PC rechtstreeks aan die er prima mee overweg kan, of een klanten router die het volledig negeert

Toch even een dhcp6 client activeren om te zien of deze zich zelf kenbaar maakt. De dhcp6 client op mijn pfSense ziet nog steeds geen activiteit op de WAN met bridge mode modem.

Voorlopig nog even doorsukkelen met de HE.net tunnels, de snelheid voor Youtube is een beetje variabel geworden de laatste 2 weken.