Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?
-
@bearhntr:
I think there may be more than one thing you have incorrect here. You must specify the correct IPv6 prefix AND also specify which of the 16 available /64 blocks you are using. I suspect you are not fully defining the required IPv6 scope in the Windows DHCPv6 server. That scope needs the entire prefix you've been delegated along with a subnet identifier to show which of the sixteen /64 subnets in your /60 prefix is being used on the LAN (and on any other network segments you might have behind your firewall).You stated that your ISP gives you a /60 block with this prefix: 2601:c4:c501:7aa0 {remainder masked}.
Within this /60 block are 16 subnets, each a /64 in size, and the first one of these subnets starts with zero (0) and the last one starts with 0x0f (15). You would need to provide one of those 16 subnets as the "scope" for your Windows AD DHCPv6 server to issue IPv6 addresses from. You would also need to specify the size as /64. Do NOT use your WAN IP address anywhere on your DHCPv6 server in AD. That address is strictly for your WAN, and is not to be used anywhere else. The prefix delegated by your ISP's server is what you need for your internal networks.
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
If you set the scopes properly with the correct /64 subnet masks, then an IPv6 address assigned by your Windows DHCPv6 server will work out to the Internet. But, and this is a big but, the instant your ISP changes your prefix delegation, it will all cease to work again. This is because when the ISP changes your delegated (and thus routed) prefix, the DHCPv6 server scope has to change on your Windows DHCP server to reflect the newly delegated prefix. But there is no automated way for that to happen from the pfSense WAN all the way to the Windows DHCP server on your LAN. That's why with IPv6 prefix delegation (and not a true static IPv6 assignment by your ISP), you are better off letting pfSense do your DHCPv6. That's not the best solution, but when your ISP does prefix delegation it is the easiest route to stable IPv6 connectivity. That's because the DHCPv6 server on pfSense will get automatically updated with the necessary scope when the prefix changes. You can make it work connected differently, but it will require manual intervention on your Windows DHCPv6 server anytime your ISP assigns you a different prefix.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
The last 64 bytes of the IPv6 address that my ISP has give me with the Track Interface - appears to be a SLAAC address - not a DHCP6 address as I would expect - as I see no indication of it being 0-f any place. Instead it has part of the MAC Address in it. This leads me to believe that even though I have set pfSense WAN to be DHCP and DHCPv6 - the Track Interface it doing SLAAC.
RA in pfSense is set to ASSISTED.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
The last 64 bytes of the IPv6 address that my ISP has give me with the Track Interface - appears to be a SLAAC address - not a DHCP6 address as I would expect - as I see no indication of it being 0-f any place. Instead it has part of the MAC Address in it. This leads me to believe that even though I have set pfSense WAN to be DHCP and DHCPv6 - the Track Interface it doing SLAAC.
RA in pfSense is set to ASSISTED.
This is likely the prefix your ISP is delegating to you: 2601:c4:c501:7aa0::/60
This yields sixteen /64 networks ranging from 2601:c4:c501:7aa0:: to 2601:c4:c501:7aaf::. I put a bold emphasis on the spot where the /64 subnet identifier is located (that 00 - 0xf value I mentioned).
So assuming you were to use subnet "0" for the LAN, your DHCPv6 scope for the LAN would be 2601:c4:c501:7aa0::/64. This would let the DHCPv6 server issue IPv6 addresses in the range 2601:c4:c501:7aa0:0000:0000:0000:0000 to 2601:c4:c501:7aa0:ffff:ffff:ffff:ffff. The next /64 subnet in the prefix you are given would be 2601:c4:c501:7aa1:0000:0000:0000:0000 to 2601:c4:c501:7aa1:ffff:ffff:ffff:ffff. The next one is 2601:c4:c501:7aa2:0000:0000:0000:0000 to 2601:c4:c501:7aa2:ffff:ffff:ffff:ffff, and so on up to 0xf.
You can't directly see the prefix delegated to you, but you can infer it by subnetting out the LAN address because pfSense knows the prefix. Notice on the LAN IPv6 configuration page you have the option, when you enable Track Interface, of entering the prefix subnet (the 00 to 0xf value in your case).
If you want to see the entire DHCPv6 prefix delegation exchange between pfSense and your ISP's server, go to SYSTEM > ADVANCED SETUP and enable the DHCPv6 debug option. Then you can look in the DHCP log under STATUS > SYSTEM LOGS to see the full exchange. There you should find the prefix logged.
A subnet calculator tool such as this one can help you see how the subnetting works: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi.
-
I truly appreciate all the help. I.G.T.F.U. I made all the changes where I think I need to change to use the 2601:c4:c501:7aa0::/64 as a DHCPv6 scope on the server.
Rebooted and A) It killed the STATIC ADDRESS I tried to give to the NIC. I even tried to let the NIC on the AD/DS server grab an address and then set as an exclusion and then the same address as STATIC. Reboot and it goes back to DHCP on the NIC for IPv6. B) Still does not let me pass the tests on the test sites.
I have put pfSense back to the way it was. I will have to figure out some other way to get rid of these DNS errors on the AD/DS server.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
I truly appreciate all the help. I.G.T.F.U. I made all the changes where I think I need to change to use the 2601:c4:c501:7aa0::/64 as a DHCPv6 scope on the server.
Some times it's better to start over from scratch, allowing DHCPv6-PD to do it's thing and using SLAAC on the LAN. I wouldn't bother with a DHCPv6 server, unless you have a specific need for one.
-
@bearhntr:
Windows AD really really wants static addresses for certain things. That is gong to be very difficult in a situation where your IPv6 prefix might change. As I mentioned, there is no way to automate that on the Windows side so that it seamlessly updates the AD DHCP server scopes when your ISP changes your prefix delegation.Using AD with a DHCPv6 server works just fine when you can have a static IPv6 setup such as a tunnel from a broker like Hurricane Electric. I had that setup for several years back when I had a cable company ISP. I had a full DHCPv6 setup on my Windows AD LAN. I had no Android devices, so I was not concerned with compatibility at the time.
I agree with @JKnott here, your life will happier without trying to use a DHCPv6 server. As others have mentioned, there are some devices (looking at you Android) that refuse to use DHCPv6 so those devices would be unable to get IPv6 addresses in your network if you only had DHCPv6 on the LAN.
By the way, your errors above with the "Best Practices Analyzer" indicate that you do not have some things correctly configured in your Active Directory environment -- even IPv4 related things. So, I'm not surprised the DHCPv6 configuration is also not operating properly.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Windows AD really really wants static addresses for certain things. That is gong to be very difficult in a situation where your IPv6 prefix might change. As I mentioned, there is no way to automate that on the Windows side so that it seamlessly updates the AD DHCP server scopes when your ISP changes your prefix delegation.
If your ISP provides consistent prefixes, your addresses won't change. With SLAAC, devices on your LAN will have one consistent address and up to seven temporary addresses. You point the DNS server to the consistent address. If your AD is used only on the local LAN, then you can configure your network to use Unique Local Addresses, which won't change, no matter what your ISP does.
-
At the top :
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
ISP is Comcast - and WAN is set to DHCP/DHCP6 (with /60 prefix - confirmed with them for residential this is good) - utilizing Prefix ID '0' My COMCAST WAN IPv6 is 2001:558:6011:a5: {remainder masked} with a 128 prefix The LAN when I use Track - is 2601:c4:c501:7aa0 {remainder masked} with a 64 prefix.
To see and know what happens at the WAN side :
System > Advanced > Networking and check :
and from now on, you can see in the Status > System Logs > DHCP - look for the "dhcp6c" lines, these are from the DHCP client v6 running on your WAN, negotiating an IPv6 WAN and obtained on or more prefixes which can be used for your LAN(s).
I have a line that shows :
2023-10-16 09:03:37.031483+02:00 dhcp6c 6769 IA_PD prefix: 2a01:cb19:beef:a6dc::/64 pltime=600 vltime=1800(My stupid ISP router says it has a /56 for me - for the devices that request prefix, like pfSense. But ... my pfsense only get one /64, 0xdc hex or 220 decimal)
Because dhcp6c obtained only one prefix, I have this choice on my LAN interface :
I can select "0 out of 0" as the counting starts from prefix "0" or 0x00 to 0xff (255). This first prefix isn't 0x00 or 0, but has the number "0xdc" for me.
This prefix is used by the DHCPv6 LAN server so it can hand over IPv6 to devices that request one.
So: first things first : can you see that you (pfSense) obtained a prefix ?
Btw : What I never quit well understood :
My IPv6 LAN : 2a01:cb19:beef:a6dc:92ec:77ff:fe29:392c
Why can't I select / set it to 2a01:cb19:907:a6dc::1
or something like that. Why the random "92ec:77ff:fe29:392c" ?
-
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Btw : What I never quit well understood :
My IPv6 LAN : 2a01:cb19:beef:a6dc:92ec:77ff:fe29:392c
Why can't I select / set it to 2a01:cb19:907:a6dc::1
or something like that. Why the random "92ec:77ff:fe29:392c" ?It is most probably a SLAAC-address. See this from the online-help of my fritzbox (with vDSL).
The Assign IPv6 address FRITZ!Box randomly option works only if the FRITZ!Box determines the interface ID of your IPv6 address itself via SLAAC (Stateless Address Auto-Configuration). The interface ID is the second component of the IPv6 address. The first component is the IPv6 prefix, which is assigned by the internet provider. The interface ID is derived from the MAC address of the FRITZ!Box in accordance with the EUI-64 method.
-
@Bob-Dig
Ah, yeah, that figures.
But I'm not using a Fritz, but pfSense ;)I wonder : can I static-DHCPv6-MAC-Lease the LAN IP of pfSense itself ??
dit : euh ... what is the DUID of my 4100 igc0 LAN interface ?
-
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
But I'm not using a Fritz, but pfSense ;)
Why LAN-Interface, it is about the WAN. You could look into NPt if you want more than one subnet of IPv6. But to be honest, I haven't understand that fully either.
-
@Bob-Dig said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
But I'm not using a Fritz, but pfSense ;)
Why LAN-Interface, it is about the WAN. You could look into NPt if you want more than one subnet of IPv6. But to be honest, I haven't understand that fully either.
Ah, sorry. I haven't read your post close enough, I thought it was about the WAN-interface.
Still it would be SLAAC.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
By the way, your errors above with the "Best Practices Analyzer" indicate that you do not have some things correctly configured in your Active Directory environment -- even IPv4 related things. So, I'm not surprised the DHCPv6 configuration is also not operating properly.
Yes - that happens when I set the DNS fully back to pfSense in the AD/DS server....you get errors that indicate that pfSense must also resolve the Global Catalog and Kerberos records. It does not do this, and I was never able to get rid of those. Even on a fully functioning pfSense which is doing DNS/DHCP/DHCPv6 and no errors - which mine was. I then installed 2019 and activated the AD/DS role, which also turns on DNS I start getting those almost immediately.
I have not found a 'solid' set of instructions on how to set AD/DS with pfSense that has a walk-through setup on it. BEFORE pfSense when the Netgear ORBI was between Modem (ISP) and my network - I never saw any of that...I went with pfSense as ORBI was causing all sorts of fits with my newly installed SmartHome.
Everything that I can find on setting up pfSense to work with COMCAST (ISP) says to set WAN to DHCP and DHCPv6 - but the v6 addresses always look like SLAAC addresses. Never once has it given me an address which does not have the "MAC looking" part at the end.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
By the way, your errors above with the "Best Practices Analyzer" indicate that you do not have some things correctly configured in your Active Directory environment -- even IPv4 related things. So, I'm not surprised the DHCPv6 configuration is also not operating properly.
Yes - that happens when I set the DNS fully back to pfSense in the AD/DS server....you get errors that indicate that pfSense must also resolve the Global Catalog and Kerberos records. It does not do this, and I was never able to get rid of those. Even on a fully functioning pfSense which is doing DNS/DHCP/DHCPv6 and no errors - which mine was. I then installed 2019 and activated the AD/DS role, which also turns on DNS I start getting those almost immediately.
I have not found a 'solid' set of instructions on how to set AD/DS with pfSense that has a walk-through setup on it. BEFORE pfSense when the Netgear ORBI was between Modem (ISP) and my network - I never saw any of that...I went with pfSense as ORBI was causing all sorts of fits with my newly installed SmartHome.
You can't get rid of your Windows AD DNS server so long as you have a functioning Active Directory setup. But you can let pfSense be your DHCP server and DNS also, if you desire. But in that scenario you must configure the proper domain overrides so that pfSense will always send any DNS request for something in your AD domain to the Windows DNS server. All the clients on your network would be pointed to pfSense for DNS in that configuration. But anything they asked about pertaining to your local AD domain would be "forwarded" by pfSense to the Windows DNS server for resolution. Anything for an Internet domain would either be resolved or forwarded by
unboundon pfSense depending on how you have it configured.You would need to configure your WIndows DNS server to use itself for AD domain lookups and forward any external lookups to pfSense. You set pfSense as a Forwarder in the WIndows AD DNS configuration if doing what I described above.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Everything that I can find on setting up pfSense to work with COMCAST (ISP) says to set WAN to DHCP and DHCPv6 - but the v6 addresses always look like SLAAC addresses. Never once has it given me an address which does not have the "MAC looking" part at the end.
What you see on the WAN has nothing to do with what you need to have on your LAN. They can be different with prefix delegation in use. Quit worrying about your WAN's address. It has one, so it's good.
The reason the guides say to use DHCPv6 is because the ONLY way prefix delegation works is through the DHCP client on your pfSense box. That client reads the special prefix delegation commands and processes them. Your WAN and LAN will likely have totally different IPv6 addresses, but your ISP is taking care of routing both of those for you behind the scenes. And with prefix delegation in use, the WAN can still get its address through SLAAC.
Configure the DHCP client on pfSense to print debug messages as @Gertjan shows, then examine the DHCP tab under STATUS > SYSTEM LOGS. It will show you the IPv6 prefix that Comcast is assigning for you.
This thread has gotten quite long and has a sideline conversation in it as well, but I think I recall reading a post up near the top where you said if you let pfSense do everything (DHCP and DNS) that your IPv6 stuff worked. But this excluded your Windows AD stuff, and you wanted that in the loop with DHCPv6 on your LAN from Windows AD. Making that work is more difficult, but possible. It just will have a need for manual intervention should your prefix from Comcast change.
I think your problem with that not working is related to you not having the correct IPv6 prefix assigned as the address scope for your LAN in the Windows DHCP server.
-
I thought that I had that setup once before---I will have to go back through all the settings, or simply rebuild the AD/DS. It was fairly brand new - only had added 2x users (one for pfSense Admin and one for NAS Admin - both using LDAP). Those were working. I really wanted to use my PROXMOX box and put the pfSense and AD/DS on there - but never could them to place nice together and get to the Internet.
I am guessing that is the only way I am going to get this working.
I cleared the logs this AM and within 10 mins I am getting these again, too. I hate seeing WARNINGS and errors in the logs - makes me think that something is broken or mis-configured:
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
What you see on the WAN has nothing to do with what you need to have on your LAN. They can be different with prefix delegation in use. Quit worrying about your WAN's address. It has one, so it's good.
I am not worried about WAN - and I realize that has nothing to do with that I am trying to do. I look that as OUTSIDE THE FIREWALL stuff anyway. pfSense is the wall around the castle and the draw bridge is WAN.
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
I think your problem with that not working is related to you not having the correct IPv6 prefix assigned as the address scope for your LAN in the Windows DHCP server.
I have done this numerous times before ever coming here for help. I would take the IP Address that COMCAST (with Track Interface) to my LAN - and setup the DHCPv6 scope on the AD/DS server to use the first 4 hex blocks (and ::1/64) as the rest of it. Things still never worked right.
Looks like today I was able to FORCE COMCAST to give me a new prefix completely.... lol. I set WAN to SLAAC .. SAVED and applied. I did indeed get an address, and it changed
from 2601:c4:c501:7aa0: to 2601:c4:c501:8bf0: the rest of the address is the same.
I then changed it back to DHCP6 and for now have the PD set to 64 - I do not really have a need for the others until get this working and figure out how to put WIRED and WIRELESS on separate segments. The box that pfSense is running on (an HP t620+ ThinClient has built in wireless - which I disabled in the BIOS).
-
Thanks again for all the help. I am going to leave the IPv6 stuff to pfSense and re-build my DC (I have learned that once you enable something in Windows for a DC - turning it OFF does not always un-do the changes ... gotta love MS). I found an old posting of yours (below) and wonder if you can help me do this with my setup:
Using pfSense as firewall and Windows Server as DHCP and DNS server
@bmeeks Oct 13, 2021, 10:16 AMIf you have an Active Directory setup on your Windows server, then you absolutely need to use Windows for DHCP and DNS (especially DNS as the unbound DNS daemon on pfSense is really not suitable for Active Directory).
So here is what I suggest:
Use Windows for DHCP and DNS. Configure DHCP on your Windows Server to handout the Domain Controller as the DNS server for all clients.
In the Windows DNS setup, you have two options. Let Windows DNS act as a resolver, or have Windows DNS forward non-local lookup requests to either pfSense or an external DNS provider like Cloudfare, Google, OpenDNS, etc. I prefer to let Windows DNS resolve. There are several Google tutorials for how to configure that in Windows.
Over on the pfSense box, you can leave the DNS setup at the out-of-the-box defaults. Don't put any IP addresses for DNS in the SYSTEM > GENERAL SETUP page.
There are two things you want to configure on the DNS Resolver tab under SERVICES > DNS RESOLVER. First, in the Custom Options box you need to provide the name of your Windows AD domain like so --
server:
private-domain: "yourdomain.tld"
Second, you will want to configure two domain overrides so that pfSense will know to contact your Windows DNS server when it wants to resolve the IP address of any local hosts, or if it wants to perform a reverse pointer lookup on a local IP. So configure one domain override for your domain name and point to your Windows DNS server as the authoritative server for the domain, and configure a second override for the *.in-addr.arpa reverse IP pointer range.These DNS overrides are necessary so that pfSense can find your local host names if you do things like perform lookups on firewall log entries or view the ARP table. The overrides tell pfSense which DNS server is authoritative for your domain and reverse IP pointer range.]
This sounds like what I want to do. I have my own 'domain' regsitered with CloudFlare and I would like to use that on AD/DS. Is that doable?
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
I have my own 'domain' regsitered with CloudFlare and I would like to use that on AD/DS. Is that doable?
No, you generally can't do this because the IP addresses are different. Your Windows AD domain controller is behind your firewall on private RFC1918 address space. Your Cloudfare hosted domain has a public IP. That can't work for Active Directory without jumping through a lot of advanced hoops to configure what is essentially a split-DNS setup.
The correct way to handle this is to use a separate sub-domain for your internal AD setup. Something like
mydomain.comfor the public IP domain name andinternal.mydomain.comfor the Windows AD network in RFC1918 space. That can work. A quick Google search will lead you to a Microsoft best practices and how-to article on this configuration. I highly recommend you restructure you AD configuration to match what is described at this older Microsoft link here: https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx. And here is a slightly newer document showing the same thing: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10).My older post you referenced was assuming the network was IPv4 only with no IPv6 in use. You want to use IPv6, but your ISP is not guaranteeing you a static assignment (they use prefix delegation which means the IPv6 space might change unexpectedly). That's going to be an issue unless you use both ULA and GUA IPv6 addresses. My post also assumed that your Active Directory domain was never going to be accessed from outside. Sounds like that is not what you intend as you mentioned somewhere up above about using some type of home automation with LDAP authentication I believe (unless I'm confusing this thread with another one).
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
The correct way to handle this is to use a separate sub-domain for your internal AD setup. Something like mydomain.com for the public IP domain name and internal.mydomain.com for the Windows AD network in RFC1918 space. That can work. A quick Google search will lead you to a Microsoft best practices and how-to article on this configuration. I highly recommend you restructure you AD configuration to match what is described at this older Microsoft link here: https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx. And here is a slightly newer document showing the same thing: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10).
Thanks for the links - one of them I had looked already (as a Google search pointed to it). My public domain name has a - {dash} in it, and apparently my old ass NAS does not like that. I have tried and tried to get it to recognize the domain-name that I first setup as ad.{mypublicdomain} - even a chat session with them for over an hour (nothing worked - they plan no updates to it. It also only does CIFSv1/SMBv1 - FTP (no sFTP) and NFS (but only to Linux boxes) - and some form of iSCSI. I have over 6TB of files and stuff on there, and they "SEAGATE" is not even willing to 'help' me with another NAS to replace it. One of my IT buddies said I should use {mypublicdomain}.loc for my AD/DS...but still going to resolve the - {dash} in there unless I remove it completely. I have considered creating (renaming my public-facing-domain) as only HomeAssistant uses it (well their app on my phone and the ALEXA and GOOGLE links do too).
My older post you referenced was assuming the network was IPv4 only with no IPv6 in use. You want to use IPv6, but your ISP is not guaranteeing you a static assignment (they use prefix delegation which means the IPv6 space might change unexpectedly). That's going to be an issue unless you use both ULA and GUA IPv6 addresses. My post also assumed that your Active Directory domain was never going to be accessed from outside. Sounds like that is not what you intend as you mentioned somewhere up above about using some type of home automation with LDAP authentication I believe (unless I'm confusing this thread with another one).
Pretty much what I am going to. Every guide that I have read says not to DISABLE the IPv6 on a DC. I am going to leave it at its default settings and let pfSense take care of it. Same for DHCPv4 - going to only do DNS on AD/DS and I am guessing that pfSense is RESOLVER with the FORWARDING option turned on. I would also need a Domain Override setup to point to AD/DS name and IPv4 address as well. Still trying to grasp the REV LOOKUP (setup in pfSense) thing and the HOST OVERRIDE too.
The LDAP stuff that I want to do is not really for Home Automation, per se. I do have HomeAssisitant - what I want to do is sign-ins to the various parts with LDAP credentials so that I do not have to keep up with (currently 22) separate login accounts. All of that stuff is 'inside' my pfSense Firewall - only Alexa and Google can access from outside and their app. I got that working, and hoping that I do not have to go through that again. WHEW!!!
