OpenVPN met IPv6 clients

[UPPERKEES]

Ik wil OpenVPN adressen alloceren voor mijn clients, hiervoor wil ik mijn bestaande /64 IPv6 range van XS4ALL gebruiken. Ik heb op een aantal sites gelezen dat je het beste je bestaande range kan subnetten naar een /112 voor de clients. So far, not much progress... Mijn setup voor IPv4 werkt al erg mooi voor een jaar, maar nu wil ik ook IPv6 adressen gebruiken. Dit wil ik alloceren via de CCD manier.
...

Ik gebruik OpenVPN 2.4.0-6+deb9u2 op Raspbian 9 (Stretch), wat dan dus draait op een Raspberry Pi 3B+.
...

Ik draai zowel een tunnel via UDP als TCP. Ik gebruik mijn UDP tunnel voor het experimenteren met IPv6. Het volgende heb ik al geprobeerd.

Mijn oude config met alleen IPv4 (enige verschil is dat het TCP is, IPv6 config is IPv4 + IPv6) ziet er als volgt uit.

code:

local 10.1.0.1
port 1194
port-share 127.0.0.1 443
proto tcp
dev tun

ca server/example.com/pki/ca.crt
cert server/example.com/pki/issued/vpn.example.com.crt
key server/example.com/pki/private/vpn.example.com.key
dh server/example.com/dh.pem
tls-auth server/example.com/ta.key 0
crl-verify server/example.com/pki/crl.pem

server 10.1.1.0 255.255.255.0
push "route 10.1.0.0 255.255.255.0"

client-config-dir server/example.com/ccd
ccd-exclusive
topology subnet
learn-address /usr/local/sbin/learn-address.sh
script-security 2

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option DOMAIN home.lan"
push "dhcp-option DOMAIN home.vpn"
keepalive 10 30

remote-cert-tls client
auth SHA256
cipher AES-128-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-version-min 1.2 or-highest
comp-lzo no
push "comp-lzo no"

user openvpn
group nogroup

persist-key
persist-tun

status /var/log/openvpn-status.log
log-append  /var/log/openvpn.log
verb 3

sndbuf 0
rcvbuf 0
push "sndbuf 0"
push "rcvbuf 0"

Het volgende heb ik nu voor mijn UDP (IPv4 + IPv6) tunnel. De indented lines zijn de lines die toegevoegd zijn. Sommige lines zijn commented omdat ik ze (nog) niet nodig heb.

2001:aaaa:bbbb:1::/64 = Het subnet dat ik van XS4ALL heb gekregen.
2001:aaaa:bbbb:1:10:1:1::/112 = Het subnet dat ik voor mijn clients wil gebruiken (direct verbindbaar met 'de wereld').

code:

local 10.1.0.1
        #local 2001:aaaa:bbbb:1:10:1:0:1 # Is voor IPv6 socket (activeer ik later)
port 1194
proto udp
        #proto udp6 # Is voor IPv6 socket (activeer ik later)
dev tun

ca server/example.com/pki/ca.crt
cert server/example.com/pki/issued/vpn.example.com.crt
key server/example.com/pki/private/vpn.example.com.key
dh server/example.com/dh.pem
tls-auth server/example.com/ta.key 0
crl-verify server/example.com/pki/crl.pem

server 10.1.1.0 255.255.255.0
        server-ipv6 2001:aaaa:bbbb:1:10:1:1::/112 # Assign de tunnel een IPv6 IP
push "route 10.1.0.0 255.255.255.0"
        push "route-ipv6 2001:aaaa:bbbb:1::/64" # Push de XS4ALL range naar de clients
        push "route-ipv6 2000::/3" # Push een default route naar het internet

client-config-dir server/example.com/ccd
ccd-exclusive
topology subnet
learn-address /usr/local/sbin/learn-address.sh
script-security 2

push "redirect-gateway def1 bypass-dhcp"
        #push "redirect-gateway ipv6" # Is voor iOS, gebruik ik niet
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option DOMAIN home.lan"
push "dhcp-option DOMAIN home.vpn"
keepalive 10 30

remote-cert-tls client
auth SHA256
cipher AES-128-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-version-min 1.2 or-highest
comp-lzo no
push "comp-lzo no"

user openvpn
group nogroup

persist-key
persist-tun

status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 5

sndbuf 0
rcvbuf 0
push "sndbuf 0"
push "rcvbuf 0"

Mijn mobiel heeft al een IPv6 adres via de UDP tunnel, door deze CCD config.

code:

ifconfig-push 10.1.1.3 255.255.255.0
ifconfig-ipv6-push 2001:aaaa:bbbb:1:10:1:1:3/112 2001:aaaa:bbbb:1:10:1:1:1

eth0 is verbonden met het internet, die heb ik een vast IPv6 adres gegeven.

code:

source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.1.0.1
    netmask 255.255.255.0
    gateway 10.1.0.10
    dns-nameservers 10.1.0.1 10.1.0.10
    dns-search home.lan home.vpn

iface eth0 inet6 static
    address 2001:aaaa:bbbb:1:10:1:0:1
    netmask 64
    gateway gateway fe80::7eff:aaaa:bbbb:cccc
    accept_ra 1
    privext 2

Ik heb het volgende verder in sysctl.conf.

code:

#kernel.domainname = example.com
#kernel.printk = 3 4 1 3
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.ip_forward=1
#net.ipv6.conf.all.forwarding=1
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
#net.ipv4.conf.all.send_redirects = 0
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
#kernel.sysrq=1
#fs.protected_hardlinks=0
#fs.protected_symlinks=0
net.ipv4.tcp_rfc1337 = 1

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1

Mijn mobiel die verbonden is via de UDP (IPv4 + IPv6) tunnel heeft alleen internet via IPv4. Ik zie in iptables geen drops, ook geen accepts for that matter in de FORWARD chain. Client en server kunnen elkaar niet pingen, internet connectie via IPv6 is voor de client ook niet mogelijk.

