Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
[...] Enorme knip >> , >> | tcpdump -ni eth0 port 2309 >> | tcpdump: verbose output suppressed, use -v[v]... for full protocol decode >> | listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 >> bytes >> | 10:08:06.110814 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags >> [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882732426 >> ecr 0,nop,wscale 7], length 0 >> | 10:08:07.126090 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags >> [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882733442 >> ecr 0,nop,wscale 7], length 0 >> | 10:08:09.143819 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags >> [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882735458 >> ecr 0,nop,wscale 7], length 0 >> ` > > Daar staat: > Op WireGuard server is te zien dat > pakketten van WGclient fd42:42:42::2 naar 2001:888:0:18::93 worden gestuurd. > > > Er staat ook: > We zien niet dat er pakketten terugkomen. > > > Dat er vanaf 2001:888:0:18::93 geen route terug naar fd42:42:42::2 is, > is "correct". > > > Voor mij is het oorspronkelijke "probleem" afgehandeld. Haha (ahem) Dus het is /toch/ iets als "Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993716
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
On 26 September 2021 10:59 Geert Stappers, wrote: (knip!) > telnet -4 salsa.debian.org 2309 ik doe op de client telnet 6 salsa.debian.org 2309 dan toon de server tcpdump -ni any port 2309 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:18:28.147092 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089390879 ecr 0,nop,wscale 7], length 0 15:18:28.147116 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089390879 ecr 0,nop,wscale 7], length 0 15:18:29.166704 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089391898 ecr 0,nop,wscale 7], length 0 15:18:29.166719 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089391898 ecr 0,nop,wscale 7], length 0 15:18:31.182594 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089393914 ecr 0,nop,wscale 7], length 0 15:18:31.182612 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089393914 ecr 0,nop,wscale 7], length 0 15:18:35.278501 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089398010 ecr 0,nop,wscale 7], length 0 15:18:35.278521 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089398010 ecr 0,nop,wscale 7], length 0
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
On Sun, Sep 26, 2021 at 10:13:16AM +0200, Gijs Hillenius wrote: > > uitput op de server van (op client) telnet xs4all.nl 2309 > > , > | tcpdump -ni any port 2309 > | tcpdump: data link type LINUX_SLL2 > | tcpdump: verbose output suppressed, use -v[v]... for full protocol decode > | listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length > 262144 bytes > | 10:01:07.351560 wg0 In IP 10.66.66.2.50640 > 194.109.6.93.2309: Flags > [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val 2717353847 > ecr 0,nop,wscale 7], length 0 > | 10:01:07.351590 eth0 Out IP 144.76.204.189.50640 > 194.109.6.93.2309: > Flags [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val > 2717353847 ecr 0,nop,wscale 7], length 0 > | 10:01:08.370230 wg0 In IP 10.66.66.2.50640 > 194.109.6.93.2309: Flags > [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val 2717354866 > ecr 0,nop,wscale 7], length 0 > | 10:01:08.370248 eth0 Out IP 144.76.204.189.50640 > 194.109.6.93.2309: > Flags [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val > 2717354866 ecr 0,nop,wscale 7], length 0 > | 10:01:10.386263 wg0 In IP 10.66.66.2.50640 > 194.109.6.93.2309: Flags > [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val 2717356882 > ecr 0,nop,wscale 7], length 0 > | 10:01:10.386282 eth0 Out IP 144.76.204.189.50640 > 194.109.6.93.2309: > Flags [S], seq 1011808921, win 64860, options [mss 1380,sackOK,TS val > 2717356882 ecr 0,nop,wscale 7], length 0 > ` Wel de pakketen met S-flag, geen pakketen terug met R-flag. Reden zou kunnen zijn dat end point 194.109.6.93 niet terugstuurt "Geen service op poort 2309" Kleine test: | $ telnet -4 194.109.6.93 2309 | Trying 194.109.6.93... | telnet: Unable to connect to remote host: Connection timed out | $ Inderdaad, de andere kant stuurt niets terug. Om wel pakketten met R-flag te zien | $ telnet -4 salsa.debian.org 2309 | Trying 209.87.16.44... | telnet: Unable to connect to remote host: Connection refused | $ telnet -6 salsa.debian.org 2309 | Trying 2607:f8f0:614:1::1274:44... | telnet: Unable to connect to remote host: Connection refused | $ > , > | tcpdump -ni eth0 port 2309 > | tcpdump: verbose output suppressed, use -v[v]... for full protocol decode > | listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes > | 10:08:06.110814 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags > [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882732426 > ecr 0,nop,wscale 7], length 0 > | 10:08:07.126090 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags > [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882733442 > ecr 0,nop,wscale 7], length 0 > | 10:08:09.143819 IP6 fd42:42:42::2.43674 > 2001:888:0:18::93.2309: Flags > [S], seq 2765591401, win 65280, options [mss 1360,sackOK,TS val 2882735458 > ecr 0,nop,wscale 7], length 0 > ` Daar staat: Op WireGuard server is te zien dat pakketten van WGclient fd42:42:42::2 naar 2001:888:0:18::93 worden gestuurd. Er staat ook: We zien niet dat er pakketten terugkomen. Dat er vanaf 2001:888:0:18::93 geen route terug naar fd42:42:42::2 is, is "correct". Voor mij is het oorspronkelijke "probleem" afgehandeld. Groeten Geert Stappers -- Silence is hard to parse
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
Dank voor het geduld en meedenken On 25 September 2021 23:24 Geert Stappers, wrote: > On Sat, Sep 25, 2021 at 09:04:26AM +0200, Gijs Hillenius wrote: >> Goedenmorgen! >> >> Tijd voor een update. Er zit een (klein) beetje schot in, maar ik ben er >> nog niet. >> >> /me veegt lei schoon, huidige configuratie onderaan. >> >> >> A) IPv4 lijkt het te doen. >> >> Met ping4 kom ik voorbij de server. En, ik kan (als voorbeeld) met ssh >> -4 een-vri...@shell.xs4all.nl bereiken, en dan toont het me dat ik kom >> vanaf 144.76.204.189, zoals de bedoeling is. >> >> Mijn conclusie: masquerading werkt, >> en de firewalld doet zijn werk. Voor IPv4. > > Ja, er zal sprake zijn van masquerading. > Waar het gebeurd heeft het verhaal nog niet vertelt. > Is het misschien iets wat "ADSL modem router" doet? Goede vraag. Belgacom/Proximus doet inderdaad NAT voor IPv4 en IPv6, en roteert (ongeveer 1 keer per jaar) de IP addressen. Als ik op de client Wireguard *niet* aanzet, dan is het antwoord van ssh -4 shell.xs4all.nl dat het verkeert komt vanaf 109.146.128.183 zet ik Wireguard aan, dan komt het dus van mijn servertje. >> b) IPv6 gaat gedeeltelijk goed. >> >> Zowel client en server kan ik nu heen en weer met ping6 bereiken. Maar >> ik kom niet vanaf de client voorbij de server, niet met ping6, maar ook >> niet met ssh. Bijvoorbeeld >> >> ssh -6 weer-die-vri...@shell.xs4all.nl >> (knip) >> debug1: Connecting to shell.xs4all.nl [2001:888:0:1::9] port 22. >> >> en dan stilte, tot ik ^C doe. > > Er zal ook masquerading nodig zijn. Dan wel iets anders zodat "local > addresses" ( fc80:: ) niet meer lokale adressen zijn. > > > > >> De configuratie van de client - let op, er staan twee mogelijke IPv[4,6] >> reeksen, ze doen het beiden (niet tegelijk, uiteraard). >> >> , >> | [Interface] >> | Address= 10.93.15.2/24, fc80::b85f:d925:971e:110f/64 >> | # een alternatief, werkt ook: Address = 10.66.66.2/24,fd42:42:42::2/64 >> | PrivateKey = >> | >> | [Peer] >> | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= >> | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 >> | AllowedIPs = 0.0.0.0/0, ::/0 >> | PersistentKeepalive = 25 >> ` >> >> en die van de server: >> >> , >> | Interface] >> | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 >> | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 >> | PrivateKey = >> | ListenPort = 51820 >> | >> | [Peer] >> | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= >> | # alternatief: AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128 >> | AllowedIPs = 10.93.15.2/32, fc80::b85f:d925:971e:110f/128 >> ` >> >> In de spaarzame vrije tijd heb ik van alles nagelopen. >> > ... IPv4 ... >> >> Dan spelde ik https://wiki.debian.org/NetworkConfiguration: mist mijn >> static configured ethernet device (die van de oops) soms "accept_ra 2" >> (ik begrijp het helaas nog niet helemaal) >> >> sysctl net.ipv6.conf.all.accept_ra=2 getest >> >> Maar het maakt voor WireGuard niets uit. >> >> Ik zie ook /niets/ relevants in de logs (mezelf kennende zal het er toch >> wel staan). >> >> Hier een paar van de huidige IPv6 instellingen op de server: >> >> sysctl -a | grep -E 'ipv6.*\.(forwarding|accept_ra) =' >> net.ipv6.conf.all.accept_ra = 1 >> net.ipv6.conf.all.forwarding = 1 >> net.ipv6.conf.default.accept_ra = 1 >> net.ipv6.conf.default.forwarding = 1 >> net.ipv6.conf.eth0.accept_ra = 0 >> net.ipv6.conf.eth0.forwarding = 1 >> net.ipv6.conf.lo.accept_ra = 1 >> net.ipv6.conf.lo.forwarding = 1 >> net.ipv6.conf.wg0.accept_ra = 1 >> net.ipv6.conf.wg0.forwarding = 1 > > > Met de diverse 'forwarding = 1' ben ik het mee eens. > > Wat ik hier van de "accept router advertizing" moet vinden, > weet ik nog niet. > > > >> Waarom doe ik al die moeite om Wireguard ook via IPv6 te doen? Tja: ik >> wil het gewoon in orde hebben, het is net als het strijken van je >> overhemden. In België wordt IPv6 gewoon goed ondersteund, het werkt goed >> op mijn LAN, het doet het uitstekend in Debian. WireGuard kan het, dus >> waarom zou ik het niet doen? > > Met alle respect: "Your logic is flawed" ... zeer wel mogelijk > Weet dat ik het ook een uitdagend probleem vind. > Mijn insteek is wel "Waar gaat het kapot?" (vermoeden: Geen NAT) > > Gijs zijn insteek is meer "Hoe krijg ik het werkend?" > > > Als we roepen "Het gaat niet" komt de mensheid nooit vooruit. Tja uhm. Beschouw de twee als synonym? > > >> op de server: >> >> ip -6 route >> , >> | ::1 dev lo proto kernel metric 256 pref medium >> | 2a01:4f8:200:546b::/64 dev eth0 proto kernel metric 256 pref medium >> | fd42:42:42::/64 dev wg0 proto kernel metric 256 pref medium > Dat komt niet overeen met > | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 > Eventueel wel met > | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 Goed gezien. Ik had inmiddels die twee reeksen omgewisseld. >> | fe80::/64 dev eth0 proto kernel metric 256 pref medium >> | default via 2a01:4f8:200:546b::
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
On Sat, Sep 25, 2021 at 09:04:26AM +0200, Gijs Hillenius wrote: > Goedenmorgen! > > Tijd voor een update. Er zit een (klein) beetje schot in, maar ik ben er > nog niet. > > /me veegt lei schoon, huidige configuratie onderaan. > > > A) IPv4 lijkt het te doen. > > Met ping4 kom ik voorbij de server. En, ik kan (als voorbeeld) met ssh > -4 een-vri...@shell.xs4all.nl bereiken, en dan toont het me dat ik kom > vanaf 144.76.204.189, zoals de bedoeling is. > > Mijn conclusie: masquerading werkt, > en de firewalld doet zijn werk. Voor IPv4. Ja, er zal sprake zijn van masquerading. Waar het gebeurd heeft het verhaal nog niet vertelt. Is het misschien iets wat "ADSL modem router" doet? > b) IPv6 gaat gedeeltelijk goed. > > Zowel client en server kan ik nu heen en weer met ping6 bereiken. Maar > ik kom niet vanaf de client voorbij de server, niet met ping6, maar ook > niet met ssh. Bijvoorbeeld > > ssh -6 weer-die-vri...@shell.xs4all.nl > (knip) > debug1: Connecting to shell.xs4all.nl [2001:888:0:1::9] port 22. > > en dan stilte, tot ik ^C doe. Er zal ook masquerading nodig zijn. Dan wel iets anders zodat "local addresses" ( fc80:: ) niet meer lokale adressen zijn. > De configuratie van de client - let op, er staan twee mogelijke IPv[4,6] > reeksen, ze doen het beiden (niet tegelijk, uiteraard). > > , > | [Interface] > | Address= 10.93.15.2/24, fc80::b85f:d925:971e:110f/64 > | # een alternatief, werkt ook: Address = 10.66.66.2/24,fd42:42:42::2/64 > | PrivateKey = > | > | [Peer] > | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= > | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 > | AllowedIPs = 0.0.0.0/0, ::/0 > | PersistentKeepalive = 25 > ` > > en die van de server: > > , > | Interface] > | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 > | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 > | PrivateKey = > | ListenPort = 51820 > | > | [Peer] > | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= > | # alternatief: AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128 > | AllowedIPs = 10.93.15.2/32, fc80::b85f:d925:971e:110f/128 > ` > > In de spaarzame vrije tijd heb ik van alles nagelopen. > ... IPv4 ... > > Dan spelde ik https://wiki.debian.org/NetworkConfiguration: mist mijn > static configured ethernet device (die van de oops) soms "accept_ra 2" > (ik begrijp het helaas nog niet helemaal) > > sysctl net.ipv6.conf.all.accept_ra=2 getest > > Maar het maakt voor WireGuard niets uit. > > Ik zie ook /niets/ relevants in de logs (mezelf kennende zal het er toch > wel staan). > > Hier een paar van de huidige IPv6 instellingen op de server: > > sysctl -a | grep -E 'ipv6.*\.(forwarding|accept_ra) =' > net.ipv6.conf.all.accept_ra = 1 > net.ipv6.conf.all.forwarding = 1 > net.ipv6.conf.default.accept_ra = 1 > net.ipv6.conf.default.forwarding = 1 > net.ipv6.conf.eth0.accept_ra = 0 > net.ipv6.conf.eth0.forwarding = 1 > net.ipv6.conf.lo.accept_ra = 1 > net.ipv6.conf.lo.forwarding = 1 > net.ipv6.conf.wg0.accept_ra = 1 > net.ipv6.conf.wg0.forwarding = 1 Met de diverse 'forwarding = 1' ben ik het mee eens. Wat ik hier van de "accept router advertizing" moet vinden, weet ik nog niet. > Waarom doe ik al die moeite om Wireguard ook via IPv6 te doen? Tja: ik > wil het gewoon in orde hebben, het is net als het strijken van je > overhemden. In België wordt IPv6 gewoon goed ondersteund, het werkt goed > op mijn LAN, het doet het uitstekend in Debian. WireGuard kan het, dus > waarom zou ik het niet doen? Met alle respect: "Your logic is flawed" Weet dat ik het ook een uitdagend probleem vind. Mijn insteek is wel "Waar gaat het kapot?" (vermoeden: Geen NAT) Gijs zijn insteek is meer "Hoe krijg ik het werkend?" Als we roepen "Het gaat niet" komt de mensheid nooit vooruit. > op de server: > > ip -6 route > , > | ::1 dev lo proto kernel metric 256 pref medium > | 2a01:4f8:200:546b::/64 dev eth0 proto kernel metric 256 pref medium > | fd42:42:42::/64 dev wg0 proto kernel metric 256 pref medium Dat komt niet overeen met | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 Eventueel wel met | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 > | fe80::/64 dev eth0 proto kernel metric 256 pref medium > | default via 2a01:4f8:200:546b::3 dev eth0 metric 1024 onlink pref medium > ` > > Mij valt op dat ssh -6 hierboven wel weet welk IP address ie moet > hebben. > > /etc/resolf.conf op de server (wg0 is up) > nameserver 2606:4700:4700:: > nameserver 1.1.1.1 > > op de client (wg0 is eveneens up) > search home > nameserver 192.168.1.1 > > dank voor de aandacht! Output van `ip -6 route` op client ontbrak. > Vraag: Hoe tover ik op de wireguard server informatie tevoorschijn die > toont waarom het IPv6 verkeer stopt bij de server. Iemand suggesties? Het echte probleem^Wuitdaging is connectie tussen wireguard client en IPv6 host voorbij wireguard server. Of dat IPv6 verkeer stopt bij de wireguard server i
