Active Directory DC Container access from multiple different subnets?

NethServer Version: NethServer release 7.6.1810 (final)
Module: nethserver-dc

I’m looking for the proper setup that allows proper communication to the Active Directory Domain Controller container from a different subnet outside of the one that was initially configured and setup during initial container setup process.

All is well on basic setup and config for our main LAN subnet (able to join a windows machine that sits on the same /16 subnet as the Nethserver DC) The issue is our WLAN subnet is it’s own separate /16 subnet.

Example subnet info (not exact ones used on LAN)
LAN: 10.20.0.0/16
WLAN: 10.25.0.0/16

nethserver vm: 10.20.1.253
NSDC container: 10.20.1.252
br0 was auto configured for the container when it was initially turned on/created.

A little background on a similar situation - We currently have a Zentyal DC running on this same network where we added a 2nd NIC to that vm for the WLAN subnet. Then we simply adjusted which IP to use on a given device for what it uses as DNS to point to the matching interface 10.20.x.x for LAN machines, 10.25.x.x for wireless machines.



(Side Discussion here while I’m at it. Do we point client machines to the Nethserver Host IP or the NSDC container IP for DNS before joining to domain? I noticed using either worked for the LAN machine that joined OK.)



I attempted to do this on NS by adding another NIC to the VM, configuring it in network tab in GUI. I can ping the additional IP now but not sure what needs to be done on the bridge side of this or additional config on the container side if any to allow the needed traffic over this additional IP when a machine attempts to join the domain using the additional NIC as it’s DNS.

Error received during the domain join attempt on a PC on the WLAN subnet. Taken from c:\WINDOWS\debug\dcdiag.txt

DNS was successfully queried for the service location (SRV) resource record used to locate a domain controller for domain “ccs.com”:

The query was for the SRV record for _ldap._tcp.dc._msdcs.ccs.com

The following domain controllers were identified by the query:
nsdc-nethserver.ccs.com

However no domain controllers could be contacted.

Common causes of this error include:

  • Host (A) or (AAAA) records that map the names of the domain controllers to their IP addresses are missing or contain incorrect addresses.

  • Domain controllers registered in DNS are not connected to the network or are not running.

nsdc-nethserver.ccs.com is the proper name of the NSDC container here but it appears as though the request doesnt make it to the container?

Any pointers or help on this is greatly appreciated. I also spent a decent amount of time searching for old posts on this topic but did not have much luck to this point.

WLAN subnet and LAN subnet are using NethServer (not container) as gateway?
How did the WLAN subnet has been classified on NethServer? Green? Blue? Whathever?

1 Like

pike,

We have another server on our network setup as our gateway so no, NethServer is not serving as our gateway. Both LAN and WLAN machines are using a different IP for GW and are only using NethServer for DNS at this point.

NethServer networking is set to
ens18 (role: bridged - br0)
br0 (role: LAN - green) 10.20.1.253

the extra interface I added to the VM is
ens18

I set a static IP 10.25.1.252 on it and set to GREEN but no luck with joining the wireless machine.

I’ve also attempted some other bridging scenarios too (not totally sure on this part though, still researching/reading documentation on this)

New br1 created (role: LAN - green) 10.25.1.252

No luck here with the wireless machine joining.

Would you please try to add the WLAN Subnet into Trusted Network?
My “home” setup is also a gateway, i don’t know if yours have this option into NethGui…
Keep the bridge on LAN network, currently.
Also… One way or another, the WLAN subnet should correctly resolve NethServer.

Why you don’t set up another virtual machine, with NS and configured remote AD that point to the actual AD? You should create this VM into the other LAN and I think it can works… I don’t know if you can set up AD (with your actually configuration) on another LAN because the IP of DC it’s only one and it’s only in one LAN.

You can also set up two green NIC on your actual VM and try to add a firewall rule that consent traffic from Green1 to Green2 and viceversa. Then try to resolve DC IP with nslookup and ping command from your 10.25.0.0 LAN. Check also your DNS and sync the time.

Wait for your feedback.

1 Like

Thanks Pike for the continued dialogue in an attempt to help me out here.

