Multiple sites FreeNAS, AD and DNS

[Aaron Woldman]

Hey all,
I currently have a windows 2008 (just 2008 not r2) domain with 15 remote sites connected via lan to lan vpns.
At each site I have a small FreeNAS server versions range depending on the install date. Oldest version is about 2 years back.
I am using FreeNAS for the users home shares and the local facility share.
Each facility has between 3 and 8 people who are domain users.

I seem to be running into a few issues that stem from connectivity back to the home office when we lose a vpn connection
either a power event or internet outage. (Rural locations)

The first is simple, currently all the users are using the main office service (domain controller) for DNS.
If the main office is offline no one can browse the internet or even get to the local FreeNAS server via AD connections.

Is there any downside to running secondary DNS of the AD domain locally on the FreeNAS server, as well as caching for internet browsing?
Is this something that should be done in a jail or can I just work with bind directly?

Is it possible to run FreeNAS as a secondary domain controller on an existing domain? I haven't found much on this.
I have been running into an issue when the vpn is down local users cannot authenticate to the AD connected FreeNAS.

Thanks for any input!

 

[Robert Trevellyan]

Is this something that should be done in a jail or can I just work with bind directly?

I can't answer all your questions, but I do know that anything you add to FreeNAS should be in a jail or a VM, not on the host system.

 

[tvsjr]

I'm probably in the minority, but I like my boxes to be single-purpose. Let FreeNAS be FreeNAS, build a small ESXi white-box system to host your secondary DNS/DC, especially if you also want to run Squid/etc.

 

[Aaron Woldman]

Problem is multiple boxes defeat the purpose of using non-microsoft based servers at the remote facilities.
Even though the M$ server would not have snapshots, I could accomplish the same with rsync and snapshots on the bigger backup nas at corp office.

 

[Dotty]

I have a customer with a similar challenge, HQ running AD with two DC and DNS resolutions.
Branch office with 4 workstations, authenticating on AD and using DNS from HQ.
Branch is connected to HQ via VPN over regular Internet.
Cable company is flaky, VPN drops twice a months for an hour or so.

Having a DC at the branch would solve the issue, but thats another Windows license, plus extra administration, plus electricity, plus heat, plus noise, plus wires, plus plus plus.
Enabling DNS server on the firewall at the branch will provide resolution for Internet domains, but not for local resources, (including the FreeNAS box), and will also expose the private naming structure (queries for local domain objects will be sent to the internet)

Perhaps running Bind on a Jail and have the workstations at the branch use that as secondary DNS,, but Im not familiar with Bind and I dont know if it offers realtime syncing with the AD DNS (if the Bind is not in sync then after a while it would cause resolutions issues)
Im also eager to hear ideas, hopefully not pointing to install redundant Internet connections, MPLS or some other sort of enterprise-grade links, or even the typical "just run another server at the branch"
We all understand the whole point is to have just the FreeNAS box at the branch.

 

[tvsjr]

There are some HOWTOs out there regarding synchronizing BIND with AD. Most start out with "unless you're very familiar with BIND, DNS, and AD, don't try this". Even if you make replication work, you won't get logon services.

If you want to stay open-source, the best answer is probably Samba. Samba 4 supports acting as a domain controller inside an existing Windows AD infrastructure. Beware, it's not nearly as easy as Windows is.

I still maintain the right answer is either to have a local AD server, or to install redundant links. Redundant links don't have to involve MPLS circuits - consider LTE as a good backup. Most Cisco routers can handle an LTE card, or there are other options (Cradlepoint, etc.) to do the same.

 

[Dotty]

Logon Services are a problem only when an user has never used the PC before, because Windows caches the last few users in event that DC is down, so the PCs will be able to work.
Microsoft already though about the DC being down and realized people still needed to work.
Windows shares and other elements work also if the DC is down.
The only thing you cant do is making changes to the directory, but that wont matter.

The only problem, is again, DNS. Someone needs to do resolution.

Samba might be a good suggestion for the OP, as he stated the need for local authentication (thinking about making FreeNAS a secondary domain controller).
Sounds like a good idea, and it will scale better to many branches.
In my case, DNS is the main issue, and I needed to be synced with the AD DNS.

Solving this issue with LTE or other metered connectivity is horrible. Monitoring LTE devices usage, troubleshooting remote connectivity, routing, and dealing with other implications of LTE is a little nightmare.
Besides is so much pressure to provide support like that, imagine, the main connectivity is down, then you dont take care of it right away for whatever reason, then branch office eats all bandwidth and the LTE bill skyrocket. Then the customer start blaming you for the bill and the whole relationship goes south, even though you made them sign a contract specifically saying they own the bill.
Personally, I would hate to be the one on the meeting explaining the bill.
Yes, now the Cellular providers can make the LTE goes to 1X speeds to avoid the overage, but that only create users discontent. I dont think that solves the issue and I dont think that scales.

That works well when you have remote weather stations, cargo tracking, vehicle telemetry, and other things that send very few packets, think of IoT (I designed AVL systems in another life, I used AMPS, TDMA, CDPD, 1X, LTE, etc, and it was great use of cellular networks).
When it comes to passing authentication, DNS resolution, and potentially a lot of AD chatting, would be scary,, I would do it only under extreme circumstances, like providing connectivity for a mobile office (like the trailers the developers used when building a new neighborhood, you know, a couple of months and thats it,, because they wont mind the couple thousand dollars bill on overage)

Again, SAMBA sounds like a good idea for the OP, and I'd like to try that myself, for the future.

 

[MatthewSteinhoff]

The features you're requesting (DNS/AD/internet caching) seem best-served from your firewall/VPN appliance and not FreeNAS. It should also be able to handle VPN failover to an alternate path, be that wired or wireless.

We have been using pfSense for at least eight years for all our branch and home offices. We started out using the community version on our own hardware (and still do for our main, corporate office) but now like their appliances for our remote offices because they are well-designed, rock solid and use tiny amounts of electricity.

Our primary internet path is a big, beefy cable company provided pipe (150/25 mbps) but, given the cable company's reliability, we also have a DSL line to each office (12/2) to provide an internet backup. Our pfSense appliances efficiently handle network failover. Adding a secondary network loop seems expensive ($50 a month, give or take) but, when you consider the overall cost of the branch offices and potential downtime, it's a tiny little drop in a very large bucket.

Cheers,
Matt

 

[Dotty]

The features you're requesting (DNS/AD/internet caching) seem best-served from your firewall/VPN appliance and not FreeNAS. It should also be able to handle VPN failover to an alternate path, be that wired or wireless.

We have been using pfSense for at least eight years for all our branch and home offices. We started out using the community version on our own hardware (and still do for our main, corporate office) but now like their appliances for our remote offices because they are well-designed, rock solid and use tiny amounts of electricity.

Our primary internet path is a big, beefy cable company provided pipe (150/25 mbps) but, given the cable company's reliability, we also have a DSL line to each office (12/2) to provide an internet backup. Our pfSense appliances efficiently handle network failover. Adding a secondary network loop seems expensive ($50 a month, give or take) but, when you consider the overall cost of the branch offices and potential downtime, it's a tiny little drop in a very large bucket.

Cheers,
Matt

Agree

Cable/DSL failover is great.
Question, does pfSense provides DNS sync with MS AD?

I used pfSense long time ago, I inherited a few Watchguard X700 boxes (with 6 Gigabit interfaces plus MiniPCI slot) and found articles on how to install pfSense on the CF card.
I took a Wi-Fi card from a Cisco WIC and put it inside the X700, drilled holes in the back, installed there the antennas, and changed the fans for Noiseblockers. That was my Home router for like 3 years.
Like I said, long time ago.
Then I discovered Mikrotik, made the switch and had been installing that at customers for a while, they also handle dual ISP very well, including VPN failover.

If there is a router that can sync with DNS from AD, then Id be a happy camper.
One way sync is ok, it is only so when the branch loses connectivity to the HQ people could still resolve addresses to AD resources, because such resources might be local at the branch.

 

[MatthewSteinhoff]

Question, does pfSense provides DNS sync with MS AD?

Short answer: probably.

Long answer: It has been so long since I've done anything with Active Directory, I'm not sure. Here is what the pfSense manual says about DNS resolution in an AD world...

"DNS Default Domain
When checked a field will appear to specify the DNS domain name to be assigned to clients. To ensure name resolution works properly for hosts on the local network where DNS name resolution is used, specify the internal DNS domain name here. For Microsoft Active Directory environments, this would usually be the Active Directory domain name.

