Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > xs4all.ipv6 > #4205 > unrolled thread

plat?

Back to article view | Back to xs4all.ipv6

Contents

  plat? Rob <nomail@example.com> - 2021-05-11 13:01 +0000
    Re: plat? richard lucassen <mailinglists@lucassen.org> - 2021-05-11 18:26 +0200
      Re: plat? Rob <nomail@example.com> - 2021-05-11 16:33 +0000
        Re: plat? "Miquel van Smoorenburg" <mikevs@xs4all.nederland.invalid> - 2021-05-11 20:57 +0000
          Re: plat? Rob <nomail@example.com> - 2021-05-11 21:06 +0000
            Re: plat? "Miquel van Smoorenburg" <mikevs@xs4all.nederland.invalid> - 2021-05-11 22:09 +0000
    Re: plat? Udo <udovdh@xs4all> - 2021-05-15 13:00 +0200
      Re: plat? Rob <nomail@example.com> - 2021-05-15 13:40 +0000
        Re: plat? Udo <udovdh@xs4all> - 2021-05-16 06:42 +0200
          Re: plat? richard lucassen <mailinglists@lucassen.org> - 2021-05-16 11:07 +0200
            Re: plat? Udo <udovdh@xs4all> - 2021-05-17 10:53 +0200
            Re: plat? Udo <udovdh@xs4all> - 2021-05-17 10:54 +0200
              Re: plat? richard lucassen <mailinglists@lucassen.org> - 2021-05-17 22:14 +0200
                Re: plat? Udo <udovdh@xs4all> - 2021-05-29 15:36 +0200
                  Re: plat? Rob <nomail@example.com> - 2021-05-29 14:29 +0000
                    Re: plat? Udo <udovdh@xs4all> - 2021-05-29 18:17 +0200
                      Re: plat? Rob <nomail@example.com> - 2021-05-30 09:15 +0000
                        Re: plat? Udo <udovdh@xs4all> - 2021-05-30 11:42 +0200
                          Re: plat? Rob <nomail@example.com> - 2021-05-30 09:58 +0000
                            Re: plat? Udo <udovdh@xs4all> - 2021-05-30 13:29 +0200
            Re: plat? Udo <udovdh@xs4all> - 2021-05-17 11:00 +0200
              Re: plat? Udo <udovdh@xs4all> - 2021-05-24 07:04 +0200
          Re: plat? Rob <nomail@example.com> - 2021-05-16 17:38 +0000
            Re: plat? Coen <newstrash1110@rosdorff.dyndns.org> - 2021-05-17 00:09 +0200
            Re: plat? "Miquel van Smoorenburg" <mikevs@xs4all.nederland.invalid> - 2021-05-16 21:35 +0000
              Re: plat? Rob <nomail@example.com> - 2021-05-17 07:35 +0000
                Re: plat? richard lucassen <mailinglists@lucassen.org> - 2021-05-17 22:10 +0200
              Re: plat? Rob <nomail@example.com> - 2021-05-18 08:20 +0000
              Re: plat? "A. Dumas" <alexandre@dumas.fr.invalid> - 2021-07-09 12:54 +0200
                Re: plat? Koos van den Hout <koos+newsposting@idefix.net> - 2021-07-09 12:32 +0000

Page 1 of 2  [1] 2  Next page →

#4205 — plat?

Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
In ieder geval naar Ziggo.

[toc] | [next] | [standalone]

#4206

On 11 May 2021 13:01:57 GMT
Rob <nomail@example.com> wrote:

> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
> In ieder geval naar Ziggo.

Ik heb hier vanaf xs gewoon toegang tot een ziggo zakelijk op ipv6

R.

-- 
richard lucassen
http://contact.xaq.nl/

[toc] | [prev] | [next] | [standalone]

#4207

richard lucassen <mailinglists@lucassen.org> wrote:
> On 11 May 2021 13:01:57 GMT
> Rob <nomail@example.com> wrote:
>
>> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
>> In ieder geval naar Ziggo.
>
> Ik heb hier vanaf xs gewoon toegang tot een ziggo zakelijk op ipv6

