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

[Ressegger]

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

 

[Crimliar]

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.

 

[Ripshod]

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.

 

[Justinh]

I use the router's caching DNS server.

What is this and how do you use it?

 

[Justinh]

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?

 

[Ripshod]

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.

 

[Ripshod]

LAN IP

DHCP

DDNS

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.

 

[eibgrad]

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.

 

[Crimliar]

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!

 

[Tech9]

You only match the name @Crimliar hoping no one actually has the same. The correct method is what @eibgrad describes using NAT loopback.

 

[Ripshod]

And as a heads-up, I can very definitely ping my WAN IP without having to "Enable Web Access from WAN". Try it!

 

[eibgrad]

View attachment 61777

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.

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 (WAN) IP reference to a private (LAN) IP reference (e.g., 192.168.1.1).

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.

 

[Ripshod]

@eibgrad you are correct that I got hung up on the DDNS part. However:

That's why you need to enable remote access to the GUI if you expect to access it remotely

.....or use a VPN server on the local network, which will also give private access to other devices in the network. Much safer than just opening the door, surely?

 

[eibgrad]

@eibgrad you are correct that I got hung up on the DDNS part. However:


.....or use a VPN server on the local network, which will also give private access to other devices in the network. Much safer than just opening the door, surely?

Absolutely correct. I wasn't suggesting it was a good idea. It is NOT. I was merely explaining for those who insist on this approach, what it takes to work as requested.

Most ppl become interested in NAT loopback because they want to maintain the same references to their services whether they are remote or local, using the public IP. But that assumes access is over the WAN. The better approach is using your own VPN server and always using a *private* IP as your reference.

 

[XIII]

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

I'm using a domain name to access my router over WAN (SSH only, not the web interface). To use the same domain name on LAN (on my MacBook only...) I added an entry to /etc/hosts (on that laptop) which maps the domain name to the IP address of my router:

192.168.1.1 hostname.tld

 

[Crimliar]

If you have IPv6, you don't even need to go that far, it just works. And if you can map any servers that you may need to make available, they'll work too - there is no issue with NAT Loopback when using IPv6. Setting up any certificates can be a little more convoluted though!
*And your clients do not need to be exposed to the internet over IPv6, just as long as the addresses are correct