What's new

Connecting to the router using ddns domain name from within the network?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Ressegger

Occasional Visitor
Recently switched to ax88pro with gx6000 node both on newest merlin ai mesh with wired back haul from ax86 with ac86 node setup the same way but from scratch and I also have ddns setup from a custom domain and it sayes it's connected but I can't reach the router from within the network using the dns name unless I enable to access from Wan I don't remember having to do so before as I was just using VPN and not actualy connecting through the wan
 
The trick is:
On the LAN > LAN IP
Host Name needs to be the name you've picked for your router
The Domain name needs to be the domain your DDNS uses (without the host part)

Of course, this only really works if it's your own domain name. If you use a DDNS with a common domain segment, you'll potentially have difficulty accessing sites belonging to other users of that same DDNS service.
 
I don't have any problems at all with my setup as @Crimliar describes. My no-ip fqdn is *********.ddns.net, all my network devices respond to their own *******.ddns.net, and I have no problem accessing external *******.ddns.net domains. I use the router's caching DNS server.
But, as they say, YMMV.
 
My no-ip fqdn is *********.ddns.net, all my network devices respond to their own *******.ddns.net
And can you clarify this? Do you mean your no-ip FQDN is like myWWWExternal.ddns.net and your internal devices are like pc1.ddns.net or pc1.myWWWExternal.ddns.net?
 
Imagine a ddns of target.ddns.net. I can access my home network from the Internet via target.ddns.net (through my network's VPN), or from the local network via the same target.ddns.net. I can also access other devices on my internal network from the Internet, again over the VPN, such as server.ddns.net or stb1.ddns.net (satellite box). It sounds complicated but it really isn't. I'll grab some screenies.
 
LAN IP
Screenshot_2024-10-05-20-34-52-33_3aea4af51f236e4932235fdada7d1643.jpg


DHCP
Screenshot_2024-10-05-20-37-54-06_3aea4af51f236e4932235fdada7d1643.jpg

Screenshot_2024-10-05-20-37-32-74_3aea4af51f236e4932235fdada7d1643.jpg


DDNS
Screenshot_2024-10-05-20-36-44-64_3aea4af51f236e4932235fdada7d1643.jpg


The caching dns server is a use it or not choice. I find it speeds up enquiries for some of the sites I visit regularly. Some don't. You'll find it under Tools>Other Settings.
Important note: I recommend to never enable Web access from the WAN. Always access through VPN.
 
Last edited:
Seems to me we've lost the plot here.

AFAICT, the issue for the OP has nothing to do w/ DDNS per se. However the OP resolves/determines his public IP, whether it's via DDNS, or he has a KNOWN static public IP, the issue has to do w/ NAT loopback. IOW, referencing that public IP from within the local network behind it.

In order for that to work, the target device has to be made remotely accessible via the WAN, whether that's simply an open port on the WAN for access to the router itself, or some other device on the LAN made accessible via port forwarding.

IOW, if it isn't normally accessible over the WAN when actually outside the WAN, it is NOT going to be accessible via the public IP while inside the LAN either. The two go hand-in-hand together for the purposes of NAT loopback.

Why? Because when you make something remotely accessible, that creates a DNAT (redirection from WAN to LAN) in the firewall. The DNAT is what NAT loopback depends on in order to convert the external (WAN) reference to an internal (LAN) reference.

As far as the reference to a VPN, you lost me there. I assume you meant that normally you remotely access via your own VPN server rather than the WAN. But that has nothing to do w/ the problem described above, which is about an external reference to an internal resource while *physically* on the LAN.
 
I believe myself and @Ripshod have been using these techniques for years - without issue!
And as a heads-up, I can very definitely ping my WAN IP without having to "Enable Web Access from WAN". Try it!
 

You're conflating ping w/ remote access of the GUI. These are different things.

You can ping based on the public IP of the router while inside the LAN because the router is listening on all its network interfaces for that protocol. That is NOT true of the GUI (I assume this is the OP's primary interest, NOT ping). The router only listens on its LAN interface for the GUI, which you can verify w/ netstat.

Code:
admin@lab-merlin1:/tmp/home/root# netstat -tupln | grep httpd
netstat: showing only processes with your user ID
tcp        0      0 127.0.0.1:80            0.0.0.0:*               LISTEN      292/httpd
tcp        0      0 192.168.1.1:80          0.0.0.0:*               LISTEN      292/httpd
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      291/httpds
tcp        0      0 192.168.1.1:8443        0.0.0.0:*               LISTEN      291/httpds

That's why you need to enable remote access to the GUI if you expect to access it remotely, OR, internally via the public IP. Enabling remote access adds the DNAT that converts the public IP reference to a LAN IP reference (e.g., 192.168.1.1).

Code:
admin@lab-merlin1:/tmp/home/root# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 668 packets, 127K bytes)
 pkts bytes target     prot opt in     out     source               destination       
    1    60 GAME_VSERVER  all  --  *      *       0.0.0.0/0            192.168.63.102   
    1    60 VSERVER    all  --  *      *       0.0.0.0/0            192.168.63.102   

Chain VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination       
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 to:192.168.1.1:8443
    1    60 VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0

And now NAT loopback will work as well.
 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top