Nu werkt het weer maar vanmiddag was het bij Ziggo helemaal plat en
ook vanuit XS4ALL kon ik allerlei dingen niet bereiken.  Het leek er
op dat er wat met de IPv6 routing was.

Ik zie ook allerlei andere storingen trouwens, zoals wegvallende PPPoE
verbindingen zowel over glas als over VDSL.

[toc] | [prev] | [next] | [standalone]

#4208

In article <slrns9lcev.147.nomail@xs9.xs4all.nl>,
Rob  <nomail@example.com> wrote:
>richard lucassen <mailinglists@lucassen.org> wrote:
>> On 11 May 2021 13:01:57 GMT
>> Rob <nomail@example.com> wrote:
>>
>>> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
>>> In ieder geval naar Ziggo.
>>
>> Ik heb hier vanaf xs gewoon toegang tot een ziggo zakelijk op ipv6
>
>Nu werkt het weer maar vanmiddag was het bij Ziggo helemaal plat en
>ook vanuit XS4ALL kon ik allerlei dingen niet bereiken.  Het leek er
>op dat er wat met de IPv6 routing was.
>
>Ik zie ook allerlei andere storingen trouwens, zoals wegvallende PPPoE
>verbindingen zowel over glas als over VDSL.

Er was vanmorgen een storing in fiber verbindingen tussen KPN en
XS4ALL. Dat is allemaal redundant uitgevoerd, maar er is wel
een failover geweest. Dat verklaart je wegvallende PPP verbinding.

En ik heb eerder gezien dat als dat gebeurt, in sommige gevallen
de fritzbox wel weer IPv4 opbouwt, maar dat er bij IPv6 iets
niet lekker gaat. Mogelijk iets met de DHCPv6 lease aanvraag oid?
Dat zou je IPv6 issue kunnen verklaren.

Mike.

[toc] | [prev] | [next] | [standalone]

#4209

Miquel van Smoorenburg <mikevs@xs4all.nederland.invalid> wrote:
> In article <slrns9lcev.147.nomail@xs9.xs4all.nl>,
> Rob  <nomail@example.com> wrote:
>>richard lucassen <mailinglists@lucassen.org> wrote:
>>> On 11 May 2021 13:01:57 GMT
>>> Rob <nomail@example.com> wrote:
>>>
>>>> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
>>>> In ieder geval naar Ziggo.
>>>
>>> Ik heb hier vanaf xs gewoon toegang tot een ziggo zakelijk op ipv6
>>
>>Nu werkt het weer maar vanmiddag was het bij Ziggo helemaal plat en
>>ook vanuit XS4ALL kon ik allerlei dingen niet bereiken.  Het leek er
>>op dat er wat met de IPv6 routing was.
>>
>>Ik zie ook allerlei andere storingen trouwens, zoals wegvallende PPPoE
>>verbindingen zowel over glas als over VDSL.
>
> Er was vanmorgen een storing in fiber verbindingen tussen KPN en
> XS4ALL. Dat is allemaal redundant uitgevoerd, maar er is wel
> een failover geweest. Dat verklaart je wegvallende PPP verbinding.
>
> En ik heb eerder gezien dat als dat gebeurt, in sommige gevallen
> de fritzbox wel weer IPv4 opbouwt, maar dat er bij IPv6 iets
> niet lekker gaat. Mogelijk iets met de DHCPv6 lease aanvraag oid?
> Dat zou je IPv6 issue kunnen verklaren.
>
> Mike.

Nou nee die storing was s'middags zo tegen half 3.  Ik was op het werk
en zag dat alle IPv6 verbindingen tussen Ziggo en XS4ALL eruit vlogen
terwijl IPv4 wel bleef werken.
(na eerdere ervaringen van het omgekeerde hebben we de VPN tunnels
tussen de locaties redundant over IPv4 en IPv6 gemaakt :-)

Toen ging ik van 2 kanten af met tracepath aan de gang en zag dat
er bij XS4ALL geen route was naar Ziggo (meteen !N) en ook andere
bestemmingen die ik probeerde werkten niet.  Op dat moment was er
binnen XS4ALL wel routing maar naar buiten leek het van niet.