Een paar configs/blogs die ik gecheckt heb.
https://community.openvpn.net/openvpn/wiki/IPv6
https://blog.apnic.net/2017/06/09/using-openvpn-ipv6/
https://cuzimageek.wordpr...6/09/21/openvpn-and-ipv6/
https://feeding.cloud.gee...v6-and-openvpn-on-linode/
https://techblog.synagila...-a-ipv6-tunnel-over-ipv4/
https://blog.kmp.or.at/ipv6-enabled-openvpn/
https://tomsalmon.eu/2013/04/openvpn-ipv6-with-tun-device/
https://blog.angenieux.in...n-ipv4-ipv6-nat-sans-ndp/
https://forums.openvpn.net/viewtopic.php?t=21051
https://www.bjoerns-techblog.de/2017/07/openvpn-und-ipv6/

Hoewel ze allemaal nuttig zijn en ik de benodigde config changes daar wel uit kan halen, werkt het alsnog niet. Mijn guess is dat het met routing te maken heeft, met name hoe de routes ingesteld staan in de server config.

Dit staat in de openvpn.log bijvoorbeeld.

code:

rWRwRwRwRwRSat Aug  4 13:48:51 2018 us=319238 intrepid.home.vpn/62.251.111.222:44356 MULTI: bad source address from client [10.1.0.13], packet dropped
RwRSat Aug  4 13:48:52 2018 us=640405 intrepid.home.vpn/62.251.111.222:44356 MULTI: bad source address from client [2001:aaa:bbbb:1:10:1:1:3], packet dropped

Iemand tips?
...

[UPPERKEES]

Nobody? Een voorbeeld van een working config zou ook al helpen denk ik.

Edit: Het werkt nu door deze regel toe te voegen aan de server config.

code:

push "route-ipv6 2001:aaaa:bbbb:1::/112"

Maar mijn public IPv6 IP is dynamisch... Niet de gene van mijn CCD file, terwijl de client wel aangeeft dat dat zijn IPv6 public IP is.

Dat was unrelated, ik kreeg dat adres via WiFi...

[ Voor 156% gewijzigd door UPPERKEES op 05-08-2018 10:48 ]

[donny007]

Gewoon een gokje: al een traceroute gedaan om te kijken of je routering ergens op slaat?

Nog andere vragen:
- Wat voor router gebruik je?
- Hoe worden je IPv6 adressen normaal uitgedeeld? KPN gebruikt standaard SLAAC, dat verwacht ik ook bij XS4ALL.
- Weet je zeker dat je van XS4ALL een /64 krijgt, en niet een /48 waar een /16 subnet ID aan vast wordt geplakt door de router?

Dat het IPv6 adres van een client wisselt kan kloppen. Met SLAAC en IPv6 privacy extensions ingeschakeld kiest de client één vast adres (op basis van het mac-adres van de netwerkinterface) en één tijdelijk random adres voor internettoegang.

[UPPERKEES]

Ik heb de vragen met betrekking tot XS4ALL doorgezet naar hun helpdesk, maar nog geen reactie gehad. Inmiddels heb ik IPv6 wel werkend (was routing). Maar wel een beetje met een dubbel gevoel. Eigenlijk wil ik alle clients direct op het internet aangesloten hebben met hun eigen IPv6 adres. Nu gebeurt dat via NAT.

Mijn huidige config.

code:

local 10.1.0.1
#local 2001:aaaa:bbbb:1:10:1:0:1
port 1194
proto udp
#proto udp6
dev tun

ca server/example.com/pki/ca.crt
cert server/example.com/pki/issued/vpn.example.com.crt
key server/example.com/pki/private/vpn.example.com.key
dh server/example.com/dh.pem
tls-auth server/example.com/ta.key 0
crl-verify server/example.com/pki/crl.pem

server 10.1.1.0 255.255.255.0
server-ipv6 2001:aaaa:bbbb:1:10:1:1::/112
push "route 10.1.0.0 255.255.255.0"
push "route-ipv6 2001:aaaa:bbbb:1::/64"
#push "route-ipv6 2001:aaaa:bbbb:1::/112"
push "route-ipv6 2000::/3 route-ipv6 2001:aaaa:bbbb:1::/64 1"
#push "route-ipv6 2000::/3"
#push "route-ipv6 ::/0"
# push "route-ipv6 2000::/3 </64 prefix>:ffff::1 1"
# push "route-ipv6 2000::/3 2001:aaaa:bbbb:1::/64"

client-config-dir server/example.com/ccd
ccd-exclusive
topology subnet
learn-address /usr/local/sbin/learn-address.sh
script-security 2

push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway ipv6"
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option DOMAIN home.lan"
push "dhcp-option DOMAIN home.vpn"
keepalive 10 30

remote-cert-tls client
auth SHA256
cipher AES-128-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-version-min 1.2 or-highest
comp-lzo no
push "comp-lzo no"

user openvpn
group nogroup

persist-key
persist-tun

status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 4

sndbuf 0
rcvbuf 0
push "sndbuf 0"
push "rcvbuf 0"

Daarna zag ik eindelijk drops en accepts in mijn forward chain. Toen eigenlijk maar de foutmeldingen gevolgd en dit gedaan.

code:

-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "Allow established/related sessions to be forwared" -j ACCEPT
-A FORWARD -s 2001:aaaa:bbbb:1::/64 -i tun+ -o eth0 -m conntrack --ctstate NEW -m comment --comment "Allow traffic initiated from vpn to access \\\'the world\\\'" -j ACCEPT
-A FORWARD ! -i lo -j LOG --log-prefix "IP6TABLES FORWARD " --log-tcp-options --log-ip-options
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited

:POSTROUTING ACCEPT [302:28613]
-A POSTROUTING -s 2001:aaaa:bbbb:1:10:1:1:0/112 -j SNAT --to-source 2001:aaaa:bbbb:1:10:1:0:1

Nu werkt het, alleen zoals te zien is krijgt elke client dus hetzelfde externe adres. Misschien dat hier geen weg omheen is, omdat ik mijn /64 subnet? Some comments about this would be helpful

EDIT
Nu net een reactie gehad van XS4ALL, ik denk dat ik dat guest netwerk maar eens ga problemen. Dan wijs ik gewoon die hele range voor VPN.

De range die wordt uitgedeeld is een /48 range. De PREFIX wordt door XS4ALL uitgedeeld. Voor Native IPV6 zal deze altijd zijn 2001:980:xxxx::/48.
De FRITZ!box kan van deze /48 maar slechts een /64 adresseren. De volgende /64 blokjes bestaan:
PREFIX::/64 voor de WAN kant (DSL)
PREFIX:1::/64 voor de LAN kant. Deze is adresseerbaar.
PREFIX:2::/64 voor guest netwerk (hier doen we niks mee!).

[ Voor 9% gewijzigd door UPPERKEES op 08-08-2018 16:19 ]

[Mijzelf]

Nu werkt het, alleen zoals te zien is krijgt elke client dus hetzelfde externe adres. Misschien dat hier geen weg omheen is, omdat ik mijn /64 subnet?

Het lijkt me dat je een routing probleem krijgt als er niet een NAT inzit. Hoe moeten de clients in hetzelfde netwerk als de RPi weten dat bepaalde adressen naar de RPi moeten?

Het kan overigens wel, denk ik. Als je de OpenVPN een tup device laat gebruiken ipv een tun device, kun je hem bridgen met eth0, en zit dus iedere OpenVPN client virtueel op de RPi ethernet poort, waar ze dus normaal kunnen reageren op ARP requests.

Die truuk heb ik ooit toegepast om OpenVPN op een NAS aan de gang te krijgen die geen iptables had, zodat NATten niet mogelijk was. Het werkte voor IPv4.

[Brahiewahiewa]

Mijzelf schreef op woensdag 8 augustus 2018 @ 15:05:
[...]

Het lijkt me dat je een routing probleem krijgt als er niet een NAT inzit...

Kwenie hoor, maar als je met ip6 nog nat wilt gebruiken, heb je ip6 niet begrepen. imho.
Ik bedoel: je krijgt een address space ter grootte van het huidige internet; ruim voldoende om elk van je clients een duizendtal ip-adressen te geven, en dan ga je toch nog doen alsof je te weinig ip-adressen hebt en nat toepassen. Klink als een artikel op thedailywtf.com

Uit de vraagstelling wordt ook niet duidelijk wat het doel is van deze excercitie. Dus mijn vraag aan @TS is: wat wil je nou eigenlijk bereiken?
Wil je een site-to-site vpn? Pak dan één machine in je network, maak een tunnel naar een machine in het andere network en laat RAD z''n werk doen.
Of heb je de illusie dat je anoniem 't internet op kunt met je clients? Dat kan met ip4 al niet (de vpn provider heeft altijd contactgegevens van je en staat die af bij een gerechtelijk bevel) en gaat met ip6 ook niet lukken
Of gaat het je erom deze twee vaguely connected technologieën te combineren om te kijken waar 't strandt?

[duronbug]

HIer de config met KPN. Is voor 99% gelijk aan XS4All. Als het goed is krijg je een /48 van de provider. Gebruik bij openvpn een subnet /64. De push-route route-ipv6 2001:aaaa:bbbb:1::/64 kan je weglaten.
Sowieso zou ik geen NAT gebruiken met IPV6, IPV6 is juist bedoeld om NAT op te kunnen heffen. Immers meer dan genoeg adressen!

code:

dev ovpns1
local 81.xxx.yyy.zzz
lport 1194
proto udp4
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
cipher none
auth SHA1
tls-server
server 10.0.8.0 255.255.255.0
server-ipv6 2a02:aaaa:bbbb:1::/64
push "route-ipv6 2000::/3"
client-config-dir /var/etc/openvpn-csc/server1
verify-client-cert none
username-as-common-name
push "dhcp-option DNS 10.0.8.1"
push "block-outside-dns"
push "register-dns"
push "redirect-gateway def1"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
ncp-disable
comp-lzo adaptive
topology subnet

[UPPERKEES]

Brahiewahiewa schreef op woensdag 8 augustus 2018 @ 18:28:
[...]

Kwenie hoor, maar als je met ip6 nog nat wilt gebruiken, heb je ip6 niet begrepen. imho.

Het doel is slechts een encrypted tunnel, voor privacy op mobiele of WiFi netwerken. Direct mijn IPv6 range gebruiken werkte in eerste instantie niet. OpenVPN raad daarom in dat geval aan om je /64 te subnetten (eerste link van mijn eerste post). Mijn doel is inderdaad publieke adressen gebruiken, ik check morgen even het voorbeeld dat hier gepost is. Misschien dat mijn eerste opzet daar meer succes mee heeft.

[UPPERKEES]

duronbug schreef op woensdag 8 augustus 2018 @ 22:14:
HIer de config met KPN. Is voor 99% gelijk aan XS4All. Als het goed is krijg je een /48 van de provider. Gebruik bij openvpn een subnet /64.

Ik probeer nu in plaats van mijn 2001:aaaa:bbbb:1::/64 te subnetten naar een /112, een nieuwe /64 range: "server-ipv6 2001:aaaa:bbbb:2::/64". In iptables zie ik packets over de interface heen gaan, maar ik heb geen IPv6 connectiviteit (test-ipv6.com). Volgens XS4ALL is de PREFIX:2::/64 een IPv6 guest range in de /48 range van de klant. Maar de router lijkt volgens mij niet mee te werken. Moet je zelf nog iets doen in je KPN router wanneer je een extra /64 subnet toevoegt? Zoals een route toevoegen op je router? Ik heb dat nu namelijk ook gedaan, een static route, maar dat maakt niks uit. Geen connectiviteit.

