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