That WLAN subnet was already added to Trusted Networks and I verified still in there

So I shouldn’t need another bridge pointing to my 2nd NIC on the VM then besides the main LAN br0 that was created by initial setup?

ping nethserver.ccs.com

Pinging nethserver.ccs.com [10.25.1.252] with 32 bytes of data:
Reply from 10.25.1.252: bytes=32 time=1ms TTL=64
Reply from 10.25.1.252: bytes=32 time=2ms TTL=64
Reply from 10.25.1.252: bytes=32 time=2ms TTL=64
Reply from 10.25.1.252: bytes=32 time=2ms TTL=64

Ping statistics for 10.25.1.252:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms


ping nsdc-nethserver.ccs.com

Pinging nsdc-nethserver.ccs.com [10.20.1.252] with 32 bytes of data:
Reply from 10.20.1.252: bytes=32 time=1ms TTL=63
Reply from 10.20.1.252: bytes=32 time=2ms TTL=63
Reply from 10.20.1.252: bytes=32 time=3ms TTL=63
Reply from 10.20.1.252: bytes=32 time=5ms TTL=63

Ping statistics for 10.20.1.252:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 5ms, Average = 2ms

I feel like this is part of the problem. nsdc-nethserver.ccs.com is the AD container on the 10.20 subnet but the machine sitting on the wireless 10.25. subnet can’t communicate with it, hence the reason for the failure of joining it to the domain?


Do you use virtualization?

When installing on virtual environment, make sure the virtualization solution allows traffic in promiscuous mode .

http://docs.nethserver.org/en/v7/accounts.html#installing-on-a-virtual-machine

1 Like

Interesting workaround. I can definitely give this a try to see how it goes. I’ll have to look up additional documentation to assist with this. Would I essentially have this 2nd NS joined to the domain as a member and basically running as another DNS server just for wireless client communication? Seems like a lot of overhead just to get proper communication to the domain controller container running on that other separate subnet. There’s no way to have the AD container communicating on another IP somehow or make it aware of the 2nd interface on the main NS that I setup with a wireless subnet IP?

After lots of reading lately on how NethServer functions, I see just how highly customized it is to help simplify tasks using the GUI. I’m also seeing some potential downfalls to this (for me in particular) as well when it comes to simple tasks such as directly editing files while directly on the server over ssh. IE: /etc/hosts … /etc/dnsmasq.conf … /etc/shorewall/rules. Not having access to quickly edit these to test things out on the fly during testing is a bit of a learning curve so far to piece together how these tie into the GUI and other custom NS related scripts behind the scenes. I’ll have to do some digging on proper methods to use to attempt opening up traffic between green 1 and green2 interfaces like you mentioned.

Thanks for the tips!

Yes, I’m running my NS on proxmox as a VM. Because I dont have any issues with traffic with the main ens18 interfaces including the br0 to the container (assuming I dont because I can join a client on the same subnet as the NS/AD container)

I did try manually running the following on my NS where I attempted to join the wireless machine after I did each command but no luck.

ifconfig br0 promisc
ifconfig ens18 promisc
ifconfig ens19 promisc

You can configure the second machine as remote AD under account provider page.

You can also try to add alias IP under actual green interface if your networks are connected. If you want to set up two different networks I think that the solution should be to set up two machines.

This whole issue ended up being a firewall issue outside the scope of the actual NethServer and AD container in general. Our previous Zentyal Domain was setup with a second interface to communicate with wireless machines on that subnet along with DNS forwarders configured within Xentyal. Essentially that method allowed proper communication without the need for additional firewall rules on our network firewalls between the two subnets. NethServer having this AD container over the one bridged interface appears to have been a slight roadblock when trying to set NS up similar to our Zentyal as mentioned above.

I used the below microsoft article as a reference to open up proper ports between the wireless subnet and the NethServer (IP of the AD container) Joining a wireless machine to the domain that’s pointed to NS AD container IP as DNS now goes through AOK.

https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts

Thanks to all who chimed in on this thread with some alternative ideas and things to double check. It’s nice to see how quick I received some replies in the forums!

1 Like