Routing: Difference between revisions
mw push |
mw push |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:Routing}} | {{DISPLAYTITLE:Routing}} | ||
Routing determines where packets go next. A working 44Net connection needs a path to your address and a return path for replies. An address assignment or DNS record alone does not establish those paths. | |||
== | == How traffic reaches you == | ||
{| class="wikitable" | |||
! Connection method !! Traffic path | |||
|- | |||
| [[44Net Connect]] || A Connect node carries traffic through a WireGuard tunnel to your device or gateway. | |||
|- | |||
| [[IPIP Mesh]] || Participating gateways exchange traffic through IPIP tunnels. A shared Internet gateway handles traffic between the mesh and the wider Internet. | |||
|- | |||
| [[BGP]] || Your provider or your own network announces your prefix. The provider delivers traffic over the connection you arrange. | |||
|} | |||
Use [[Provisioning Methods]] to choose a connection method. | |||
== | == One device or a local network == | ||
With a [[44Net Connect/Single Device Tunnel|single-device tunnel]], the 44Net address belongs to the device running WireGuard. That device controls its routes and firewall. | |||
With a [[44Net Connect/Routed Subnet|routed subnet]], the tunnel ends at a gateway. The gateway forwards traffic to local devices, which need addresses and return routes through it. Those devices do not need their own tunnels. | |||
== | Whether other Internet traffic also uses the tunnel depends on the configuration. In a split-tunnel setup, some traffic keeps using the ordinary Internet connection. See [[44Net Connect/Ways to Connect|Ways to deploy Connect]] for the traffic behavior of each model. | ||
== Finding a broken path == | |||
Check each part of the path before changing configuration: | |||
# '''Connection:''' Is the underlying Internet connection working? For Connect, is there a recent WireGuard handshake? For BGP, is the expected prefix visible outside your network? | |||
# '''Routes:''' Does traffic reach the tunnel or provider connection? For a routed subnet, can the gateway forward to the destination, and can that device send replies back through it? | |||
# '''Service and firewall:''' Is the service listening on the intended address and port? Do both the gateway and host firewalls allow it? See [[Firewalling Basics]]. | |||
# '''Naming:''' If access by address works but access by name fails, check the [[DNS/Portal/Records|DNS record]]. | |||
# '''Packet size:''' If small packets work but transfers stall, check [[MTU and MSS]]. | |||
Test both inbound and outbound traffic. A successful outbound connection does not establish that a new inbound connection is permitted. When asking for [[Get Help|help]], include the source and destination addresses, the expected path, and the step that fails. | |||
[[Category:Explanation]] | |||
[[Category:Infrastructure]] | |||
[[Category:Routing]] | |||
Latest revision as of 22:28, 28 September 2026
Routing determines where packets go next. A working 44Net connection needs a path to your address and a return path for replies. An address assignment or DNS record alone does not establish those paths.
How traffic reaches you
| Connection method | Traffic path |
|---|---|
| 44Net Connect | A Connect node carries traffic through a WireGuard tunnel to your device or gateway. |
| IPIP Mesh | Participating gateways exchange traffic through IPIP tunnels. A shared Internet gateway handles traffic between the mesh and the wider Internet. |
| BGP | Your provider or your own network announces your prefix. The provider delivers traffic over the connection you arrange. |
Use Provisioning Methods to choose a connection method.
One device or a local network
With a single-device tunnel, the 44Net address belongs to the device running WireGuard. That device controls its routes and firewall.
With a routed subnet, the tunnel ends at a gateway. The gateway forwards traffic to local devices, which need addresses and return routes through it. Those devices do not need their own tunnels.
Whether other Internet traffic also uses the tunnel depends on the configuration. In a split-tunnel setup, some traffic keeps using the ordinary Internet connection. See Ways to deploy Connect for the traffic behavior of each model.
Finding a broken path
Check each part of the path before changing configuration:
- Connection: Is the underlying Internet connection working? For Connect, is there a recent WireGuard handshake? For BGP, is the expected prefix visible outside your network?
- Routes: Does traffic reach the tunnel or provider connection? For a routed subnet, can the gateway forward to the destination, and can that device send replies back through it?
- Service and firewall: Is the service listening on the intended address and port? Do both the gateway and host firewalls allow it? See Firewalling Basics.
- Naming: If access by address works but access by name fails, check the DNS record.
- Packet size: If small packets work but transfers stall, check MTU and MSS.
Test both inbound and outbound traffic. A successful outbound connection does not establish that a new inbound connection is permitted. When asking for help, include the source and destination addresses, the expected path, and the step that fails.