Notes from Phil Karn KA9Q on 44Net Connect
This page summarzes observations on 44Net Connect from Phil Karn KA9Q posted to the mailing list in April 2026. The full thread, including discussion and examples is available at groups.io: Phil Karn KA9Q, Notes on 44Net Connect.
Many of the comments are in regard to settings that appear in the suggested configuration for Wireguard generated by the Connect dashboard.
Summary
Routing: avoid sending everything through the tunnel
In most cases, routing all outbound traffic through the tunnel adds latency and unnecessary load on ARDC PoPs.
A common pattern is to route only traffic that originates from the assigned 44Net address through the tunnel, while leaving ordinary outbound traffic on the local network path (out through your regular Internet connection, for example).
Some applications (IRLP, AllStar, etc.) may work better or be more convenient with full-tunnel behavior. In those cases, routing all traffic through the tunnel can be appropriate.
Use policy-based routing to send only 44Net traffic over the tunnel
WireGuard’s default behavior is to modify routing automatically. Disabling this and using policy routing opens up more options for control.
To send only 44Net traffic over the tunnel:
- Disable automatic route management in Wireguard (
Table = off) - Create a separate routing table for 44Net traffic in your router
- Add a rule that selects 44Net traffic and directs it to the new routing table
The procedures for this vary by system. Phil explains some examples for Debian in the discussion thread.
MTU: 1380 is very conservative
The MTU value of 1380 in the suggested configuration is conservative and likely lower than needed. A higher MTU like 1420 is likely more appropriate, but this depends on the specific network path and devices between the operator and the Connect endpoint.
DNS: avoid unintended resolver changes
The suggested configuration replaces system DNS settings and can interfere with local name resolution (for example, home routers or local dnsmasq setups).
The suggested configuration uses Cloudflare's 1.1.1.1 DNS server to help ensure that DNS queries can be resolved when all traffic is directed over the tunnel. If only 44Net traffic is routed through the tunnel, it is almost certainly not necessary to do this. If you are using a local DNS server, you will want to remove the DNS line from the WireGuard configuration to avoid breaking local name resolution.
Security: assume immediate exposure
A 44Net address is globally reachable. When you bring up an interface with a 44Net address, the whole Internet can see your interface and attempt to connect to it.
Steps to secure the system should be taken before bringing up the tunnel. Depending on your use case, these might include:
- Disabling password-based SSH authentication in favor of public key authentication
- Filtering inbound traffic as appropriate (for example, using a firewall to block all inbound traffic except SSH if you need remote access)
- Disabling unnecessary services
Obfuscation measures like changing SSH ports can reduce log noise, but changing a service port does not replace robust security measures.
Engineering is skilled compromise
The suggestions here are valid in many use cases, but there are also valid reasons to deviate from them.
There is no single “correct” configuration. Even “best” depends on the use case and priorities of the operator.
The full discussion
The original thread, including specific examples and detailed explanations, is available on groups.io: