<div dir="ltr"><div class="gmail_default" style="font-size:small">Excellent work Bob.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What is the content of <code>/proc/sys/net/ipv6/conf/all/disable_ipv6 ? <br></code></div><div class="gmail_default" style="font-size:small"><code>0 <br></code></div><div class="gmail_default" style="font-size:small"><code></code>Means ipv6 is disabled. [1]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">You may need to edit your grub to enable it at boot.<br></div><br><div class="gmail_default" style="font-size:small">Running both IPv4 and IPv6 is called "Dual-Stack".</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] <a href="https://serverfault.com/questions/1147296/how-to-enable-ipv6-on-ubuntu-20-04">https://serverfault.com/questions/1147296/how-to-enable-ipv6-on-ubuntu-20-04</a></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Hope this helps,</div><div class="gmail_default" style="font-size:small">Evelyn<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2024 at 2:35 AM Bob Proulx <<a href="mailto:bob@proulx.com" target="_blank">bob@proulx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Evelyn Mitchell wrote:<br>
> The ONT is a fairly stupid device, it translates between optical and<br>
> electric in order to pick up data for your address but is not firewalling.<br>
<br>
The Nokia "WiFi Gateway 3" is both an ONT and a firewall router. It<br>
contains a NAT router for IPv4 and a firewall for IPv6. The default<br>
is that IPv4 is configured to NAT and the IPv6 firewall is configured<br>
"Low" which is a good default. It allows outgoing connections but<br>
drops incoming connections. Which is a good default configuration.<br>
<br>
This must be turned to Off is one wants incoming connections. I<br>
turned it off.<br>
<br>
> If you have a router or firewall on your internal network that may be the<br>
> issue.<br>
<br>
The devices under test connect directly to the Nokia's 4-port on-board<br>
switch. There is nothing between my test systems and the Nokia.<br>
<br>
> How are you testing that the 2605:b40:1516:a200:8433:8e2d:2bad:e833/64 is<br>
> reachable?<br>
<br>
I start with ping because of course everything starts with ping. Then<br>
I also test TCP with netcat. I have mostly been ignoring UDP. Here<br>
"queasy" is my Ubuntu 24.04 test system connected directly to the<br>
Nokia.<br>
<br>
root@queasy:~# ping -c3 rainy<br>
PING rainy (2600:3c00::f03c:91ff:fe18:62e4) 56 data bytes<br>
From 2605:b40:1516:a200::1 icmp_seq=1 Destination unreachable: Source address failed ingress/egress policy<br>
From 2605:b40:1516:a200::1 icmp_seq=2 Destination unreachable: Source address failed ingress/egress policy<br>
From 2605:b40:1516:a200::1 icmp_seq=3 Destination unreachable: Source address failed ingress/egress policy<br>
<br>
--- rainy ping statistics ---<br>
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2032ms<br>
<br>
And then a TCP probe using netcat. Which fails. It will eventually<br>
time out after a long time. If it works then the ssh banner is<br>
displayed immiedately. Here I am using Control-C after it is obvious<br>
that it is not connecting.<br>
<br>
root@queasy:~# nc -6 rainy 22<br>
root@queasy:~# echo $?<br>
1<br>
<br>
I also reverse and probe back from rainy which is a Linode system.<br>
Linode has always had excellent IPv6 operation.<br>
<br>
root@rainy:~# ping -c3 2605:b40:13a3:8c00:b978:210b:51bd:e23f<br>
PING 2605:b40:13a3:8c00:b978:210b:51bd:e23f(2605:b40:13a3:8c00:b978:210b:51bd:e23f) 56 data bytes<br>
From 2605:b40:3003:1::2 icmp_seq=1 Destination unreachable: Address unreachable<br>
From 2605:b40:3003:1::2 icmp_seq=2 Destination unreachable: Address unreachable<br>
From 2605:b40:3003:1::2 icmp_seq=3 Destination unreachable: Address unreachable<br>
<br>
--- 2605:b40:13a3:8c00:b978:210b:51bd:e23f ping statistics ---<br>
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2003ms<br>
<br>
> Are you using ping6 and traceroute6?<br>
<br>
The old ping6 functional has been incorporated into the standard ping<br>
binary and the use of the ping6 name for it has been deprecated. And<br>
the same with traceroute6 too. But they are symlinked for backward<br>
compatibility for at least a little while longer.<br>
<br>
root@queasy:~# ll /usr/bin/ping6<br>
lrwxrwxrwx 1 root root 4 Apr 8 2024 /usr/bin/ping6 -> ping*<br>
<br>
root@queasy:~# update-alternatives --display traceroute6<br>
traceroute6 - auto mode<br>
link best version is /usr/bin/traceroute6.db<br>
link currently points to /usr/bin/traceroute6.db<br>
link traceroute6 is /usr/bin/traceroute6<br>
slave traceroute6.1.gz is /usr/share/man/man1/traceroute6.1.gz<br>
/usr/bin/traceroute6.db - priority 100<br>
slave traceroute6.1.gz: /usr/share/man/man1/traceroute6.db.1.gz<br>
<br>
root@queasy:~# ll /usr/bin/traceroute6.db<br>
lrwxrwxrwx 1 root root 13 Dec 25 2023 /usr/bin/traceroute6.db -> traceroute.db*<br>
<br>
So I just use the standard ping and traceroute now.<br>
<br>
> Is your router between the ONT and that server passing IPV6 traffic?<br>
<br>
There is no router between the devices under test and the Nokia. They<br>
are directly connected to the Nokia ONT router. One of the devices is<br>
actually my house router. But the other two are directly connected<br>
so I can test using them.<br>
<br>
> Is your firewall configured to pass IPV6 for that range?<br>
<br>
There is no firewall between. My three systems (so far three) are<br>
connected directly into the Nokia.<br>
<br>
> You can test from "outside" with one of the online Looking glass servers.<br>
<br>
I can test from outside using Linode, Digital Ocean, Amazon EC2, other<br>
systems on Hurricane Electric's network. Lots of possible test<br>
systems!<br>
<br>
I can also log into George's system also on Connexion. And then I can<br>
probe _across the local network_ as it were. This actually provides<br>
different results. A useful additional test case.<br>
<br>
So here is an example of just weirdness.<br>
<br>
root@queasy:~# ip -6 addr show eth0<br>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000<br>
altname enp1s0<br>
inet6 2605:b40:13a3:8c00:b978:210b:51bd:e23f/64 scope global temporary dynamic<br>
valid_lft 43009sec preferred_lft 34100sec<br>
inet6 2605:b40:1516:a200:87db:ba30:b265:3c86/64 scope global temporary dynamic<br>
valid_lft 42888sec preferred_lft 34100sec<br>
inet6 2605:b40:1516:a200:928d:8523:a296:f80b/64 scope global temporary deprecated dynamic<br>
valid_lft 42888sec preferred_lft 0sec<br>
inet6 2605:b40:1516:a200:37cb:35cf:cdec:71fe/64 scope global dynamic mngtmpaddr noprefixroute<br>
valid_lft 42888sec preferred_lft 42888sec<br>
inet6 2605:b40:13a3:8c00:fde7:1fca:2876:5419/64 scope global temporary deprecated dynamic<br>
valid_lft 43009sec preferred_lft 0sec<br>
inet6 2605:b40:13a3:8c00:6f33:ffb3:f4f6:9c7b/64 scope global dynamic mngtmpaddr noprefixroute<br>
valid_lft 43009sec preferred_lft 43009sec<br>
inet6 fe80::4425:2931:5fcd:845/64 scope link noprefixroute<br>
valid_lft forever preferred_lft forever<br>
<br>
The system has SIX addresses. The address bound by default unless<br>
overridden is 2605:b40:13a3:8c00:b978:210b:51bd:e23f. Let's ping a<br>
Linode system. It's in the cloud and "rainy" is one of my cloud<br>
systems.<br>
<br>
root@queasy:~# ping -c3 rainy<br>
PING rainy (2600:3c00::f03c:91ff:fe18:62e4) 56 data bytes<br>
From 2605:b40:1516:a200::1 icmp_seq=1 Destination unreachable: Source address failed ingress/egress policy<br>
From 2605:b40:1516:a200::1 icmp_seq=2 Destination unreachable: Source address failed ingress/egress policy<br>
From 2605:b40:1516:a200::1 icmp_seq=3 Destination unreachable: Source address failed ingress/egress policy<br>
<br>
--- rainy ping statistics ---<br>
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2061ms<br>
<br>
Such an interesting error message! "Source address failed<br>
ingress/egress policy". Hmm... But if I test all of the addresses<br>
binding to each of them in turn eventually I will locate a working<br>
one.<br>
<br>
root@queasy:~# ping -I 2605:b40:1516:a200:87db:ba30:b265:3c86 -c3 rainy<br>
PING rainy (2600:3c00::f03c:91ff:fe18:62e4) from 2605:b40:1516:a200:87db:ba30:b265:3c86 : 56 data bytes<br>
64 bytes from <a href="http://rainy.proulx.com" rel="noreferrer" target="_blank">rainy.proulx.com</a> (2600:3c00::f03c:91ff:fe18:62e4): icmp_seq=1 ttl=54 time=24.9 ms<br>
64 bytes from <a href="http://rainy.proulx.com" rel="noreferrer" target="_blank">rainy.proulx.com</a> (2600:3c00::f03c:91ff:fe18:62e4): icmp_seq=2 ttl=54 time=26.2 ms<br>
64 bytes from <a href="http://rainy.proulx.com" rel="noreferrer" target="_blank">rainy.proulx.com</a> (2600:3c00::f03c:91ff:fe18:62e4): icmp_seq=3 ttl=54 time=24.9 ms<br>
<br>
--- rainy ping statistics ---<br>
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br>
rtt min/avg/max/mdev = 24.890/25.330/26.171/0.594 ms<br>
<br>
And my Linode can ping it.<br>
<br>
root@rainy:~# ping -c3 2605:b40:1516:a200:87db:ba30:b265:3c86<br>
PING 2605:b40:1516:a200:87db:ba30:b265:3c86(2605:b40:1516:a200:87db:ba30:b265:3c86) 56 data bytes<br>
64 bytes from 2605:b40:1516:a200:87db:ba30:b265:3c86: icmp_seq=1 ttl=54 time=24.4 ms<br>
64 bytes from 2605:b40:1516:a200:87db:ba30:b265:3c86: icmp_seq=2 ttl=54 time=27.5 ms<br>
64 bytes from 2605:b40:1516:a200:87db:ba30:b265:3c86: icmp_seq=3 ttl=54 time=25.5 ms<br>
<br>
--- 2605:b40:1516:a200:87db:ba30:b265:3c86 ping statistics ---<br>
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br>
rtt min/avg/max/mdev = 24.429/25.795/27.465/1.257 ms<br>
<br>
Okay. So 2605:b40:1516:a200:87db:ba30:b265:3c86 is the working<br>
address. The others are all non-working. Too bad that one is an<br>
additional IP alias and not the first default one.<br>
<br>
But strangely it is only working from foreign networks. If I log into<br>
George's system also on Connection and try to ping back then it fails.<br>
<br>
root@yukiko# ping -c3 2605:b40:1516:a200:87db:ba30:b265:3c86<br>
PING 2605:b40:1516:a200:87db:ba30:b265:3c86(2605:b40:1516:a200:87db:ba30:b265:3c86) 56 data bytes<br>
<br>
--- 2605:b40:1516:a200:87db:ba30:b265:3c86 ping statistics ---<br>
3 packets transmitted, 0 received, 100% packet loss, time 2056ms<br>
<br>
Going across the local network is blocked. Not working.<br>
<br>
But all of this ping testing is just icmp6 packets. Does TCP work?<br>
Nope! TCP is not functional even though icmp6 is functional.<br>
<br>
root@queasy:~# nc -6 rainy 22<br>
root@queasy:~# echo $?<br>
1<br>
<br>
Even binding to the address "working" for ping does not work for TCP.<br>
<br>
root@queasy:~# nc -6 -s 2605:b40:1516:a200:87db:ba30:b265:3c86 rainy 22<br>
^C<br>
<br>
Does inbound work? No. Does not work. Which is not surprising since<br>
outbound is not working.<br>
<br>
root@rainy:~# nc 2605:b40:1516:a200:87db:ba30:b265:3c86 22<br>
^C<br>
<br>
root@rainy:~# nmap -6 -F 2605:b40:1516:a200:87db:ba30:b265:3c86<br>
Starting Nmap 7.93 ( <a href="https://nmap.org" rel="noreferrer" target="_blank">https://nmap.org</a> ) at 2024-11-14 02:07 MST<br>
Nmap scan report for 2605:b40:1516:a200:87db:ba30:b265:3c86<br>
Host is up (0.026s latency).<br>
All 100 scanned ports on 2605:b40:1516:a200:87db:ba30:b265:3c86 are in ignored states.<br>
Not shown: 100 filtered tcp ports (no-response)<br>
<br>
Nmap done: 1 IP address (1 host up) scanned in 3.99 seconds<br>
<br>
Meanwhile I have actually seen this work before. I think if I reboot<br>
my Nokia that it will work _for a while_ and then stop working. As if<br>
it has auto-reset the firewall back on again.<br>
<br>
Meanwhile IPv4 works perfectly and is very fast and reliable. You<br>
would never notice that IPv6 is not working unless specifically<br>
looking for it.<br>
<br>
Strange stuff!<br>
<br>
Bob<br>
<br>
P.S. A lot of people switch their Nokia into bridging mode in order to<br>
remove the entire routing and firewall of the Nokia firmware from the<br>
configuration. I am sure that given enough discussion here that<br>
someone will say that's what they did and suggest I do the same.<br>
Using bridge mode then they are _directly on the net_ through the<br>
bridge and the router part of the Nokia is removed from the<br>
configuration.<br>
<br>
I might eventually get to the point where I decide to do that. But<br>
for various reasons I prefer the routed mode configuration. For one<br>
it keeps open the possibility of someone plugging a MS-Windows laptop<br>
into the Nokia directly and it would still be safe using the Nokia's<br>
built in firewall. Because no one would want to put a Windows system<br>
naked directly on the hostile Internet. It would become compromised<br>
with moments!<br>
<br>
And routed mode /should/ be working. We know it can work. While<br>
traveling around with my laptop I have connected to many networks. A<br>
very, very few of them have IPv6 fully working. I always look.<br>
Sometimes I am pleasantly surprised. I know it can work. It's just<br>
not working here for me.<br>
<br>
And I am just cantankerous enough to want to continue poking at the<br>
problem somewhat longer before giving up on it and testing out bridge<br>
mode. Hoping to learn something in the process of this investigation.<br>
</blockquote></div>