Configure server firewall to allow remote connections?

[grunger106]

But if you ping 10.0.0.20 it works? If so you have a DNS issue over the tunnel.

I suspect the issue you're actually chasing.

If your SQL connection strings are pointing at something the machine can't resolve it ain't going to work.

 

There are some strange configs at play here.

I assume 10.0.0.1 is your Draytek device

I suspect this server is also a Domain Controller and DNS server, as well as a SQL Server (not recommended)

If I am correct that it's a DC then it's the DNS server settings on the NIC are incorrect, it should not be pointing to your Draytek device as a DNS server, even if it's just a member server and the DC is elsewhere it still shouldn't be pointing at a non-domain integrated DNS server.

However someone might have stuck that there to make it 'work'

 

It sounds like you have a domain controller, but people logging into workstations with local accounts, mapping drives and then authenticating at that point.

And your SQL Authentication method is unknown, but based on the rest of this guesswork I'd bet it was SQLAuth.

 

This may 'function' but it's not right.

 

TBH there is enough wrong here that I don't think you're going to get this sorted over a forum post, did you set this up or did you have someone do it for you?

 

[M_Lyons10]

  On 24/03/2020 at 17:01, grunger106 said:

But if you ping 10.0.0.20 it works? If so you have a DNS issue over the tunnel.

I suspect the issue you're actually chasing.

If your SQL connection strings are pointing at something the machine can't resolve it ain't going to work.

 

There are some strange configs at play here.

I assume 10.0.0.1 is your Draytek device

I suspect this server is also a Domain Controller and DNS server, as well as a SQL Server (not recommended)

If I am correct that it's a DC then it's the DNS server settings on the NIC are incorrect, it should not be pointing to your Draytek device as a DNS server, even if it's just a member server and the DC is elsewhere it still shouldn't be pointing at a non-domain integrated DNS server.

However someone might have stuck that there to make it 'work'

 

It sounds like you have a domain controller, but people logging into workstations with local accounts, mapping drives and then authenticating at that point.

And your SQL Authentication method is unknown, but based on the rest of this guesswork I'd bet it was SQLAuth.

 

This may 'function' but it's not right.

 

TBH there is enough wrong here that I don't think you're going to get this sorted over a forum post, did you set this up or did you have someone do it for you?

 

Expand  

Thank you for your help. 

 

Based on the ipcongif /all on the remote machine, it is getting the DNS settings from the office...

 

How would I fix the DNS issue over the tunnel?  I could see if that fixes it?

10.0.0.1 IS the Draytek device, yes. 

 

I tried an experiment today and found it very interesting.  I think you're right about the DNS being the issue but I'm not sure how to fix it...

 

The SQL connection string references the server by name.  BUT, if I change the server name to its IP Address, it works!

 

The same for accessing the file system.  So, if I try to browse to the server in file explorer by IP Address, it works as well!  Though I can't open any of the files... Oddly (it says that they can't be reached).

 

I realize that the person that set this up did some things improperly, but is this DNS issue able to be fixed?  I REALLY appreciate your help.  Thank you very much for all of your time and expertise.

Edited March 25, 2020 by M_Lyons10
Mor informtation

[grunger106]

100% proves its a DNS issue.

 

Post an ipconfig /all of on the VPN'd workstations.

 

For it to work you'd need 10.0.0.20 as the pushed DNS server to the clients, OR have the Draytek push itself to the clients as DNS server and have your internal domain referenced in the DNS settings of the Draytek with a forwarder to 10.0.0.20

I know how to do this on the equipment I use (SophosXG/Cisco), but Draytek isn't my area I'm afraid so I can't tell you exactly how to do this with one of those.

 

But like I say there is some funky config with your domain and internal DNS going on there too, this is the sort of thing that I hate walking into when I get it at work as you have to figure out what effect doing it by the book will have with the rest of the non-standard configuration - can of worms.

[Joe User]

If they're internal IP's and static and the clients are all set, just cheat and put the server names into the HOSTS file and figure out DNS later on.

