<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hello Nate,<div><br></div><div>I’m wondering what will happen if you visit http://ip-echo.ripe.net/ (note http:// not https://). Would you mind doing this?<br><div><br></div><div>I agree that redirecting traffic to your local DNS server is not a viable solution.</div><div><br></div><div>Lastly, do you have the ability to connect the unit to the Internet without a firewall in between, to see if this makes a difference?</div><div><br></div><div>Regards,</div><div><br></div><div>Michel<br><blockquote type="cite"><div>On 30 Nov 2022, at 19:55, Nate Weibley <nweibley@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">Michel,<div><br></div><div>First, my apologies for initially misspelling your name! I went ahead and rebooted the probe while monitoring traffic from it on the LAN and only saw a single active https session originating from the probe to an edgecast CDN endpoint in VA over IPv4: <a href="https://i.imgur.com/xztP6My.png">https://,/xztP6My.png</a> </div><div><br></div><div>I monitored all the DNS queries hitting my server after the reboot and didn't see any come in for <a href="http://ip-echo.ripe.net/">ip-echo.ripe.net</a> either. I could use OPNSense to capture all outbound DNS traffic from the probe and redirect it to my server to see if the probe is trying to resolve that host directly elsewhere, but obviously manipulating the probe's outbound DNS traffic isn't a viable long term solution for it to function properly. The probe was generating plenty of other DNS queries hitting my DNS server during this time though. I also disabled DNS64 as I don't actually have IPv6-only clients inside my network anymore. Unsurprisingly that did not have an effect on the IPv4 issue given I'm not seeing DNS requests for the ip-echo test. The DNS requests made to my DNS server since the probe was reset (all requests after 11:41) can be seen here: <a href="https://i.imgur.com/AlLKeCk.png">https://i.imgur.com/AlLKeCk.png</a></div><div><br></div><div>OPNSense is fully up to date on release 22.7.8. I'm at a bit of a loss as to what is going on as well. Is there a way to pull logs or diagnostics from the probe itself to see what it thinks is going on? </div><div><br></div><div>-Nate</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 30, 2022 at 10:13 AM Michel Stam <<a href="mailto:mstam@ripe.net">mstam@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hello Nate,<div><br></div><div>Can you check that there are active v4 TCP sessions, namely a port 443/TCP session? That should be there for the probe to be able to talk to the infrastructure.</div><div><br></div><div>Depending on the measurement the probe may directly contact name servers, correct, but it may also use your provided name servers.<br><div><br></div><div>I’m not sure how often the echo queries happen, but I expect during initial connect, not continuously. A simple reboot would prove that.</div><div><br></div><div>I don’t see a particular problem in your description as yet, I’ve seen the probes happily running on v4 / v6 dual stack networks (no DNS64 though) without any problems. Not sure what makes it different here, is there maybe a more recent version of OPNSense available</div><div><br></div><div>It’s important that the probe is not restricted from accessing the Internet, because this is the nature of the measurements it does. It will also use old-style DNS, not only DNS over TLS, not sure if this is a problem.</div><div><br></div><div>Keep me posted.</div><div><br></div><div>Cheers,</div><div><br></div><div>Michel</div><div><br></div><div><br></div><div><blockquote type="cite"><div>On 30 Nov 2022, at 17:00, Nate Weibley <<a href="mailto:nweibley@gmail.com" target="_blank">nweibley@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Michael,<div><br></div><div>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. </div><div><br></div><div>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: <a href="https://imgur.com/a/GCMR9sz" target="_blank">https://imgur.com/a/GCMR9sz</a> </div><div><br></div><div>Additionally I do not see any recent DNS queries for <a href="http://ip-echo.ripe.net/" target="_blank">ip-echo.ripe.net</a> 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. </div><div><br></div><div>I will keep poking around to see if I can uncover anything that may be getting blocked or rerouted from the probe.</div><div><br></div><div>-Nate</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 30, 2022 at 5:18 AM Michel Stam <<a href="mailto:mstam@ripe.net" target="_blank">mstam@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hello Nate,<div><br></div><div>Sorry to hear you’ve been having problems with the V5 probe.</div><div><br></div><div>It seems that your probe is not able to contact the IP echo service at <a href="http://ip-echo.ripe.net/" target="_blank">ip-echo.ripe.net</a> to derive its IP address. Because of this, IPv4 is presumed to be non-functional and the probe will not execute IPv4 measurements.</div><div><br></div><div>Can you take a good look at the OPNSense configuration to see if any v4 traffic going towards the internet is being filtered?</div><div><br></div><div>Regards,</div><div><br></div><div>Michel<br><div><br><blockquote type="cite"><div>On 28 Nov 2022, at 16:31, Nate Weibley <<a href="mailto:nweibley@gmail.com" target="_blank">nweibley@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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: <a href="https://atlas.ripe.net/probes/62490/" target="_blank">https://atlas.ripe.net/probes/62490/</a> <div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Are there any other troubleshooting steps I should try?</div></div>
-- <br>ripe-atlas mailing list<br><a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a><br><a href="https://lists.ripe.net/mailman/listinfo/ripe-atlas" target="_blank">https://lists.ripe.net/mailman/listinfo/ripe-atlas</a><br></div></blockquote></div><br></div></div></blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></body></html>