Community discussions

MikroTik App
 
hqxnet
just joined
Topic Author
Posts: 2
Joined: Mon Dec 20, 2021 5:23 pm

Static DNS not always working

Mon Dec 20, 2021 5:39 pm

Hello everyone!
I haven' t been able to find a definitive answer for this, and it seems I might be going wrong about it.
My goal is to have a server listening on a local appliance and have users access it using the same address both from local the LAN and from a VPN connection.
I have created a static DNS entry in RouterOS pointing to an internal IP assuming that every connection request to that address would be routed to the local IP but that sometimes works and sometimes doesn´t.
I intend to avoid having to deal with NAT Hairpin, hence the use of the VPN-only access.

When it fails a traceroute reveals that the connection is being forwarded to our WAN's public address.
The ROS DHCP hands down only it's own IP as the DNS server, so I'd expect it to be the only queried device and to redirect users to the registered IP when asked for the address of the FQDN...

Are my assumptions on how the static DNS entry is supposed to work wrong?

(The specifics of the ROS version escape my memory right now but it is 6.x )

Thanks in advance.
HQ
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19103
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Static DNS not always working

Mon Dec 20, 2021 5:45 pm

Well for starters posting the config will assist
/export hide-sensitive file=anynameyouwish

VPN is not required for internal queries to the server by the way but I applaud the concept of external access to the router being served up by a VPN tunnel to gain access for really good security.
If that is the case, then one simply needs to ensure
a. forward chain firewall access from the vpn interface to the server, and
b. an IP route such that all traffic destined for the external users gets routed out the tunnel and not the standard WAN.

The only time you need hairpin is if
a. the LAN users and server are on the same subnet and the easiest solution is simply to put the server on its own subnet!
b. use of the DNS solution should work as well for the LAN users as you have attempted.......

More info here...
viewtopic.php?t=179343
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Static DNS not always working

Mon Dec 20, 2021 8:30 pm

Static DNS records do work, meaning that if client asks router's DNS resolver for something, and there's static record for it, client will get that. Problem is with ensuring that client will ask router, and only router, never any other resolver.

Even if it gets router as the only resolver from DHCP, it can still fail, because something can have hardcoded use of some other resolver, be it regular one (that you can intercept) or encrypted one like DoH or DoT (that you can't do anything about).

And if it's remote VPN client, it's even worse, because the system definitely has other resolver(s), and you can't guarantee that it will exclusively use only what it gets from VPN. And even if it does, it will do that only when VPN is connected. If anything asks for the hostname a second before, it gets response from public resolver, and it will be cached and used even after VPN connects.

I'm not sure if you want the service accessible only from LAN and remote VPN clients, or if it's also publicly available from WAN (since the hostname also resolves to public address). If it's the latter, then don't think for another second and go for hairpin NAT. The only argument against it is that traffic from local clients have to go to router and back, and that could be problem if it's something massive. But other than that, it's simple and trouble free solution. And it's not one or the other, you can combine both, use static DNS records for clients willing to use them, and have hairpin NAT as backup when static DNS fails for any reason.
 
hqxnet
just joined
Topic Author
Posts: 2
Joined: Mon Dec 20, 2021 5:23 pm

Re: Static DNS not always working

Tue Dec 21, 2021 12:33 am

Hi, thank you for all the insights guys!

>Well for starters posting the config will assist

Yeah, I just didn't want to pollute the post if it wasn't really necessary.
Good to know that I wasn' t completely far off then.

> a. the LAN users and server are on the same subnet and the easiest solution is simply to put the server on its own subnet!
> b. use of the DNS solution should work as well for the LAN users as you have attempted.......

Server and users are on the same subnet, but my understanding was that I could avoid hairpin as long as I wasn't attempting to reroute traffic from one port to another within this same subnet

> Static DNS records do work, meaning that if client asks router's DNS resolver for something, and there's static record for it, client will get that. Problem is with ensuring that client will ask router, and only router, never any other resolver.

Yes, the "failing" devices behave as if they were ignoring the local DNS and it' s static host.

> And if it's remote VPN client, it's even worse, because the system definitely has other resolver(s), and you can't guarantee that it will exclusively use only what it gets from VPN.

So far I haven' t paid much attention to what happens with the VPN clients because even local ones are "failing" (see points above and below), but it might as well be happening too.

> If anything asks for the hostname a second before, it gets response from public resolver, and it will be cached and used even after VPN connects.

hummm... I overlooked that something so basic could be happening...
Actually the moment when I realized I should ask here was when -being at the LAN- my notebook would traceroute to the public IP and my cellphone to the proper local IP... I figured I must be missing something there...

> I'm not sure if you want the service accessible only from LAN and remote VPN clients, or if it's also publicly available from WAN (since the hostname also resolves to public address). If it's the latter, then don't think for another second and go for hairpin NAT.

I should add this for more context:
Because A) I want to increase security and B) I'm tired of users not understanding "use URL with non-standard port to access from the outside and use URL without port to access from within the LAN" I decided to enforce VPN connections and to stop using port forwarding for user facing services.

For these services I want to have "unique" addresses for local and remote access, "remote" being now VPN instead of WAN.
But for other services I intend to have external WAN access, for instance the VPN server address should be a FQDN, so I am using a DDNS with wildcards, which means that any query for <*.me.myddnsss.com> will effectively resolve to our public IP address.

I realize I could use IPs instead of FQDNs for the "user facing services", but they are less flexible when I need to (i.e.) have a service running in a parallel VM for maintenance, but that would be, IMHO, sub optimal.

> If it's the latter, then don't think for another second and go for hairpin NAT.

To be completely honest, hairpin was my first intention. But most of what I read in the forums it seems to quite more complicated that I can chew right now... As many -or most- of you probably know, this "24 months year" has been a tough one to keep up with...

Well, maybe I can't escape hairpin :) ?... I'll give that link another look, come back posting my config and see how that looks.

Regards.
(PS: I hope I was able to explain myself)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19103
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Static DNS not always working

Tue Dec 21, 2021 1:07 am

Sort of LOL. To me vpn is far more complex than hairpin nat...........
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Static DNS not always working

Tue Dec 21, 2021 2:03 am

B) I'm tired of users not understanding "use URL with non-standard port to access from the outside and use URL without port to access from within the LAN"
This is exactly what hairpin NAT solves. Whether you're connecting from inside or outside, it doesn't matter, there's always same hostname and same port, nothing changes and it works from everywhere. Everyone uses public dns and you don't need any special config anywhere. Except one srcnat rule on router that does hairpin NAT. And proper dstnat rules, but it's no biggie either. There's nothing complicated about it.

But if you don't need the service publicly available at all, i.e. no direct access to server from internet with port forwarding, and everyone can use VPN to access it, it's of course safer. In that case, opening it to the world just to make things easier, would be going backwards. But then you really have to solve this internal DNS.

For start, I'd use private hostnames, something that doesn't exist in public DNS at all. It still doesn't guarantee that everything will start to work without any problems. If a request goes to public resolver, the answer will be that it doesn't exist, which too can be cached, but only for a while, and it will start to work after that, if client asks your router. At least you won't ever get wrong address.

If this won't work realiably even with internal clients that don't use VPN, and only have router as DNS resolver, you'll need to find out what exactly they are doing, what other resolvers they use and why.

Who is online

Users browsing this forum: baragoon, Kanzler and 35 guests