Bij Ziggo werkte er echter helemaal niks meer op IPv6 en ik denk dat
de storing in feite daar zat en niet bij XS4ALL, of ergens in het
transit netwerk.

Echter die PPPoE onderbrekingen die heb ik op andere momenten ook
gezien bijv om 13:00 op glas in Houten en om 17:50 op VDSL in Utrecht.

Met de MikroTik routers die ik gebruik (direct op glas, of achter
de Fritzbox op VDSL) is het probleem precies omgekeerd: na een
PPPoE onderbreking is er soms wel IPv6 maar geen IPv4.  Maar daar
heb ik een watchdog scriptje voor gemaakt wat in zo'n geval de PPPoE
interface nog een keer reset, en dat helpt dan.

Al met al heb ik diverse storingen gezien op diverse plekken vandaag.
Wellicht als gevolg van die fiber problemen en de recovery daarvan.

[toc] | [prev] | [next] | [standalone]

#4210

In article <slrns9lsfc.r4e.nomail@xs9.xs4all.nl>,
Rob  <nomail@example.com> wrote:
>Nou nee die storing was s'middags zo tegen half 3.  Ik was op het werk
>en zag dat alle IPv6 verbindingen tussen Ziggo en XS4ALL eruit vlogen
>terwijl IPv4 wel bleef werken.

Om half 3 ... dat kan ik niet verklaren. Geen storing bekend hier.
Sowieso zou dat wel opvallen, "alle IPv6 eruit". We hebben diverse
systemen die IPv6-only zijn.

>Toen ging ik van 2 kanten af met tracepath aan de gang en zag dat
>er bij XS4ALL geen route was naar Ziggo (meteen !N) en ook andere
>bestemmingen die ik probeerde werkten niet.  Op dat moment was er
>binnen XS4ALL wel routing maar naar buiten leek het van niet.
>
>Bij Ziggo werkte er echter helemaal niks meer op IPv6 en ik denk dat
>de storing in feite daar zat en niet bij XS4ALL, of ergens in het
>transit netwerk.

Lijkt er wel op.

>Echter die PPPoE onderbrekingen die heb ik op andere momenten ook
>gezien bijv om 13:00 op glas in Houten en om 17:50 op VDSL in Utrecht.

Ah, bij nader bekijken: er was iets om 10 uur wat niet significant
was, en iets om 13:00 wat dat wel was. Allebei ergens binnen KPN.
Om 17:50 weet ik niet, dat kan iets veel lokaler zijn geweest.
Alleen Houten of alleen die DSLAM ofzo.

Mike.

[toc] | [prev] | [next] | [standalone]

#4211

On 11-05-2021 15:01, Rob wrote:
> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
> In ieder geval naar Ziggo.

Ik merkte wat sites die een F5 nodig hadden om gevonden te worden.
Vreemder is dat dhclient geen prefix lijkt te ontvangen, ook zonder 
firewall. Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209

Ohja, af en toe moet ik de pppd herstarten om weer verkeer te verkrijgen.

Udo

[toc] | [prev] | [next] | [standalone]

#4212

Udo <udovdh@xs4all> wrote:
> On 11-05-2021 15:01, Rob wrote:
>> Volgens mij ligt de IPv6 naar buiten toe er een beetje uit...
>> In ieder geval naar Ziggo.
>
> Ik merkte wat sites die een F5 nodig hadden om gevonden te worden.
> Vreemder is dat dhclient geen prefix lijkt te ontvangen, ook zonder 
> firewall. Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209
>
> Ohja, af en toe moet ik de pppd herstarten om weer verkeer te verkrijgen.
>
> Udo

Mijn ervaring met een Linux-based router (ik weet niet wat daar precies
in draait rond PPPoE voor IPv4 en IPv6) is juist net omgekeerd: bij
onderbrekingen in het aansluitnetwerk komt het soms voor dat er geen
IPv4 adres meer is en komt, maar wel IPv6.  Herstart van de PPPoE
interface lost dat dan meteen op.
Dit is op een glas aansluiting.