code:

 1843  311K ACCEPT     all      tun+   eth0    2001:aaaa:bbbb48:2::/64  ::/0                 ctstate NEW /* Allow traffic initiated from vpn to access \\'the world\\' */

[CAPSLOCK2000]

Die /64 van XS4All kun je niet gebruiken, die is al bezet. Die is nodig om met XS4all te praten. Het zou theoretisch wel kunnen werken maar je maakt het jezelf moeilijk.
Kies een andere /64 uit je /48.

NAT heb je niet nodig, dat gaat het alleen maar ingewikkeld maken. Dat heeft niks te maken met de discussie of NAT wenselijk is of niet, het is in deze situatie gewoon niet van toepassing. Wederom is het technisch best mogelijk, maar je maakt het moeilijker dan het is.

Ter motivatie, ik heb exact zo'n setup thuis staan (xs4all, ipv6, openvpn) en dat werkt prima.

[UPPERKEES]

CAPSLOCK2000 schreef op donderdag 9 augustus 2018 @ 17:55:
ik heb exact zo'n setup thuis staan (xs4all, ipv6, openvpn) en dat werkt prima.

Ik heb nu het onderstaande in mijn server config:

code:

server-ipv6 2001:aaaa:bbbb:2::/64
push "route-ipv6 2000::/3"

En dit in de CCD van een client waar ik de tunnel mee test.

code:

ifconfig-push 10.1.1.3 255.255.255.0
ifconfig-ipv6-push 2001:aaaa:bbbb:2::3/64 2001:aaaa:bbbb:2::1

Vervolgens kreeg ik drops in mijn FORWARD chain voor de PREFIX:2::/64 range, die doorgelaten met deze regel.

code:

-A FORWARD -s 2001:aaaa:bbbbb:2::/64 -i tun+ -o eth0 -m conntrack --ctstate NEW -m comment --comment "Allow traffic initiated from vpn to access \\\'the world\\\'" -j ACCEPT

Maar nog steeds geen joy. Ik mis duidelijk nog iets, een route of een iptable rule denk ik. Zie jij wat ik anders doe dan jou?

[duronbug]

Deze zijn niet nodig:

ifconfig-push 10.1.1.3 255.255.255.0
ifconfig-ipv6-push 2001:aaaa:bbbb:2::3/64 2001:aaaa:bbbb:2::1

Openvpn wijst zelf een client IP toe aan de hand van het opgegeven subnet.

Haal als test eens alles uit Iptables weg.

[UPPERKEES]

duronbug schreef op donderdag 9 augustus 2018 @ 21:10:
Deze zijn niet nodig:

ifconfig-push 10.1.1.3 255.255.255.0
ifconfig-ipv6-push 2001:aaaa:bbbb:2::3/64 2001:aaaa:bbbb:2::1

Openvpn wijst zelf een client IP toe aan de hand van het opgegeven subnet.

Haal als test eens alles uit Iptables weg.

Een random IP wordt dan inderdaad toegewezen, maar hetzelfde probleem blijft; geen IPv6 internet connectiviteit (test-ipv6.com). Hoewel CCD niet nodig is, is het voor mij wel een voorkeur. Maar het weglaten heeft geen zin.

[UPPERKEES]

CAPSLOCK2000 schreef op donderdag 9 augustus 2018 @ 17:55:
Ter motivatie, ik heb exact zo'n setup thuis staan (xs4all, ipv6, openvpn) en dat werkt prima.

Heb je toevallig in je Fritzbox een IPv6 static route aangemaakt zoals: PREFIX:2::/64 PREFIX:1::1 (OpenVPN /64 range naar de router)?

[UPPERKEES]

Dit fixed het ook, maar ja, dan heb je weer NAT. Volgens mij mis ik gewoon nog een route die ergens gezet moet worden om de PREFIX:2::/64 goed te laten werken. Pingen tussen de clients werkt wel gewoon.

code:

ip6tables -t nat -A POSTROUTING -s PREFIX:2::/64 -j SNAT --to PREFIX:1:10:1:0:1

[duronbug]

Heb je in de fritzbox wel alle subnetten die actief zijn op de Raspberry doorgezet? Weet de Fritzbox hoe hij de VPN clients kan bereiken?
Zo te zien komt het packet wel naar buiten toe, maar loopt de weg terug naar de Openvpn client dood.

[UPPERKEES]

duronbug schreef op vrijdag 10 augustus 2018 @ 21:00:
Heb je in de fritzbox wel alle subnetten die actief zijn op de Raspberry doorgezet? Weet de Fritzbox hoe hij de VPN clients kan bereiken?
Zo te zien komt het packet wel naar buiten toe, maar loopt de weg terug naar de Openvpn client dood.

Dit heb ik gisteren inderdaad geprobeerd, het subnet statically routed van PREFIX:2::/64 naar de link-local address van mijn router.

Maar geen verschil. Ik heb ook NDP proxy geprobeerd (NDP proxy staat aan in sysctl), maar helpt ook niet. Ik heb het ook geprobeerd met de tun1 interface (de IPv6 tunnel). Ik zag voorbeelden online die of de ethernet interface of de tunnel proxy toevoegde. Maar ook dat heeft geen effect.

code:

# ip neigh show proxy
2001:aaaa:bbbb:2::3 dev eth0  proxy

[ Voor 4% gewijzigd door UPPERKEES op 26-02-2020 09:54 ]

[Thralas]