[grunger106]

That's an option, and it would work, but would not be a path I'd follow as that kind of 'temporary fix' has a nasty habit of becoming permanent

 

I'm a firm believer in doing it right - bodging a HOST file is masking a problem, they might 'fix' this issue, but the next issue you find might be because of the last bodge you did.

Then when someone does eventually have to do it properly they have to spend ages unwinding all the 'temporary fixes' before they can get the thing in a state to do it right.

 

Doing it properly takes more time, more effort, and more knowledge but if it's done by the book then you can be confident it will work every time without further messing about and future changes can be implemented without worrying about stuff breaking as it wasn't standard.

 

There isn't a vast amount of work here I suspect, it's probably a couple of days for a decent engineer

 

Just my opinion of course, but it's how I approach all the projects I work on.

[Joe User]

  On 25/03/2020 at 18:52, grunger106 said:

That's an option, and it would work, but would not be a path I'd follow as that kind of 'temporary fix' has a nasty habit of becoming permanent

 

I'm a firm believer in doing it right - bodging a HOST file is masking a problem, they might 'fix' this issue, but the next issue you find might be because of the last bodge you did.

Then when someone does eventually have to do it properly they have to spend ages unwinding all the 'temporary fixes' before they can get the thing in a state to do it right.

 

Doing it properly takes more time, more effort, and more knowledge but if it's done by the book then you can be confident it will work every time without further messing about and future changes can be implemented without worrying about stuff breaking as it wasn't standard.

 

There isn't a vast amount of work here I suspect, it's probably a couple of days for a decent engineer

 

Just my opinion of course, but it's how I approach all the projects I work on.

Expand  

It really depends on the number of clients and servers, if it's all a static workgroup and under 2-3 systems total, I don't bother with internal DNS at all.

 

If they're actually running a domain, then yes, fix DNS!

[+BudMan MVC]

If he can not resole the fully qualified domain name..  Which should be

 

OSRVR.DISBLAS.local

 

First thing I would say is use of .local as your tld is HORRIBLE HORRIBLE idea!  .local is used by mdns.. Should not be used as domain or tld of a domain.

 

But if you can not ping that, then look to your dns your pointing to.. Can tell you for damn sure google dns is not going to resolve it for you... Your vpn clients should point to your local dns, which I assume is 10.0.0.20. what is this 10.10.0.1 - That is your gateway?  So this .20 box is also your DC running dns services?  Since its pointing to itself for dns.. DNS server in AD shouldn't also have your router for dns..

 

You also have isatap interface active.. 2 of them??

 

This network needs some serious love!!!  I would use the technical term Borked! to describe the setup as you have presented it 😉  And from the output of your ipconfig /all..

 

What I would suggest is you fix your local dns so your vpn clients can resolver your server by FQDN.. Then once you have that working, we can figure out if still not working what else is going on... But that is prob a good bet that is the problem.

 

What happened to the ipconfig info.. There was nothing in there of any significance for privacy... it was rfc1918 address... And what the disblas name of the domain.

[M_Lyons10]

  On 25/03/2020 at 19:33, BudMan said:

If he can not resole the fully qualified domain name..  Which should be

 

OSRVR.DISBLAS.local

 

First thing I would say is use of .local as your tld is HORRIBLE HORRIBLE idea!  .local is used by mdns.. Should not be used as domain or tld of a domain.

 

But if you can not ping that, then look to your dns your pointing to.. Can tell you for damn sure google dns is not going to resolve it for you... Your vpn clients should point to your local dns, which I assume is 10.0.0.20. what is this 10.10.0.1 - That is your gateway?  So this .20 box is also your DC running dns services?  Since its pointing to itself for dns.. DNS server in AD shouldn't also have your router for dns..

 

You also have isatap interface active.. 2 of them??

 

This network needs some serious love!!!  I would use the technical term Borked! to describe the setup as you have presented it 😉  And from the output of your ipconfig /all..

 

