The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S).
Some questions:
What exactly does it mean by "this in itself is not enough to do measurements"?
"you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S)" means that I should allow this kind of inbound traffic?
My main point is that I expect to measure latency of traffic initiated on my fixed IP address. So I expect that I could create a user-defined measurement where the probe I host would initiate traffic against a defined IP address. But then… what does it mean adding probes to that measurement? How do they come into play in this specific measurement?
In other words, I expect to perform what the docs say:
You can take advantage of the entire RIPE Atlas network to perform measurements about your own network(s).
How exactly do I perform measurements about my own network?
For a probe to effectively perform measurements, it needs unrestricted access to the internet. (Or at least the best you can get it.) That means not behind a firewall that will mess with the traffic. Just because it can get as address (DHCP, SLAAC), resolve names, and connect to a controller, does not mean it will be able to perform measurements. It must be able to ping (ICMP), traceroute (UDP+ICMP), and connect to various services (UDP/TCP, on various ports.) While most measures will originate from a probe, probes are often targets as well. (eg. select a pool of probes from AS#A to ping/trace to a pool from AS#B.)
There are numerous documents (and videos) on how to setup measurements. The short version: select probes outside your network to target your probe, and/or servers. (and v.v.)
As the probes themselves run no services, ping and traceroute would be the only things that would work. There’s no documented requirement that it work, but people DO use probes as measurement targets - because they’re known things within interesting networks. So it’s good for them to be reachable – or at least appear to be, behind NAT it’s the router/firewall actually answering. In my case, v4 is behind NAT, so you’d be targeting the router; v6, however, is GUA, so you’d be targeting the actual probe.
Having a firewall in front of a probe can interfere with measurements. The added latency is minimal (if measurable at all), but the FW suddenly deciding what the probe is doing is “bad” and blocking it would be problematic. If I could put the probe beyond the firewall, outside the “internal” networks, I would. (and have.)
