Tuesday November 12th, 2024 NCLUG Meeting
Evelyn Mitchell
efmphone at gmail.com
Fri Nov 15 23:42:28 UTC 2024
Sorry, 0 means enabled.
On Fri, Nov 15, 2024 at 4:39 PM Evelyn Mitchell <efmphone at gmail.com> wrote:
> 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/9e04875e/attachment-0001.htm>
More information about the NCLUG
mailing list