What I would suggest is you fix your local dns so your vpn clients can resolver your server by FQDN.. Then once you have that working, we can figure out if still not working what else is going on... But that is prob a good bet that is the problem.

 

What happened to the ipconfig info.. There was nothing in there of any significance for privacy... it was rfc1918 address... And what the disblas name of the domain.

Expand  

Thank you for your response.

 

I'm really shocked that there are so many issues with this setup.  The server was set up by someone that said they knew what they were doing.  They even ran a tech service, so I'm really disappointed in them to say the least.  He closed up shop last year and I'm beginning to understand why.

 

I would like to try to correct the DNS issue, but I'm honestly not sure where I should start or what I should change.  The only DNS settings I've found in the router are under the LAN Setup and they're blank...

 

On the server I found the DNS Manager, but definitely didn't want to mess with anything in there without knowing what I was doing.  I did see that the workstations were listed but their IP Addresses weren't correct.  They're all 192.168.1.x, when they all would be 10.0.0.x...?  So I did find that odd.

 

I really do appreciate everyone's help and I'm sorry that this is as big a mess as it is.

[+BudMan MVC]

  On 25/03/2020 at 20:08, M_Lyons10 said:

The server was set up by someone that said they knew what they were doing

Expand  

Not in the least would be my opinion from what have seen.

 

  On 25/03/2020 at 20:08, M_Lyons10 said:

He closed up shop last year and I'm beginning to understand why.

Expand  

Yeah would make sense if he set that mess up 😉

 

I might be able to find some time to remote in and fix it up.. Not like any of us our about town these days 😉  if you don't have a problem with that... Let me know, @sc302 has been known to fix up users systems remotely as well.. He is guru for sure.. One of the few people around here I would trust to touch my systems even.. He might even be better because unless something has changed, he deals with windows systems day to day.. While I don't - more on the security and network side for many years.  I still tinker in my lab and such, and consult when they run into ###### they can't figure out at work 😉 hehehe... 

 

All I would ask is maybe you donate what you feel appropriate to a good cause of your choosing.. Non religious based would be my only stipulation 😉

[grunger106]

  On 25/03/2020 at 19:33, BudMan said:

If he can not resole the fully qualified domain name..  Which should be

 

OSRVR.DISBLAS.local

 

First thing I would say is use of .local as your tld is HORRIBLE HORRIBLE idea!  .local is used by mdns.. Should not be used as domain or tld of a domain.

Expand  

100% - I didn't go down the route of flagging that as there are so many .locals still around - it was best practice for 15 years, and many internal domains I deal with are still there, but I'm moving them to ad.company.com as and when
Benefit of the doubt and assumed it was an old one that was migrated.

  2 hours ago, BudMan said:

 

But if you can not ping that, then look to your dns your pointing to.. Can tell you for damn sure google dns is not going to resolve it for you... Your vpn clients should point to your local dns, which I assume is 10.0.0.20. what is this 10.10.0.1 - That is your gateway?  So this .20 box is also your DC running dns services?  Since its pointing to itself for dns.. DNS server in AD shouldn't also have your router for dns..

Expand  

Yep! Pointed that out - OPs reported issue is certainly DNS, and is probably fixable - but there is more rot here.

 

  2 hours ago, BudMan said:

 

You also have isatap interface active.. 2 of them??

 

This network needs some serious love!!!  I would use the technical term Borked! to describe the setup as you have presented it 😉  And from the output of your ipconfig /all..

Expand  

Yep

  2 hours ago, BudMan said:

 

What I would suggest is you fix your local dns so your vpn clients can resolver your server by FQDN.. Then once you have that working, we can figure out if still not working what else is going on... But that is prob a good bet that is the problem.

Expand  

Yep!

 

Unfortunately as I previously said, this is a can of worms.

 

OP:

What is the site layout, how many workstations, how many servers.

 

For reference: 

 

You should have

 

1 or more (ideally 2 at least) domain controllers, these would normally also be DNS servers and in a small network one or both would be DHCP servers

