Probe 61817 currently shows as connected from the 2600:4800::/28 network, and it shows the IPv6 network as ASN 6128.
While the probe was briefly connecting through that it’s connected via 2600:4000::/24 (ASN 701) for the past ~2 days (and most of the time before).
The “IPv6 Current Configuration” also properly shows an address in 2600:4000::/24 and nothing in 2600:4800::/28.
IP echo address and local IP are again using the correct address.
The IP4 address is currently correctly shown from ASN 701, but I noticed a few days back that is was showing a wrong address from that ASN that had changed a few days earlier.
So something seems to be off with the IP reporting on the status pages.
Hello, is there some kind of v6 NAT in place? Seemingly the UI shows the probe’s local IP there. The connection history indeed has entries showing flaps between the two networks.
Note: I believe the upcoming new (beta) user interface shows the IP what you describe as the correct one, please check it out.
(I apologise for not posting a direct link here, I don’t want the link to be on permanent record since it’s supposed to be temporary 
I’ll send you mail instead.)
No, there is no v6 NAT involved. The new status page shows the exact same information as the old one for me (i.e., connection via ASN 6128). They both correctly show the ASN 701 address as the IP echo service address.
For context: I have a HA setup with two routers to two different ISPs, so that is why the probe will occasionally connect via ASN 6128. The last time there was a failover was Tue Feb 11 07:22:05 PM EST 2025, but that was brief and I think did not show up as a disconnect for the probe (i.e., I think it fell into the gap between two status updates by the probe). But that means the probe might still have the ASN 6128 address within the valid lifetime (but not as preferred).
I have confirmed via tcpdump on the external interfaces that there is no relevant traffic via the router connected to ASN 6128. All traffic (probes and the ssh over port 443 based status updates) go out via ASN 701.
The only thing I do see on the ASN 6128 connection are incoming syncs on various ports from a “shadowserver.org” server, but they are dropped by the firewall.
What’s visible in your connection logs is that your probe flapped between connecting from 2600:480a::/32 and 2600:4041::/32 four times in the last 1,5 months or so. Seemingly the discovered address/ASN always matches one of these. Since you explain you have a HA setup so I’d attribute the behaviour to this - and perhaps that there’s some delay in us adjusting these values over time.
Thanks for the explanation.
I have some suspicion the recorded connection address can be off. For this probe this is the connection log for the past few weeks:
| 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-06 09:39:24 |
13d 7h 3m |
Still Connected |
|
| 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-06 09:08:51 |
0h 28m |
2025-02-06 09:36:51 |
0h 2m |
| 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-05 13:52:15 |
18h 58m |
2025-02-06 08:50:46 |
0h 18m |
| 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-02 22:59:28 |
2d 14h 52m |
2025-02-05 13:52:12 |
0h 0m |
| 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-02 22:47:14 |
0h 9m |
2025-02-02 22:56:19 |
0h 3m |
| 2600:4041:5c6f:388c:da58:d7ff:fe03:1dc |
ctr-dub-hw02 |
2025-02-02 17:13:38 |
5h 33m |
2025-02-02 22:47:10 |
0h 0m |
All connections since 2025-02-02 22:59:28 have been made from 2600:4041:5c6f:388c:da58:d7ff:fe03:1dc, not 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc. So it seems you are recording the wrong address for the connection. Only the one connection at 2025-02-02 22:47:14 falls into a window where the backup connection was active.
If this is what is actually recorded in your DB then it would make sense with what the various tools are showing (i.e, 2600:480a:8935:9c8c:da58:d7ff:fe03:1dc showing up as the current connection address would then be consistent with these wrong connection logs).