DNS servers
When checked, up to four DNS servers may be entered for use by the client while connected to the VPN. For Microsoft Active Directory environments, this is typically the Active Directory Domain Controllers or DNS servers for proper name resolution and authentication when connected via OpenVPN."

Cheers,
Matt

 

[Dotty]

Short answer: probably.

Long answer: It has been so long since I've done anything with Active Directory, I'm not sure. Here is what the pfSense manual says about DNS resolution in an AD world...

"DNS Default Domain
When checked a field will appear to specify the DNS domain name to be assigned to clients. To ensure name resolution works properly for hosts on the local network where DNS name resolution is used, specify the internal DNS domain name here. For Microsoft Active Directory environments, this would usually be the Active Directory domain name.

DNS servers
When checked, up to four DNS servers may be entered for use by the client while connected to the VPN. For Microsoft Active Directory environments, this is typically the Active Directory Domain Controllers or DNS servers for proper name resolution and authentication when connected via OpenVPN."

Cheers,
Matt

I know they work as "forwarders" and "caching servers" , but either or those need the AD DNS available.
If they would sync and hold a DNS DB, then would be a good thing. Im not sure something like this would exist.

 

[Aaron Woldman]

I have a customer with a similar challenge, HQ running AD with two DC and DNS resolutions.
Branch office with 4 workstations, authenticating on AD and using DNS from HQ.
Branch is connected to HQ via VPN over regular Internet.
Cable company is flaky, VPN drops twice a months for an hour or so.

Having a DC at the branch would solve the issue, but thats another Windows license, plus extra administration, plus electricity, plus heat, plus noise, plus wires, plus plus plus.
Enabling DNS server on the firewall at the branch will provide resolution for Internet domains, but not for local resources, (including the FreeNAS box), and will also expose the private naming structure (queries for local domain objects will be sent to the internet)

Perhaps running Bind on a Jail and have the workstations at the branch use that as secondary DNS,, but Im not familiar with Bind and I dont know if it offers realtime syncing with the AD DNS (if the Bind is not in sync then after a while it would cause resolutions issues)
Im also eager to hear ideas, hopefully not pointing to install redundant Internet connections, MPLS or some other sort of enterprise-grade links, or even the typical "just run another server at the branch"
We all understand the whole point is to have just the FreeNAS box at the branch.

Using Bind, you can set the M$ domain up as a secondary. Any time you make a change on the M$ server it will replicate through to bind on freenas.
You can lock down bind to only resolve for local IP's if you are worried about name security.

 

[Dotty]

Using Bind, you can set the M$ domain up as a secondary. Any time you make a change on the M$ server it will replicate through to bind on freenas.
You can lock down bind to only resolve for local IP's if you are worried about name security.

This is a good idea, unfortunately on this case with this particular customer and the branch office we found other challenges.
For example, we need to make the FreeNAS box use AD accounts for authentication on SMB shares, but if the FreeNAS box reboots while the VPN is down (such as after a long power failure), authentication breaks,, even if the VPN comes back online, the authentication doesnt work (FreeNAS doest not connect to AD anymore, unless you reboot the FreeNAS or manually join the domain again, and for whatever reason, all mapped drives on Windows clients fails dont reconnect and they need to be recreated again, and that doesnt happens with Samba running on LInux, we tested it).
Therefore, a Domain is needed at the branch office (just because FreeNAS wont cache tickets and authentication upon reboot and cannot reconnect alone as is supposed to do), the problem is, another Domain is another box, and the whole purposed of the FreeNAS box is to have only that at the branch. Of course, you can run a Domain inside FreeNAS usinng VirtualBox,, but the same thing happens, FreeNAS will boot up before the VirtualBox, and by the time the local DC is up and running FreeNAS already timed out the AD connection.
So, back to square one, in order to make FreeNAS at the branch working in a reliable way, we need another AD box there,, and it must be on another hardware, and we have to make sure it comes online BEFORE freeNAS. Geeeez !!
Wouldn't be easier if the FreeNAS can basically be resilient to AD disconnections, even on reboots? or at least, try to reconnect every few seconds after reboot, until the AD is found?
But I asked around, and looks like I have to open a "feature request" for that. I thought features are for things escaping the logic.
For example, I dont think I would need a feature request if I say that freeNAS deletes folders by itself and I need that fixed. That would qualify as a bug because it is a feature that logically should work.
Same way here, Domain Authentication should work, including reconnection is DC is unavailable.