All workstations should be getting IPs from DHCP, they would have DNS set to be the internal DNS, and the gateway would be your Draytek,
They should be domain joined and users should be logging on with AD credentials.

 

SQL should not be on a DC, but it does happen in small environments, SQL should be AD integrated and logins to SQL should be NT based - as in based off the AD login the user used to login to the workstation.

 

This is all pretty basic, but lays out the correct structure.

 

It sounds like you have AD, but no joined machines and DNS that is incorrect - a DC should never be pointing to a DNS server that isn't AD aware.

 

I'd want to see

 

Ipconfigs from server, workstation and a screen grab of the AD DNS and DHCP tables.

 

Frankly from what I've seen so far I'd want to be double checking the backup solution was what you expected too.

 

Your initial query is a simple DNS over a tunnel issue,

 

[+BudMan MVC]

  On 25/03/2020 at 22:40, grunger106 said:

it was best practice for 15 years, and many internal domains

Expand  

Apple took it when, like 2013 with rfc 6762 I think... Since then its been bad idea to use it for your actual domain or tld..

 

Well its not like they own it or anything.. but pretty sure they put out that rfc..  F'd everyone that was using it for other than mdns.

[shockz]

.LAN has replaced .local for me thanks to Apple's stupidity. 

[grunger106]

  On 25/03/2020 at 22:38, BudMan said:

I might be able to find some time to remote in and fix it up.. Not like any of us our about town these days 😉  if you don't have a problem with that... Let me know, @sc302 has been known to fix up users systems remotely as well.

Expand  

Brave man that takes on an unknown, oddly configured AD from afar! 😂

  On 25/03/2020 at 22:47, BudMan said:

Apple took it when, like 2013 with rfc 6762 I think... Since then its been bad idea to use it for your actual domain or tld..

Expand  

Yep - it's been bad practice for ages, it's just so ingrained that its still pretty common in sites where the AD has been around a long time - it's not good, but it's there (not for external TLDs of course, but there are loads of companies with .local internally still)

Funny story - I was doing some consultancy recently and the domain was NT.local - literally the example from the books in the early 2000s (400 users and a 20 year old AD) - they also had 7 DCs,  each new admin was frightened to domote the old ones, the the FSMO role holder was a 9 year old G5 proliant

 
Maybe the magic move away from internal AD to AzureAD will finally shunt people along..... (.....maybe, when Intune is 1:1 with GroupPolicy) 

Edited March 25, 2020 by grunger106

[M_Lyons10]

  On 25/03/2020 at 22:38, BudMan said:

Not in the least would be my opinion from what have seen.

 

Yeah would make sense if he set that mess up 😉

 

I might be able to find some time to remote in and fix it up.. Not like any of us our about town these days 😉  if you don't have a problem with that... Let me know, @sc302 has been known to fix up users systems remotely as well.. He is guru for sure.. One of the few people around here I would trust to touch my systems even.. He might even be better because unless something has changed, he deals with windows systems day to day.. While I don't - more on the security and network side for many years.  I still tinker in my lab and such, and consult when they run into ###### they can't figure out at work 😉 hehehe... 

 

All I would ask is maybe you donate what you feel appropriate to a good cause of your choosing.. Non religious based would be my only stipulation 😉

Expand  

Hello @BudMan, I would absolutely appreciate that and would be happy to make a donation to a charity.  That is really an amazing thing that you're doing there.

 

How would we do that?  PM?  I'm sorry it took me so long to get back to this, my internet went down at the house for much of today.  For a minute there I was getting pretty stressed out stuck in the house with absolutely NOTHING to do...  lol

[sc302 Veteran]

I would be willing to look at it for sure.  I am pretty good at not messing things up    
 

if you want or need shoot me a pm.  I am not as active as I once was but always willing to lend a hand when in need. 
 

teamviewer or maybe something else. 

[+BudMan MVC]

Well I sent him a PM, haven't heard anything back..