44Net Connect routing

44Net Connect servers, also called points of presence (PoPs) or nodes, are interconnected through an internal mesh. Your Connect tunnel connects to the PoP you selected during setup, but Internet traffic may enter the mesh through another PoP before reaching yours. This can lead to unexpected results in traceroutes and other network tests.

Your tunnel and asymmetric routing

Your tunnel stays attached to its selected PoP even when Internet routes change.

Outbound traffic routed through your tunnel exits onto the Internet through your selected PoP. This includes replies your equipment sends to incoming connections.

Inbound traffic, to your Connect IP address from someone on the Internet, enters through the PoP chosen by other routers on the Internet, and it might not enter through the PoP you selected.

Anycast

44Net Connect uses anycast routing to advertise reachability to Connect addresses from multiple PoPs at the same time. This means that inbound traffic can enter through a different PoP from the one you selected.

If traffic enters through another PoP, it crosses the internal mesh to your selected PoP, then travels down your tunnel to you. If it enters through your selected PoP, no inter-PoP hop is needed.

The entry PoP for inbound traffic can change, even during an existing connection between the same source and destination. Internet routing is dynamic, and the preferred path can change over time.

Even replies to outbound traffic do not necessarily return through the same outbound path. The two directions can take different paths. This is known as asymmetric routing.

Example: your tunnel is in Los Angeles

Suppose your tunnel connects to the Los Angeles (LAX) PoP:

• Someone in Asia might reach you through LAX, then directly down your tunnel. The preferred route from their network to you might be across the Pacific Ocean to LAX, which happens to be where your PoP is located.
• For someone in Europe, the preferred route might cross the Atlantic and enter Connect through a different PoP, like Chicago. Once the traffic enters the internal mesh through Chicago, it travels to LAX, and then down your tunnel.
• Your traffic to either person leaves through LAX. Their traffic to you, including replies, follows their networks’ selected routes into Connect.

These are illustrative paths, not guarantees for particular regions. Even two people in the same city using different ISPs can enter Connect through different PoPs, depending on the backbone they use or the other ISPs they peer with. Someone in Nebraska on “Northern Midwest ISP Inc.” might enter through Chicago, while someone in the same city on “Southern Midwest ISP Inc.” might enter through Dallas.

What determines the entry point?

Connect advertises address ranges through multiple PoPs using Border Gateway Protocol (BGP). An announcement tells neighboring networks, “I can reach this address range,” including addresses attached to other PoPs.

Outside networks choose among the routes available to them according to their routing policies. A provider may prefer a peer over a paid transit connection, or prefer a shorter AS path when other preferences are equal. AS-path length counts networks traversed, not individual router hops. BGP does not ordinarily measure geographic distance, bandwidth, latency, or congestion, although providers can adjust their policies in response to cost or performance.

That’s why the preferred route is not necessarily the shortest geographic path or the one with the lowest latency. Even an ISP near LAX may choose a route through Dallas. Connect influences the available paths through its advertisements, but other networks apply their own policies when choosing among those paths. More specific prefix announcements can also change which PoP receives traffic for a particular address range.

The tunnel route versus the Internet route

There’s one more thing to think about: the path your tunnel takes from your device to the PoP.

When you configure your WireGuard client to connect to a PoP, you specify the public IP address of that PoP. Your client then sends packets to that IP address, and those packets are routed through your local network and your ISP’s network to reach the PoP.

A traceroute sent through the tunnel does not reveal the Internet hops carrying the tunnel itself. Those outer packets follow Internet routing policies too, so they may pass through other cities before reaching your selected PoP. To examine that path, run a traceroute to the PoP’s public WireGuard endpoint address over your ordinary Internet connection, outside the tunnel.

Checking a route

Compare traceroutes to the same Connect destination from different networks, and test the reverse direction where possible. Look at the round-trip times reported for each hop and the destination; each measurement includes the reply path, which may differ from the forward path. Missing traceroute replies do not by themselves indicate lost forwarded traffic, and a public BGP view may not show the internal path between PoPs. Hostnames with abbreviated city names or airport codes can suggest where a hop is located, though those names may be outdated or misleading.

Resources

• bgp.tools: advertised prefixes and observed upstream connectivity.
• RIPEstat: search a Connect IP address or prefix for routing observations from RIPE’s collectors.
• RIPE RIS Looking Glass: BGP routes seen by RIPE’s collectors (API documentation and query examples).
• What is BGP?: an introduction to routing between Internet networks.