Tuesday November 12th, 2024 NCLUG Meeting
Evelyn Mitchell
efmphone at gmail.com
Fri Nov 15 23:39:43 UTC 2024
Excellent work Bob.
What is the content of /proc/sys/net/ipv6/conf/all/disable_ipv6 ?
0
Means ipv6 is disabled. [1]
You may need to edit your grub to enable it at boot.
Running both IPv4 and IPv6 is called "Dual-Stack".
[1]
https://serverfault.com/questions/1147296/how-to-enable-ipv6-on-ubuntu-20-04
Hope this helps,
Evelyn
On Thu, Nov 14, 2024 at 2:35 AM Bob Proulx <bob at proulx.com> wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20241115/edbc62ca/attachment-0001.htm>
More information about the NCLUG
mailing list