Wat ik ook wel gehad heb is dat na een onderbreking op een andere
aansluiting (VDSL) de PPP verbinding helemaal niet meer opkomt, en
dat dit opgelost kan worden door ofwel de VDSL laag te resetten
(modem hertrainen) ofwel de PPP een paar minuten down te brengen en
dan pas weer te starten.  Dit schijnt te maken te hebben met een of
andere buggy netwerkcomponent die snooping van de PPP packets doet
en als je blijft proberen dan blijft ie vastzitten in een foute status.
Doe je dan een reset van de VDSL dan wordt dit meteen gereset en als
je 3 minuten wacht ofzo dan ook.  Maar blijf je discover packets
sturen dan is het uren later nog plat.

Beide zaken heb ik met scriptjes in de router opgelost.

[toc] | [prev] | [next] | [standalone]

#4213

On 15-05-2021 15:40, Rob wrote:
> Beide zaken heb ik met scriptjes in de router opgelost.

Hier is ook een ping-script actief voor IPv4.

Het IPv6 probleem is bijzonder vreemd: (ISC) dhclient vraagt om een 
prefix, de dhcp-server antwoordt (volgens tcpdump) maar dhclient lijkt 
niets te ontvangen.
Ook met IPv6 firewall plat is dit gedrag te zien.
Wat kan het verkeer nog tegenhouden?

Udo

[toc] | [prev] | [next] | [standalone]

#4214

On Sun, 16 May 2021 06:42:54 +0200
Udo <udovdh@xs4all> wrote:

> Hier is ook een ping-script actief voor IPv4.
> 
> Het IPv6 probleem is bijzonder vreemd: (ISC) dhclient vraagt om een 
> prefix, de dhcp-server antwoordt (volgens tcpdump) maar dhclient
> lijkt niets te ontvangen.
> Ook met IPv6 firewall plat is dit gedrag te zien.
> Wat kan het verkeer nog tegenhouden?

Laat poort 546/udp eens toe vanaf fe80::/10

-- 
richard lucassen
http://contact.xaq.nl/

[toc] | [prev] | [next] | [standalone]

#4219

On 16-05-2021 11:07, richard lucassen wrote:
> On Sun, 16 May 2021 06:42:54 +0200
> Udo <udovdh@xs4all> wrote:
> 
>> Hier is ook een ping-script actief voor IPv4.
>>
>> Het IPv6 probleem is bijzonder vreemd: (ISC) dhclient vraagt om een
>> prefix, de dhcp-server antwoordt (volgens tcpdump) maar dhclient
>> lijkt niets te ontvangen.
>> Ook met IPv6 firewall plat is dit gedrag te zien.
>> Wat kan het verkeer nog tegenhouden?
> 
> Laat poort 546/udp eens toe vanaf fe80::/10

Dat gebeurt min of meer al:

