This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] New V5 Probe with IPv4 Discovery issues
- Previous message (by thread): [atlas] New V5 Probe with IPv4 Discovery issues
- Next message (by thread): [atlas] New V5 Probe with IPv4 Discovery issues
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nate Weibley
nweibley at gmail.com
Wed Nov 30 17:00:01 CET 2022
Michael, Thank you for your troubleshooting guidance. I do not see any evidence of OPNSense blocking the IPv4 traffic originating from the probe; to the contrary I see IPv4 UDP and ICMP traffic passing through the LAN interface via the default allow rule (I have the probe on my main LAN to establish everything is working and will move it to my isolated IOT VLAN once comfortable). Many other IPv4 devices also connected to the LAN network function normally over IPv4. Here's a screenshot of all the probe IPv4 traffic I see, as well as all of the traffic which does not match a pass rule on all non-WAN interfaces in my network: https://imgur.com/a/GCMR9sz Additionally I do not see any recent DNS queries for ip-echo.ripe.net in my DNS resolver logs, though I suspect the probe may be directly querying other resolvers directly for those requests (I do see plenty of other DNS traffic from the probe on my local DNS server though). I was initially suspicious that having DNS64 support enabled in my unbound resolver may be to blame, but since I don't see requests hitting it I'm not confident that is the case. My upstream DNS servers (I run Adguard Home locally for my LAN clients, though the probe has been set to bypass all filter rules) are my local OPNSense unbound instance and DNS-over-TLS to 1.1.1.1 and 8.8.8.8. I will keep poking around to see if I can uncover anything that may be getting blocked or rerouted from the probe. -Nate On Wed, Nov 30, 2022 at 5:18 AM Michel Stam <mstam at ripe.net> wrote: > Hello Nate, > > Sorry to hear you’ve been having problems with the V5 probe. > > It seems that your probe is not able to contact the IP echo service at > ip-echo.ripe.net to derive its IP address. Because of this, IPv4 is > presumed to be non-functional and the probe will not execute IPv4 > measurements. > > Can you take a good look at the OPNSense configuration to see if any v4 > traffic going towards the internet is being filtered? > > Regards, > > Michel > > On 28 Nov 2022, at 16:31, Nate Weibley <nweibley at gmail.com> wrote: > > I received a shiny new V5 probe via post on Saturday and got it up and > running yesterday on my dual-stack network. The probe in question is: > https://atlas.ripe.net/probes/62490/ > > It has been operational for about 18 hours and quickly indicated that IPv6 > connectivity was functional, but it has only momentarily indicated IPv4 > connectivity was established. I can see IPv4 ICMP and UDP traffic > originating from the probe passing through my opnsense router on the IPv4 > WAN interface so I know IPv4 traffic is flowing. I also see the correct > IPv4 DHCP lease info for my LAN on the probe's network status page. > > Probe address discovery does not show a valid IPv4 connection address or > IP Echo Service listed, only the Local IP of my probe. I've tried power > cycling the probe but it doesn't seem to impact this issue. > > Are there any other troubleshooting steps I should try? > -- > ripe-atlas mailing list > ripe-atlas at ripe.net > https://mailman.ripe.net/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas/attachments/20221130/db1de202/attachment.html>
- Previous message (by thread): [atlas] New V5 Probe with IPv4 Discovery issues
- Next message (by thread): [atlas] New V5 Probe with IPv4 Discovery issues
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]