legitdns.
FeaturesUse casesDocsSign inGet started

Reaching your device from outside

Your hostname points at your home's public address. That is only the first piece. For a connection from outside to actually reach the device, three more things have to line up:

  1. A service listening on the device. The program you want to reach (a web page, a game server, SSH) must be running. Test from inside your home network first: if you cannot reach it from another room, the internet cannot either.
  2. A port forward on the router. Your router has to be told: connections arriving on this port go to this device. Give the device a fixed local address first (a DHCP reservation in the router), or the forward points at the wrong box after a reboot. Forward only the ports the service needs.
  3. A public address for the connection to arrive at. This is the piece that fails silently - see the test below.

The test: is your address really public?

Compare two numbers:

  • The WAN (internet) address on your router's status page.
  • What our /checkip reports from a device at home, asked over IPv4 (the -4 in the command):
curl -4 https://legitdns.com/checkip

If they match, your router holds the public address, and a port forward can work. If they differ, something between your router and the internet is also translating addresses: a second router, or your provider. The sections below cover each case.

A WAN address in the range 100.64.0.0 to 100.127.255.255 is a shared provider address (see CGNAT below), never a public one.

Double NAT: two routers at home

If the provider's box is itself a router and your own router sits behind it, there are two layers of translation. A forward on your router alone is not enough - the outside connection stops at the first box.

Fixes, best first:

  • Put the provider's box in bridge mode, so your router holds the public address and one forward does the whole job.
  • Or set the same port forward on both boxes: the first forwards to your router, your router forwards to the device.

CGNAT: the provider's shared address

Providers are out of IPv4 addresses, so many put whole streets of customers behind a few public ones. This is common on mobile broadband, satellite, and newer fibre plans. The address /checkip shows belongs to the provider's equipment and is shared with other customers.

Connections from outside stop at the provider's equipment. They never reach your router, and no DDNS entry, port forward, or router setting can change that: your router has no public address to forward from. If the test above shows a mismatch and there is no second router in your home, this is almost certainly your situation.

What does work:

  • Ask your provider for a public address. Many hand one out free on request; some charge a small monthly fee or want you on a different plan. Say you need inbound connections for remote access.
  • Use IPv6. If your provider gives your connection a reachable IPv6 prefix, each device can hold its own public IPv6 address - no translation in the way. Our updaters publish the IPv6 record alongside IPv4. Instead of a port forward, you open the router's IPv6 firewall for that one device and port.
  • Use a tunnel service. A program on the device dials out to a relay service, and connections come back down that outbound link. Nothing has to arrive uninvited, so it works through CGNAT. The trade-off is another service in the path, usually under its own name.

Checklist

  • The service answers from inside your home network.
  • The device has a fixed local address (DHCP reservation).
  • The router forwards the port to that address.
  • The router's WAN address matches /checkip - or you have handled the mismatch (bridge mode, a second forward, a public address from the provider, IPv6, or a tunnel).
  • You tested from outside: phone on mobile data, Wi-Fi off. Testing from inside can mislead - some routers answer their own public address, some do not.

See also: Getting started, Troubleshooting.

legitdns - free dynamic DNS for home serversEULAPrivacyStatusReport abuseFeedback