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)