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.
Control routing explicitly
WireGuard’s default behavior is to modify routing automatically, and the suggested configuration reflects this. Disabling this and using policy routing opens up more options for control.
Scoping the tunnel to the traffic that actually needs the tunnel entails:
- disabling automatic route management (
Table = off) - creating a separate routing table for 44Net traffic
- adding a rule that selects that table based on source address
The procedures for this vary by system. Phil explains some examples for Debian in the discussion thread.
MTU: default is extremely conservative
The MTU values in the suggested configuration are conservative and likely lower than needed. A higher MTU like 1420 is likely more appropriate.
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).
Using the suggested 1.1.1.1 (Cloudflare) DNS server ensures that DNS queries can be resolved by default when all traffic is directed over the tunnel, but if the tunnel is scoped to only 44Net traffic, it is likely preferable not to specify a DNS server on the tunnel and thereby use the existing system DNS configuration instead.
Security: assume immediate exposure
A 44Net address is globally reachable. Services become visible to the public Internet almost immediately.
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
- using public key authentication
- filtering inbound traffic to only the services you intend to expose
- disabling unnecessary services
Obfuscation measures like changing SSH ports can reduce log noise, but do 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: