Make Windows AD DNS work with remote site VPN / IPSEC connected lans
The problem:
Customer has a main HQ location with a Windows Active Directory setup and one or more remote LANs that are connected to the HQ location across internet based IPSEC or OpenVPN lan2lan tunnels. The small remote LANs have 2 to 10 users, a mixture of PCs and wireless users; no domain controllers exist at the remote LANs. Users must authenticate to the AD domain across the tunnel. The question is how can DHCP+DNS be setup so that if the lan2lan tunnel is down, the users at the remote sites can still browse the internet and connected to external resources.
If the DHCP server is setup to pass out 2 DNS servers:
10.10.10.10 (IP address of the HQ AD domain controller - i.e. the DC)
8.8.8.8 (google DNS)
Then in theory computers on the remote LAN would use internal DNS and resolve AD names, and then fail over to google when the tunnel is down. This is not how it will work, however, in production. What will happen is that the resolvers on the LAN will still query the google DNS server for internal domain names (he name resolver software considers the DNS servers equal in terms of resolution capability initially). This results in potential information leakage (a security issue) as your internal resources are asking an external resource (google) for information about a network (the HQ domain) that is private, and of course google cannot answer these questions. This can cause windows logins, file shares, and printing to either break or move very slow, and become unreliable and frustrating for end users.
If you remove the google dns server and have only the internal DNS server, then AD will work better, but if the ipsec tunnel is down then no name resolution will work, and unless the users have an icon on their desktop that uses RDP to connect to a remote terminal server by ipv4 address, they will not be able to work at all (well creating host file entries would work, but this is a horrible kludge that will cause trouble down the road and extra maintenance costs).
Solution #1: Replicate DNS to the remote firewall - Richweb SGW (OpenBSD gateway)
This is good example of why an OpenBSD box makes a better 1 stop solution for remote lans than a commercial firewall that does not include an OS or DNS process that you can customize!
Legend:
10.10.10.0/24: HQ LAN Subnet
10.10.10.10: HQ DC
10.10.40.0/24: Remote LAN Subnet
10.10.40.1: Inside ipv4 addr of remote firewall
hqdomain.local AD domain name
1. Edit the named configuration file to pull the zone file:
/var/named/etc/named.conf
# make sure that the clients access list allows the networks that will query this remote dns server
# to have permission to use it. If you want to test or monitor the remote DNS server process from a
# station at the HQ location, then you will need to add the HQ location to the clients list. If your
# entire internal network (HQ LAN and all remotes) is using 10.x you could add 10.0.0.0/8; for example.
acl clients {
127.0.0.0/8;
localnets;
};
# here the forwarders are commented out, but you could use opendns forwarders here if you are
# also interested in stopping the users from accessing certain internet sites.
options {
version ""; // remove this to allow version queries
listen-on { any; };
empty-zones-enable yes;
allow-recursion { clients; };
additional-from-auth yes;
additional-from-cache yes;
## forwarders { a.b.c.d; x.y.z.2; };
};
# Add these 2 zone definitions - the transfer source is important to set as we must use our internal LAN ip and not the WAN ip or tunnel ip (OpenVPN) to connect to the HQ DC across the tunnel.
zone "hqdomain.local" {
type slave;
file "slave/hqdomain.local.txt";
transfer-source 10.10.40.1;
masters { 10.10.10.10; };
};
zone "_msdcs.hqdomain.com" {
type slave;
file "slave/_msdcs.hqdomain.local.txt";
transfer-source 10.10.40.1;
masters { 10.10.10.10; };
};
The _msdcs subzone may or may not exist. Here is an excerpt from a windowsitpro article:
http://www.windowsitpro.com/article/dns/q-what-s-the-dns-_msdcs-zone-for...
"Active Directory (AD) uses DNS as its locator service to support the various types of services that AD offers, such as Global Catalog (GC), Kerberos, and Lightweight Directory Access Protocol (LDAP). Other non-Microsoft services can be advertised in the DNS, including--but not restricted to--non-Microsoft implementations of LDAP and GC. However, sometimes clients might need to contact a Microsoft-hosted service. For that reason, each domain in DNS has an _msdcs subdomain that hosts only DNS SRV records that are registered by Microsoft-based services. The Netlogon process dynamically creates these records on each domain controller (DC). The _msdcs subdomain also includes the globally unique identifier (GUID) for all domains in the forest and a list of GC servers."
2. You need to make sure that the DC allows the remote firewall - 10.10.40.1 to perform a zone transfer request in the windows DNS manager tools.
3. Restart named on the firewall:
/opt/shared/scripts/restart_bind9.sh
Check that the zones replicated:
ls /var/named/slave/
To see what named logged - in case the zones did not transfer:
grep named /var/log/daemon
4. In the DHCP settings you would have something like this:
/etc/dhcpd.conf
subnet 10.10.40.0 netmask 255.255.255.0 {
range 0.10.40.130 10.10.10.250;
default-lease-time 14400;
max-lease-time 86400;
option routers 10.10.40.1;
option domain-name-servers 10.10.40.1;
option domain-name "hqdomain.local";
option ntp-servers 10.10.40.1;
option time-offset -18000;
option autoproxy-script "http://10.10.40.1/wpad.dat";
option netbios-node-type 8;
option netbios-name-servers 10.10.10.10;
option option-156 "FtpServer=10.10.10.11, country=1, language=1, layer2tagging=0p";
option tftp-server-name "10.10.10.11";
}
Notes:
The wpad option is used if you have a web proxy (filtering or caching-only) that protects the end users at the remote site. Even if you have a content gateway at the HQ, unless you have a very fast vpn tunnel (low latency across the tunnel) and large amounts of bandwidth at the remote and at the HQ location, its not efficient to backhaul web browsing across the vpn tunnel.
The netbios-name-servers option is only needed if you have a WINS server - most AD networks wont need this option (its for legacy SMB clients - older MS networks before AD+DNS).
The tftp server and option 156 are to support remote booting of Shoretel IP phones.
Solution #2: Use Unbound DNS server with custom forwarding rule for the internal AD domain(s)
This option works well when you cannot get the zone transfer working so that the remote firewall can replicate copies of the AD zone file(s), or you simply dont want to have to configure this on the AD side for whatever reason (policy, security, compliance, etc). We will need to use unbound, which has the ability to define custom forwarders on a per domain basis. bind9 (named) can use only an all-or-nothing approach to forwarding at this time, which will not work for our purposes. We want ONLY the AD zones forwarded across the tunnel, so that if the tunnel is down, regular inet access works as expected.
1. Install the unbound package on the openbsd server, and make sure named is stopped and not configured to start in /etc/rc.conf.local
edit /etc/rc.local to start unbound:
echo -n ' unbound'; /usr/bin/sudo -c daemon /usr/local/sbin/unbound
2. Unbound is configured via:
/var/unbound/etc/unbound.conf
interface: 10.10.40.1
# Be sure to comment out the interface automatic statement and use the ip of the inside (LAN)
# facing interface for use across ipsec tunnels. Otherwise the query will not make it across the
# ipsec tunnel and you will get a server fail result in the dns query for hqdomain.local.
# interface-automatic: yes
outgoing-interface: 192.168.1.1
port: 53
access-control: 10.0.0.0/8 allow
forward-zone:
name: "hqdomain.local."
forward-addr: 10.10.10.10
forward-zone:
name: "."
forward-addr: 208.67.220.220
forward-addr: 208.67.222.222
This will forward queries for the local AD domain across the ipsec tunnel, and cache the results, and it will forward all other dns lookups to OpenDNS servers.
You should not need any rules in pf.conf different than what you would need for standard bind9 / named dns resolution. Pass out on the external intf of the firewall the outbound dns queries, and keep state:
pass out quick proto {tcp,udp} from $fwip to any port 53
You may need to add a nat rule that will set the src address of the dns queries to be the inside ip of the firewall if unbound does not pick the inside ip itself when generating the queries.
dnstop is a useful tool to install to watch the DNS traffic to verify that it is working as intended:
You can also use tcpdump. Assuming you want to watch the inside firewall interface which is fxp1:
/usr/sbin/tcpdump -n -i fxp1 udp dst port 53