AquaL1te schreef op zaterdag 11 augustus 2018 @ 10:07:
Maar geen verschil. Ik heb ook NDP proxy geprobeerd (NDP proxy staat aan in sysctl), maar helpt ook niet. Ik heb het ook geprobeerd met de tun1 interface (de IPv6 tunnel). Ik zag voorbeelden online die of de ethernet interface of de tunnel proxy toevoegde. Maar ook dat heeft geen effect.

code:

# ip neigh show proxy
2001:aaaa:bbbb:2::3 dev eth0  proxy

Begrijp dat het frustrerend is als zaken niet werken, maar het helpt als je beredeneert waarom je zaken probeert, anders verzand je in de 'pogingen' die bij voorbaat niet gaan slagen.

Je hebt in eerste instantie je (vermeende) /64 subnet verder opgedeeld in een /112 om die op de VPN interface te gebruiken. Dat kan prima, maar dan moet je NDP proxyen, want dat subnet is niet direct verbonden met je LAN. Proxyen doe je op je eth0, want daar hoort het subnet waar je voor proxiet thuis.

Inmiddels ben je een alternatieve weg ingeslagen (ander subnet uit de /48 van XS4ALL). Ook goed, maar dan heb je die NDP proxy niet nodig, want je routeert het hele subnet naar je VPN-bak.

Pick one. Ik zou voor het extra subnet gaan, die 'luxe' heb je immers.

Wat ik verder bij het debuggen mis is een duidelijk beeld waar het nu misgaat, anders dan 'het werkt niet'. Volg met tcpdump een v6 ping vanaf een VPN client naar het internet. Controleer de tun interface en je eth0, dan zie je zo op welk punt je pakketjes kwijtraakt (interface) en wanneer (inkomend, uitgaand). Helpt enorm om te bepalen waar je het probleem moet zoeken.

[UPPERKEES]

Thralas schreef op zaterdag 11 augustus 2018 @ 12:00:
[...]
Wat ik verder bij het debuggen mis is een duidelijk beeld waar het nu misgaat, anders dan 'het werkt niet'. Volg met tcpdump een v6 ping vanaf een VPN client naar het internet. Controleer de tun interface en je eth0, dan zie je zo op welk punt je pakketjes kwijtraakt (interface) en wanneer (inkomend, uitgaand). Helpt enorm om te bepalen waar je het probleem moet zoeken.

Ja je hebt gelijk, normaal laat ik wel een log zien van debugging. Maar ik had de aanname dat anderen hier zo bekend mee waren dat er gelijk wel wat nuttige tips uit kwamen. Inderdaad mag ik wel wat meer info delen. Het checken met tcpdump heb ik al gedaan en mijn conclusie is inderdaad dat routing het probleem is.

Client kan server pingen en server kan client pingen. Pingen naar het internet gaat alleen fout.

Op de client ping ik 3 keer google.com, wat faalt.

code:

$ ping6 -c 3 google.com
PING google.com(ams15s32-in-x0e.1e100.net (2a00:1450:400e:809::200e)) 56 data bytes

--- google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2067ms

Op de server volg ik dit met een tcpdump, met als source het IPv6 IP van de client die pingt. Daar wordt niks geregistreerd.

code:

# tcpdump -n -i tun1 not tcp port 4443 and dst 2001:aaaa:bbbb:2::2

Nu een tcpdump met als destination het IP van de client.

code:

# tcpdump -n -i tun1 not tcp port 4443 and src 2001:aaaa:bbbb:2::2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 262144 bytes

16:42:33.408952 IP6 2001:aaaa:bbbb:2::2 > 2a00:1450:400e:809::200e: ICMP6, echo request, seq 1, length 64
16:42:34.411796 IP6 2001:aaaa:bbbb:2::2 > 2a00:1450:400e:809::200e: ICMP6, echo request, seq 2, length 64
16:42:35.434482 IP6 2001:aaaa:bbbb:2::2 > 2a00:1450:400e:809::200e: ICMP6, echo request, seq 3, length 64

De echo reply komt dus nooit aan, er is dus geen route vanaf het internet terug naar de client. Ik heb daarom al dit toegevoegd in de router, in de hoop dat dat het probleem oplost. Maar geen verschil.

Mijn doel is dus dat elke client zijn eigen IPv6 address heeft in de PREFIX:2::/64 range en daarmee naar het internet kan communiceren (zonder NAT).

Over de PREFIX:1:10:1:0::/112 oplossing, ik heb daarmee ook met NDP proxy gespeeld. Met de tunnel interface. Maar dat werkte ook niet. Die oplossing laat ik nu inderdaad ter zijde omdat een /64 range voor OpenVPN zelf inderdaad een mooie luxe is.

Mijn vraag is dus, hoe zorg ik ervoor dat nu die clients met het internet kunnen praten. Wanneer ik met NAT POSTROUTING het source adres verander naar een PREFIX:1::/64 adres werkt het. Dus de PREFIX:2::/64 komt er gewoon niet lekker doorheen. Dit is zeer waarschijnlijk een routing probleem. Graag wat tips.

[Thralas]

AquaL1te schreef op zaterdag 11 augustus 2018 @ 16:59:
Op de server volg ik dit met een tcpdump, met als source het IPv6 IP van de client die pingt. Daar wordt niks geregistreerd.

Je wisselt source en destination om met wat je laat zien

De echo reply komt dus nooit aan, er is dus geen route vanaf het internet terug naar de client.
Ik heb daarom al dit toegevoegd in de router, in de hoop dat dat het probleem oplost. Maar geen verschil.

Je slaat een stap over - tcpdump ook eens eth0 om te controleren wat je VPN-machine daadwerkelijk verlaat en/of binnenkomt? Pas dan weet je of het aan die route ligt, of aan je VPN-machine.