[root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
     4246   768526 ACCEPT     udp      ppp0   *       ::/0 
    ::/0                 udp spt:547 dpt:546


In `dmesg` komen geen gedropte UDP packets voor die samenhangen met 
dhclient c.q. dhcp-server.
Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken 
verzenden, niet reageren op antwoorden van de dhcp-server.

Udo

[toc] | [prev] | [next] | [standalone]

#4220

On 16-05-2021 11:07, richard lucassen wrote:
 > On Sun, 16 May 2021 06:42:54 +0200
 > Udo <udovdh@xs4all> wrote:
 >
 >> Hier is ook een ping-script actief voor IPv4.
 >>
 >> Het IPv6 probleem is bijzonder vreemd: (ISC) dhclient vraagt om een
 >> prefix, de dhcp-server antwoordt (volgens tcpdump) maar dhclient
 >> lijkt niets te ontvangen.
 >> Ook met IPv6 firewall plat is dit gedrag te zien.
 >> Wat kan het verkeer nog tegenhouden?
 >
 > Laat poort 546/udp eens toe vanaf fe80::/10
Dat gebeurt min of meer al:

[root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
     4246   768526 ACCEPT     udp      ppp0   *       ::/0 
    ::/0                 udp spt:547 dpt:546


In `dmesg` komen geen gedropte UDP packets voor die samenhangen met 
dhclient c.q. dhcp-server.
Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken 
verzenden, niet reageren op antwoorden van de dhcp-server.

Udo

[toc] | [prev] | [next] | [standalone]

#4223

On Mon, 17 May 2021 10:54:42 +0200
Udo <udovdh@xs4all> wrote:

>  > Laat poort 546/udp eens toe vanaf fe80::/10

> Dat gebeurt min of meer al:
> 
> [root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
>      4246   768526 ACCEPT     udp      ppp0   *       ::/0 
>     ::/0                 udp spt:547 dpt:546
> 
> 
> In `dmesg` komen geen gedropte UDP packets voor die samenhangen met 
> dhclient c.q. dhcp-server.
> Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken 
> verzenden, niet reageren op antwoorden van de dhcp-server.

Dit staat er bij mij in:

-A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT

Geen idee of de src port altijd 547 is.

R.

-- 
richard lucassen
http://contact.xaq.nl/

[toc] | [prev] | [next] | [standalone]

#4226

On 17-05-2021 22:14, richard lucassen wrote:
> On Mon, 17 May 2021 10:54:42 +0200
> Udo <udovdh@xs4all> wrote:
> 
>>   > Laat poort 546/udp eens toe vanaf fe80::/10
> 
>> Dat gebeurt min of meer al:
>>
>> [root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
>>       4246   768526 ACCEPT     udp      ppp0   *       ::/0
>>      ::/0                 udp spt:547 dpt:546
>>
>>
>> In `dmesg` komen geen gedropte UDP packets voor die samenhangen met
>> dhclient c.q. dhcp-server.
>> Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken
>> verzenden, niet reageren op antwoorden van de dhcp-server.
> 
> Dit staat er bij mij in:
> 
> -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT
> 
> Geen idee of de src port altijd 547 is.

In mijn dtcpdumps wel.
Zoniet zou ik e.e.a. ook gelogd zien als geblockt.
En dat gebeurt niet.

Ik heb dus geen idee of het DHCP verkeer via INPUT en FORWARD bij 
dhclient aankomt. (logische verklaring: nee)
Ook heb ik geen idee waarom het DHCP de FORWARD in gaat of moet.
Het adres waar e.e.a. heen moet immers is lokaal.
Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209#c7 voor tcpdump 
met kale IPv6 adressen.
Zie ik iets over het hoofd wat de rare FORWARD verklaart?

Udo

[toc] | [prev] | [next] | [standalone]

#4227

Udo <udovdh@xs4all> wrote:
> On 17-05-2021 22:14, richard lucassen wrote:
>> On Mon, 17 May 2021 10:54:42 +0200
>> Udo <udovdh@xs4all> wrote:
>> 
>>>   > Laat poort 546/udp eens toe vanaf fe80::/10
>> 
>>> Dat gebeurt min of meer al:
>>>
>>> [root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
>>>       4246   768526 ACCEPT     udp      ppp0   *       ::/0
>>>      ::/0                 udp spt:547 dpt:546
>>>
>>>
>>> In `dmesg` komen geen gedropte UDP packets voor die samenhangen met
>>> dhclient c.q. dhcp-server.
>>> Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken
>>> verzenden, niet reageren op antwoorden van de dhcp-server.
>> 
>> Dit staat er bij mij in:
>> 
>> -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT
>> 
>> Geen idee of de src port altijd 547 is.
>
> In mijn dtcpdumps wel.
> Zoniet zou ik e.e.a. ook gelogd zien als geblockt.
> En dat gebeurt niet.
>
> Ik heb dus geen idee of het DHCP verkeer via INPUT en FORWARD bij 
> dhclient aankomt. (logische verklaring: nee)
> Ook heb ik geen idee waarom het DHCP de FORWARD in gaat of moet.
> Het adres waar e.e.a. heen moet immers is lokaal.
> Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209#c7 voor tcpdump 
> met kale IPv6 adressen.
> Zie ik iets over het hoofd wat de rare FORWARD verklaart?

Ik gebruik altijd MikroTik routers waar intern Linux draait (iptables)
en ik heb de rules die hiermee te maken hebben altijd alleen bij INPUT
staan.  Dat werkt prima.

[toc] | [prev] | [next] | [standalone]

#4228

On 29-05-2021 16:29, Rob wrote:
> Udo <udovdh@xs4all> wrote:
>> On 17-05-2021 22:14, richard lucassen wrote:
>>> On Mon, 17 May 2021 10:54:42 +0200
>>> Udo <udovdh@xs4all> wrote:
>>>
>>>>    > Laat poort 546/udp eens toe vanaf fe80::/10
>>>
>>>> Dat gebeurt min of meer al:
>>>>
>>>> [root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
>>>>        4246   768526 ACCEPT     udp      ppp0   *       ::/0
>>>>       ::/0                 udp spt:547 dpt:546
>>>>
>>>>
>>>> In `dmesg` komen geen gedropte UDP packets voor die samenhangen met
>>>> dhclient c.q. dhcp-server.
>>>> Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken
>>>> verzenden, niet reageren op antwoorden van de dhcp-server.
>>>
>>> Dit staat er bij mij in:
>>>
>>> -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT
>>>
>>> Geen idee of de src port altijd 547 is.
>>
>> In mijn dtcpdumps wel.
>> Zoniet zou ik e.e.a. ook gelogd zien als geblockt.
>> En dat gebeurt niet.
>>
>> Ik heb dus geen idee of het DHCP verkeer via INPUT en FORWARD bij
>> dhclient aankomt. (logische verklaring: nee)
>> Ook heb ik geen idee waarom het DHCP de FORWARD in gaat of moet.
>> Het adres waar e.e.a. heen moet immers is lokaal.
>> Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209#c7 voor tcpdump
>> met kale IPv6 adressen.
>> Zie ik iets over het hoofd wat de rare FORWARD verklaart?
> 
> Ik gebruik altijd MikroTik routers waar intern Linux draait (iptables)
> en ik heb de rules die hiermee te maken hebben altijd alleen bij INPUT
> staan.  Dat werkt prima.

Nou, dat zou dan een aanwijzing zijn dat de FORWARD inderdaad vreemd is.
Gezien de tcpdump, is er iets op te merken aan de inkomende data 
waardoor deze de FORWARD regel in gaat?

Komt het doordat dhclient luistert op ppp0 waar alleen een link-local 
nummer op zit voor IPv6?


Udo

[toc] | [prev] | [next] | [standalone]

#4229

Udo <udovdh@xs4all> wrote:
> On 29-05-2021 16:29, Rob wrote:
>> Udo <udovdh@xs4all> wrote:
>>> On 17-05-2021 22:14, richard lucassen wrote:
>>>> On Mon, 17 May 2021 10:54:42 +0200
>>>> Udo <udovdh@xs4all> wrote:
>>>>
>>>>>    > Laat poort 546/udp eens toe vanaf fe80::/10
>>>>
>>>>> Dat gebeurt min of meer al:
>>>>>
>>>>> [root@vuurmuur ~]# ip6tables -L -v -n -x|grep 546
>>>>>        4246   768526 ACCEPT     udp      ppp0   *       ::/0
>>>>>       ::/0                 udp spt:547 dpt:546
>>>>>
>>>>>
>>>>> In `dmesg` komen geen gedropte UDP packets voor die samenhangen met
>>>>> dhclient c.q. dhcp-server.
>>>>> Zonder firewall gedraagt dhclient zich identiek: alleen verzoeken
>>>>> verzenden, niet reageren op antwoorden van de dhcp-server.
>>>>
>>>> Dit staat er bij mij in:
>>>>
>>>> -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT
>>>>
>>>> Geen idee of de src port altijd 547 is.
>>>
>>> In mijn dtcpdumps wel.
>>> Zoniet zou ik e.e.a. ook gelogd zien als geblockt.
>>> En dat gebeurt niet.
>>>
>>> Ik heb dus geen idee of het DHCP verkeer via INPUT en FORWARD bij
>>> dhclient aankomt. (logische verklaring: nee)
>>> Ook heb ik geen idee waarom het DHCP de FORWARD in gaat of moet.
>>> Het adres waar e.e.a. heen moet immers is lokaal.
>>> Zie https://bugzilla.redhat.com/show_bug.cgi?id=1956209#c7 voor tcpdump
>>> met kale IPv6 adressen.
>>> Zie ik iets over het hoofd wat de rare FORWARD verklaart?
>> 
>> Ik gebruik altijd MikroTik routers waar intern Linux draait (iptables)
>> en ik heb de rules die hiermee te maken hebben altijd alleen bij INPUT
>> staan.  Dat werkt prima.
>
> Nou, dat zou dan een aanwijzing zijn dat de FORWARD inderdaad vreemd is.
> Gezien de tcpdump, is er iets op te merken aan de inkomende data 
> waardoor deze de FORWARD regel in gaat?
>
> Komt het doordat dhclient luistert op ppp0 waar alleen een link-local 
> nummer op zit voor IPv6?

Dat lijkt me niet, dit verkeer wordt altijd met link-local adressen
afgewikkeld zie ook die firewall rule daarboven.  Ik heb deze rules
er in staan:

/ipv6 firewall filter
add action=accept chain=input comment="Established / Related" \
    connection-state=established,related
add action=drop chain=input log=yes log-prefix=bad_ipv6 src-address-list=\
    bad_ipv6
add action=accept chain=input protocol=icmpv6
add action=accept chain=input comment=DHCPv6-client dst-port=546 \
    in-interface-list=internet protocol=udp src-address=fe80::/10
add action=reject chain=input comment=DHCPv6-server dst-address=ff02::1:2/128 \
    dst-port=547 protocol=udp reject-with=icmp-port-unreachable src-port=546
add action=reject chain=input log=yes log-prefix=default reject-with=\
    icmp-admin-prohibited

Dit is in RouterOS syntac maar de mapping naar iptables is wel duidelijk.

[toc] | [prev] | [next] | [standalone]

#4230

On 30-05-2021 11:15, Rob wrote:
> Udo <udovdh@xs4all> wrote:
>> On 29-05-2021 16:29, Rob wrote:
>>> Udo <udovdh@xs4all> wrote:
>>>> On 17-05-2021 22:14, richard lucassen wrote:
>>>>> On Mon, 17 May 2021 10:54:42 +0200
>>>>> Udo <udovdh@xs4all> wrote:
>>>>>
>> Komt het doordat dhclient luistert op ppp0 waar alleen een link-local
>> nummer op zit voor IPv6?
> 
> Dat lijkt me niet, dit verkeer wordt altijd met link-local adressen
> afgewikkeld zie ook die firewall rule daarboven.  Ik heb deze rules
> er in staan:
> 
> /ipv6 firewall filter
(knip)

> 
> Dit is in RouterOS syntac maar de mapping naar iptables is wel duidelijk.

Helder.
De routering is misschien een ding:

# ip -6 r s
unreachable ::/96 dev lo metric 1024 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 pref medium
(....)
anycast fe80:: dev eth0 proto kernel metric 0 pref medium
fe80::9ecc:83ff:fec6:e7e5 dev ppp0 proto kernel metric 256 pref medium
fe80::c5d5:e942:39c7:7eb7 dev ppp0 proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev ppp0 proto kernel metric 256 pref medium
default dev ppp0 metric 1 pref medium

Uit deze tabel had ik een route 'fe80::/64 dev eth0'  (naar het LAN dus) 
verwijderd.
Toch komt er een 'anycast fe80:: dev eth0' terug.
En die staat /voor/ de routes voor de link-local adressen op ppp0.

Kan dit verklaren dat dhclient geen reactie ziet?
Zoja: hoe zorg ik dat de routes voor fe80:: op eth0 lager in de tabel 
terecht gaan komen of dat de ppp0 link-local routes hoger in de lijst komen?


Udo

[toc] | [prev] | [next] | [standalone]

#4231

Udo <udovdh@xs4all> wrote:
> On 30-05-2021 11:15, Rob wrote:
>> Udo <udovdh@xs4all> wrote:
>>> On 29-05-2021 16:29, Rob wrote:
>>>> Udo <udovdh@xs4all> wrote:
>>>>> On 17-05-2021 22:14, richard lucassen wrote:
>>>>>> On Mon, 17 May 2021 10:54:42 +0200
>>>>>> Udo <udovdh@xs4all> wrote:
>>>>>>
>>> Komt het doordat dhclient luistert op ppp0 waar alleen een link-local
>>> nummer op zit voor IPv6?
>> 
>> Dat lijkt me niet, dit verkeer wordt altijd met link-local adressen
>> afgewikkeld zie ook die firewall rule daarboven.  Ik heb deze rules
>> er in staan:
>> 
>> /ipv6 firewall filter
> (knip)
>
>> 
>> Dit is in RouterOS syntac maar de mapping naar iptables is wel duidelijk.
>
> Helder.
> De routering is misschien een ding:
>
> # ip -6 r s
> unreachable ::/96 dev lo metric 1024 pref medium
> unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 pref medium
> (....)
> anycast fe80:: dev eth0 proto kernel metric 0 pref medium
> fe80::9ecc:83ff:fec6:e7e5 dev ppp0 proto kernel metric 256 pref medium
> fe80::c5d5:e942:39c7:7eb7 dev ppp0 proto kernel metric 256 pref medium
> multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
> multicast ff00::/8 dev ppp0 proto kernel metric 256 pref medium
> default dev ppp0 metric 1 pref medium
>
> Uit deze tabel had ik een route 'fe80::/64 dev eth0'  (naar het LAN dus) 
> verwijderd.
> Toch komt er een 'anycast fe80:: dev eth0' terug.
> En die staat /voor/ de routes voor de link-local adressen op ppp0.
>
> Kan dit verklaren dat dhclient geen reactie ziet?
> Zoja: hoe zorg ik dat de routes voor fe80:: op eth0 lager in de tabel 
> terecht gaan komen of dat de ppp0 link-local routes hoger in de lijst komen?
>
>
> Udo

Je zou kunnen beginnen met "IPv6 privacy extensions" uit te schakelen zodat
je alleen nog dat fe80::9ecc:83ff:fec6:e7e5 adres hebt en niet meer dat
fe80::c5d5:e942:39c7:7eb7 adres.  Beetje raar trouwens dat zelfs voor
link-local die privacy idioterie enabled is.
Hier zit er trouwens op de PPP alleen maar een kennelijk hardcoded adres
fe80::15, niet zo'n automatisch bepaald adres.
Voor een "vast systeem bij je thuis" hebben die privacy extensions geen
enkele zin en maakt het de boel alleen maar onduidelijker.

[toc] | [prev] | [next] | [standalone]

#4232

On 30-05-2021 11:58, Rob wrote:
> Je zou kunnen beginnen met "IPv6 privacy extensions" uit te schakelen zodat
> je alleen nog dat fe80::9ecc:83ff:fec6:e7e5 adres hebt en niet meer dat
> fe80::c5d5:e942:39c7:7eb7 adres.  Beetje raar trouwens dat zelfs voor
> link-local die privacy idioterie enabled is.
> Hier zit er trouwens op de PPP alleen maar een kennelijk hardcoded adres
> fe80::15, niet zo'n automatisch bepaald adres.
> Voor een "vast systeem bij je thuis" hebben die privacy extensions geen
> enkele zin en maakt het de boel alleen maar onduidelijker.

fe80::9ecc:83ff:fec6:e7e5 is van de dhcpv6-server.
Alleen eth0 heeft extra ipv6 maar die adressen zie ik niet terug in de 
tcpdump van de dhcp-conversatie.

Dus waarom stuurt de ip-stack verkeer voor fe80::c5d5:e942:39c7:7eb7 in 
de FORWARD?

# ip -6 r s
unreachable ::/96 dev lo metric 1024 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 pref medium
(....)
fe80::9ecc:83ff:fec6:e7e5 dev ppp0 proto kernel metric 256 pref medium
fe80::c5d5:e942:39c7:7eb7 dev ppp0 metric 900 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev ppp0 proto kernel metric 256 pref medium
default dev ppp0 metric 1 pref medium

Geen fe80 op eth0 verwijzing meer. (na opruimen)
Maar geen verschil als ik naar de dhclient uitvoer kijk.
Ofwel: verkeer komt nog niet aan.

Udo

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | xs4all.ipv6

csiph-web