RTFM · Networking
Troubleshooting from LAN to Internet
Test one boundary at a time: service, host firewall, LAN route, router/provider edge, DNS, and the remote network. This page is the hub; each deep-dive lives on its own chapter below.
Works on LAN but not Internet
- Confirm the service listens on the expected address with ss -lntup.
- Confirm nftables permits the port on the correct interface and address family.
- Confirm the router rule points to the current reserved LAN address.
- Confirm the router WAN address is genuinely public and not CGNAT.
- Confirm the provider firewall and ISP do not block the port.
- Test from a phone hotspot or remote host, not only through the same router.
IPv6 failures
Check ip -6 addr and ip -6 route. If there is no default route, inspect RA. If a prefix exists but expires, inspect PD lifetimes and renewal. If clients have addresses but cannot connect, inspect IPv6 firewall policy, ICMPv6, DNS AAAA answers, and whether the service binds IPv6.
ip -6 addr
ip -6 route
dig A example.com
dig AAAA example.com
sudo tcpdump -ni eth0 icmp6
sudo nft list rulesetVPN failures
A handshake proves cryptography, not routing. Compare ip route and ip -6 route on both sides, confirm forwarding and return routes, inspect the VPN interface with ss and tcpdump, and test MTU with tracepath. Check that VPN and LAN prefixes do not overlap and that DNS names resolve to addresses reachable through the VPN.
DNS and mail failures
Use dig from an external resolver or remote host to inspect MX, A, AAAA, PTR, SPF, DKIM, and DMARC. Confirm FCrDNS for the actual public sending IP. If HAProxy is involved, identify the public IP used for outbound mail; the backend's private address is irrelevant to PTR.
dig +short MX example.com
dig +short A mail.example.com
dig +short AAAA mail.example.com
dig -x 203.0.113.25 +short
dig +short TXT example.com
dig +short TXT _dmarc.example.comKeep a change record
Write down the old and new address, route, firewall, router, DNS, and VPN changes. Record what was tested from inside and outside. Networking failures often come from two individually reasonable changes that disagree about the destination.
Use a repeatable packet walk
When someone reports a failure, write one concrete test sentence: 'from this source address, connect to this destination name/address, on this family and port, and expect this protocol result.' Walk that packet from the source to the service. This replaces a vague 'the network is down' report with evidence that a colleague can reproduce.
1. Resolve the name
Use dig A and dig AAAA. Choose the address family deliberately; a broken AAAA can make an IPv6-capable client fail while IPv4 appears fine.
2. Check source route
Use ip route get or ip -6 route get on the source. A VPN or multiple default routes may select a different interface than expected.
3. Observe arrival
Run tcpdump on the receiving WAN/VPN/LAN interface while one test occurs. No packet means investigate an earlier provider, router, DNS, or route boundary.
4. Observe decision and listener
Inspect nftables counters and ss. A packet that arrives but is not accepted is a host-policy/listener issue.
5. Check return path
On the server or gateway, use ip route get back to the source. Asymmetric replies are common behind multiple routers, VPNs, NAT, and policy routing.
# Source side
dig A app.example.test +short
dig AAAA app.example.test +short
ip route get 203.0.113.25
ip -6 route get 2001:db8:100::25
tracepath app.example.test
# Edge/server side during one test.
tcpdump -ni internet0 'host 198.51.100.44 and tcp port 443'
nft -a list chain inet filter input
ss -lntp '( sport = :443 )'
ip route get 198.51.100.44Recognise the common failure signatures
| What you see | Often means | Check next |
|---|---|---|
| Connection refused immediately | A host replied, but nothing accepted that port or a firewall actively rejected it. | ss listener ownership and nftables reject rule. |
| Connection times out | A packet was dropped or never arrived; it can be provider, router, route, firewall, or return path. | tcpdump at every expected boundary, then counters. |
| Works by IPv4 but not IPv6 | AAAA/DNS, IPv6 route/RA/PD, or IPv6 firewall differs. | dig AAAA, ip -6 route, listener on [::], IPv6 policy. |
| VPN handshake but no remote LAN access | Encryption works; routing, forwarding, return path, AllowedIPs, or firewall does not. | ip route, ip -6 route, nft forward chain, tcpdump wg0 and LAN. |
| Small transfers work; larger ones stall | An MTU/MSS issue through PPPoE/tunnel/encapsulation is likely. | tracepath, packet capture of SYN MSS, route-MTU clamp. |
| Public site works on LAN only | Hairpin/NAT loopback or split-DNS behaviour can differ from the Internet. | Repeat test from an independent network. |
Prove it works: A network incident is recovered
The intended connection works from its documented source and address family, a deliberately forbidden connection is still denied, route/firewall/DNS evidence was recorded, and the change record explains what was altered and how to roll it back.
Deep-dive chapters
Did we miss something?
If this page left something unanswered, found an error, or there is another subject you would like documented, tell us. Saphira’s documentation grows from real problems people need to solve.
Send feedback or request a new section →
Prefer not to do it yourself?
Everything needed to do the work yourself is documented here and remains free — we charge for human time, not for withholding knowledge. Sometimes the missing resource is simply time. The same people who build Saphira can provide paid professional help with implementation, migration, troubleshooting and administration.