Gewoon op 'icmp6' filteren is meestal nog wat makkelijker dan op src/dst/host filteren. Pak je ook meteen alle NDP-zaken mee - hier mogelijk ook wel van belang.

Mijn vraag is dus, hoe zorg ik ervoor dat nu die clients met het internet kunnen praten. Wanneer ik met NAT POSTROUTING het source adres verander naar een PREFIX:1::/64 adres werkt het. Dus de PREFIX:2::/64 komt er gewoon niet lekker doorheen. Dit is zeer waarschijnlijk een routing probleem. Graag wat tips.

Oké, dat is inderdaad een interessante observatie. Dan zou de NDP proxy-optie sowieso moeten werken en suggereert dat er iets verkeerd gaat met die route. Misschien is de tcmpdump van eth0 daarbij nuttig.

[UPPERKEES]

Thralas schreef op zaterdag 11 augustus 2018 @ 17:52:
Je slaat een stap over - tcpdump ook eens eth0 om te controleren wat je VPN-machine daadwerkelijk verlaat en/of binnenkomt? Pas dan weet je of het aan die route ligt, of aan je VPN-machine.

Gewoon op 'icmp6' filteren is meestal nog wat makkelijker dan op src/dst/host filteren. Pak je ook meteen alle NDP-zaken mee - hier mogelijk ook wel van belang.

Dan zie ik het volgende.

code:

11:57:33.869415 IP6 2001:aaaa:bbbb:2::3 > 2a00:1450:400e:80b::200e: ICMP6, echo request, seq 9, length 64

Een echo reply komt dus niet aan. Dus lijkt dan dat het bij de router al fout gaat? Aangezien het niet eens op de ethernet interface aankomt. Er zijn een aantal mensen hier die het al werkend hebben, maar niet echt hun oplossing delen behalve berichten dat het wel kan werken. Het zou erg behulpzaam zijn als die mensen hun routering config delen Ik zou ze dankbaar zijn.

[Thralas]

AquaL1te schreef op zondag 12 augustus 2018 @ 12:03:
Dus lijkt dan dat het bij de router al fout gaat? Aangezien het niet eens op de ethernet interface aankomt.

Correct.

Als je router diagnostische tools aan boord heeft dan zou ik vanaf daar checken of het gatewayadres te pingen is. Lijkt me dat die route wel behoort te werken mits je hem juist instelt..

[terror538]

Zoals ik het zie zijn er 3 opties:
-met tap en bridging instellen, dan deelt de fritzbox middels SLAAC een ipv6 uit, niet iedere client (oa android) ondersteund zondermeer tap
-en /64 alloceren uit de /48 die XS4ALL uitdeelt, en dan op je fritzbox een statische route instellen richting je VPN doos, geen idee of de fritzbox dit kan.
-de fritzbox de deur uit/in bridge mode en een router neerzetten die openvpn doet. Bv een openwrt doos of PF/Opnsense

Een /112 vanuit je /64 alloceren gaat alleen maar problemen geven, andere devices uit dat subnet weten dan niet dat ze via een gateway moeten, en kleiner dan /64 subnetten is in principe ook not-done in ipv6

[UPPERKEES]

terror538 schreef op zondag 12 augustus 2018 @ 14:28:
-en /64 alloceren uit de /48 die XS4ALL uitdeelt, en dan op je fritzbox een statische route instellen richting je VPN doos, geen idee of de fritzbox dit kan.
-de fritzbox de deur uit/in bridge mode en een router neerzetten die openvpn doet. Bv een openwrt doos of PF/Opnsense

Ik ben inmiddels beter bekend met de opties. De statische route is wat ik probeer, zie hier bijvoorbeeld. Die link-local address is van mijn router. Maar dit lijkt nog niet te werken. Diagnostische tools zoals ping of traceroute zijn niet aanwezig op mijn FRITZ!Box 5490. Dus ik zit nu even vast. Ik heb de vraag ook gesteld aan FRITZ!Box zelf; wat te doen in zo'n scenario als dit. Want de XS4ALL helpdesk is niet echt behulpzaam, ze wisten niet eens wat een subnet is en verwezen me daarom door naar de vendor van hun routers.

Kan iemand een working example geven zodat ik het kan vergelijken met mijn setup? De systemen (laptop in dit geval) hier in mijn netwerk hebben het volgende in hun routing table staan.

code:

# ip -6 r
2001:aaaa:bbbb:1::/64 via fe80::7eff:aaaa:bbbb:a1f3 dev enp59s0u1u4u3 proto ra metric 100 pref medium
2001:aaaa:bbbb:1::/64 dev wlp2s0 proto kernel metric 600 pref medium
2001:aaaa:bbbb:1::/64 via fe80::7eff:aaaa:bbbb:a1f3 dev wlp2s0 proto ra metric 600 pref medium
2001:aaaa:bbbb::/48 via fe80::7eff:aaaa:bbbb:a1f3 dev enp59s0u1u4u3 proto ra metric 100 pref medium
2001:aaaa:bbbb::/48 via fe80::7eff:aaaa:bbbb:a1f3 dev wlp2s0 proto ra metric 600 pref medium
fd00::/64 dev enp59s0u1u4u3 proto ra metric 100 pref medium
fd00::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev enp59s0u1u4u3 proto kernel metric 100 pref medium
fe80::/64 dev enp59s0u1u4u3 proto kernel metric 256 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 256 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 600 pref medium
default via fe80::7eff:aaaa:bbbb:a1f3 dev enp59s0u1u4u3 proto ra metric 100 pref medium
default via fe80::7eff:aaaa:bbbb:a1f3 dev wlp2s0 proto ra metric 600 pref medium

In principe heb ik dus de onderstaande regel als statische route ingesteld op de router, maar dan met het PREFIX:2::/64 adres.

code:

2001:aaaa:bbbb:1::/64 via fe80::7eff:aaaa:bbbb:a1f3 dev enp59s0u1u4u3 proto ra metric 100 pref medium

Dus dat komt neer op.

code:

2001:aaaa:bbbb:2::/64 via fe80::7eff:aaaa:bbbb:a1f3 dev intX

That's the way to go right? Als dat zo is, waarom zou dat dan niet werken?

[terror538]

Kan je fritzbox die linklocal ook pingen? Evt kan je ipv het link local adres ook het ipv6 adres wat aan de lan kant beschikbaar is als gw aangeven op de fritzbox

-edit- hier al gekeken? Volgens een post daar is subnet 2 ook biet bruikbaar, misschien is met 3 proberen?
https://xs4all.gebruikers...wthread.php?thread_id=455

[ Voor 35% gewijzigd door terror538 op 12-08-2018 16:30 ]

[UPPERKEES]

terror538 schreef op zondag 12 augustus 2018 @ 16:26:
Kan je fritzbox die linklocal ook pingen? Evt kan je ipv het link local adres ook het ipv6 adres wat aan de lan kant beschikbaar is als gw aangeven op de fritzbox

-edit- hier al gekeken? Volgens een post daar is subnet 2 ook biet bruikbaar, misschien is met 3 proberen?
https://xs4all.gebruikers...wthread.php?thread_id=455

Er zit geen ping tool in mijn router. Wanneer ik in het menu nog niks in het gateway veld heb ingevuld staat er fe80:, dus dat hint wel een beetje dat link-local gebruikelijk is. Ik heb ook het IP van de router geprobeerd; PREFIX::/64. No luck.

De helpdesk van XS4ALL hebben mij inderdaad ook verteld dat PREFIX:2::/64 een guest adres is, maar daarbij gaven ze als tip dat ik die moest gebruiken. Of ik ook :3 kon gebruiken konden ze niet echt een besluit over maken. Uiteindelijk was hun conclusie dat je alleen :1 en :2 kon gebruiken

Anyway, nu net ook PREFIX:3::/64 en PREFIX:ffff::/64 geprobeerd. Beide gaven geen verschil. Ik had ook de static route geupdate. Het begint een beetje een dood eind te worden. Best wel jammer dat de mensen die dit wel werkend hebben niks meer van hun laten horen

[terror538]

via link local routen is inderdaad gebruikelijk, niet verplicht.

Ik neem aan dat je minstens middels telnet of middels ssh moet kunnen werken op de fritzbox, vanaf daar ff proberen te pingen en te spelen met de static routes.

[Thralas]

AquaL1te schreef op zondag 12 augustus 2018 @ 14:50:

code:

# ip -6 r
default via fe80::7eff:aaaa:bbbb:a1f3 dev enp59s0u1u4u3 proto ra metric 100 pref medium
default via fe80::7eff:aaaa:bbbb:a1f3 dev wlp2s0 proto ra metric 600 pref medium

Dus dat komt neer op.

code:

2001:aaaa:bbbb:2::/64 via fe80::7eff:aaaa:bbbb:a1f3 dev intX

That's the way to go right? Als dat zo is, waarom zou dat dan niet werken?

Aap, mouw.

:a1f3 is het link local address van je router (want dat is je default route op je laptop)?

Datzelfde adres komt ook voor in het screenshot van je static route. Dat klopt niet.

Ik zou het link local address van je VPN-doos invullen in de router, dan werkt het vast een stuk beter.

[UPPERKEES]

Thralas schreef op zondag 12 augustus 2018 @ 17:57:
[...]


Aap, mouw.

:a1f3 is het link local address van je router (want dat is je default route op je laptop)?

Datzelfde adres komt ook voor in het screenshot van je static route. Dat klopt niet.

Ik zou het link local address van je VPN-doos invullen in de router, dan werkt het vast een stuk beter.

Thanks a million! De static route moest inderdaad van het link-local adres zijn van mijn eth0 op mijn Raspberry Pi Veel geleerd en ik ga hier veel plezier van hebben.

[Verwijderd]

Hallo allemaal,

Ik loop ook tegen vergelijkbare problemen aan. Ik heb een /64 naar de RPi geforward vanaf de Fritz!Box met een statische route. De route gaat van 2001:xxx:xxxx:xxxx:: naar het link-local adres van de RPi (ik heb het IPv6 adres dat begon met fe80 gebruikt).

Nu krijgt mijn MacBook op de VPN een IPv6 toegewezen uit die range, en ik kan de RPi vanaf de MacBook ping6'en. Ik kan ook de MacBook op dat adres ping6'en vanaf de RPi. Maar de laptop kan niet de router ping6'en en online tests geven aan dat IPv6 niet werkt. Iemand enig idee?

de client bestanden heb ik niet aangepast, maar ik heb in de server.conf wel alles gedaan wat hier te vinden is:
https://blog.apnic.net/2017/06/09/using-openvpn-ipv6/

Ik heb ook IPv6 forwarding aangezet in sysctl.conf.

Iemand enig idee waar het mis kan gaan?

[UPPERKEES]

Verwijderd schreef op dinsdag 11 september 2018 @ 11:49:
Ik loop ook tegen vergelijkbare problemen aan. Ik heb een /64 naar de RPi geforward vanaf de Fritz!Box met een statische route. De route gaat van 2001:xxx:xxxx:xxxx:: naar het link-local adres van de RPi (ik heb het IPv6 adres dat begon met fe80 gebruikt).

Kan je wat meer detail geven over deze routes en hoe je die statisch hebt ingesteld? Configs delen helpt ook.

[Verwijderd]

AquaL1te schreef op woensdag 12 september 2018 @ 13:25:
[...]


Kan je wat meer detail geven over deze routes en hoe je die statisch hebt ingesteld? Configs delen helpt ook.

Sorry voor de latere reactie van mijn kant. Ik was even niet bereikbaar.

Hier is mijn server.conf, ingesteld via PiVPN, maar daarna zelf aangepast:
dev tun
tun-ipv6
push tun-ipv6
proto tcp
port 443
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server_alI.crt
key /etc/openvpn/easy-rsa/pki/private/server_alI.key
dh none
ecdh-curve secp384r1
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 2001:xxx:xxxx:xxxx::/64
# Set your primary domain name server address for clients
push "route 192.168.178.0 255.255.255.0"
push "route-ipv6 2000::/3"
push "dhcp-option DNS 192.168.178.20"
ifconfig-ipv6 2001:xxx:xxxx:xxxx::1 2001:xxx:xxxx:xxxx::2
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
compress lz4
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io

Ik gebruik OpenVPN samen met Pi-hole, dus ik heb deze instructies gevolgd: https://docs.pi-hole.net/guides/vpn/dual-operation/
Voor IPv4 werkt dat prima. Maar met IPv6 weet ik niet precies hoe ik zo'n zelfde setup kan maken die thuis direct over m'n netwerk gaat en buitenshuis over de VPN, dus ik heb IPv6 maar ingesteld zoals hier: https://blog.apnic.net/2017/06/09/using-openvpn-ipv6/
In /etc/sysctl.conf heb ik de volgende twee lines toegevoegd:
net.ipv6.conf.eth0.forwarding=1
net.ipv6.conf.eth0.accept_ra=2
De firewall instellingen lijken geen verschil te maken, momenteel heb ik geen regels in iptables. De PiVPN install heeft zelf wel iptables persistent mee geïnstalleerd en die als volgt ingesteld:
# Generated by iptables-save v1.6.0 on Wed Aug 22 10:31:31 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:218]
:POSTROUTING ACCEPT [1:218]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Aug 22 10:31:31 2018
# Generated by iptables-save v1.6.0 on Wed Aug 22 10:31:31 2018
*filter
:INPUT ACCEPT [749:745386]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [855:85124]
COMMIT

De ip6tables zijn nog leeg:
# Generated by ip6tables-save v1.6.0 on Wed Aug 22 10:31:31 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT


Het statische forwarden heb ik als volgt gedaan: https://imgur.com/HFDGxlA


De client.conf heb ik niet aangepast.

[Verwijderd]

Iemand enig idee? Ik wil het heel erg graag werkend krijgen maar loop compleet vast.

[ Voor 70% gewijzigd door Verwijderd op 09-10-2018 16:55 ]

[UPPERKEES]

Aantal dingen die eigenlijk nog ontbreken om je echt te helpen.

* Wat staat er bijvoorbeeld in je OpenVPN log van je server?
* Wat staat er in de OpenVPN log van je client?
* Wat staat er in je ip[6]tables? Heb je een ip[6]table rule die firewall drops logt? Zo ja, zie je iets dat op poort 1194 wordt geblokkeerd?

Ik heb het volgende in mijn router staan (FRITZ!Box 5490). De eerste is de statische route van subnet 3 naar mijn OpenVPN server (subnet 1), door het IPv6 adres te gebruiken die ik van XS4ALL heb gekregen. Je kan ook de link-local adressen gebruiken, makes no difference. Maar die ik gebruik blijft zo, link-local kan wijzigen. De tweede screenshot is port forwarding. FRITZ!Box heeft daar toch een soort van firewall oplossing zodat IPv6 hosts niet open staan op het internet. Je kan je host volledig open zetten, of slechts de poorten die je gebruikt. Ik heb het laatste gedaan.

[ Voor 6% gewijzigd door UPPERKEES op 26-10-2018 07:41 ]

[Verwijderd]

Ik ben na een paar maanden terug de handdoek in de ring gegooid te hebben toch weer bezig om dit te proberen. Ditmaal met een helemaal schone DietPi installatie op mijn Raspberry.

De installatie zelf werkte en zowel ping als ping6 gave respons. Nu wil ik ik voordat ik een VPN server ga installeren zorgen dat elke stapje goed werkt, zodat ik in elk geval weet waar het probleem ongeveer zit.

Nog voordat de OpenVPN en firewall instellingen er bij komen kijken is het nu zo dat als ik op de Raspberry in /etc/sysctl.conf
ipv6 forwarding aanzet door net.ipv6.conf.all.forwarding=1 toe te voegen, ping6 op de Raspberry niet meer werkt.

Ik denk dat dit de kern van mijn probleem moet zijn, want als de Raspberry geen ipv6 verbinding kan maken kan hij dat ook niet forwarden over het VPN.
Ik snap hier allemaal nog vrij weinig van dus ik hoor het graag als ik mis zit met m'n conclusies.

[idef1x]

Dat is wel erg vreemd. Bij mij werkt het gewoon op mijn Pi...
Op het moment dat je die ping doet op je Pi:
- heb je een publiek ipv6 adres op de pi?
- geen firewall/iptables die de boel blokkeerd
- je ipv6 routering staat goed?
- sysctl -p gedaan en output is iets als:
net.ipv6.conf.all.forwarding = 1

als je die sysctl regel weghaald, doet ie het dan weer wel?

[Verwijderd]

Dat is inderdaad allemaal het geval. Ik ben er inmiddels achter dat de oorzaak is dat de Raspberry niet naar Router Advertisement luistert als IPv6 forwarding aanstaat.
Zodra ik ‘net.ipv6.conf.eth0.accept_ra=2’ toevoeg in /etc/sysctl werkt ping6 weer.
Daarmee lijkt de oorzaak van dit probleem dit probleem opgelost en is het volgende dat ik moet zien te doen een /64 IPv6 prefix naar de raspberry routen vanaf de Fritz!Box.
Momenteel heb ik dat zo gedaan: http://imgur.com/mRrl6Qs.
Is dit de juiste manier om dat te doen vanaf een Fritz!Box?