pfSense 2.5.2 - Web Console super slow
-
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
@bmeeks said in pfSense 2.5.2 - Web Console super slow:
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
In your case, something is preventing your IPv6 clients on your LAN (where the Windows AD network resides) from talking to each other. I assume you have the virtual machine that is your AD controller on the same subnet as the Windows client you provided the screenshot of. Is that correct?
All of my machines - everything in the house has an IP address 192.168.10.xxx
AD DS (static 192.168.10.250 / 2601:c9:200:60e::250 /64)
pfSense (statis 192.168.10.254) / 2601:c9:200:60e::254 /64)
ORBI AP (Main) (static 192.168.10.1) does not do IPv6 in AP mode
ORBI AP (Sat) (static 192.168.10.2) does not do IPv6 in AP modeWell, that is going to cause you issues I think. That would mean anything in your home on wireless (using the APs, I presume) would be unable to speak back and forth using IPv6. Since Windows will always prefer IPv6 when it is enabled, then anything Windows that is wireless will first try IPv6, wait for it to fail, and only then try IPv4. That will be very slow.
If you have a non-IPv6 capable WiFi setup, then you most certainly will want to remove all the IPv6 stuff you have configured and just stick with an IPv4 network.
It would have been helpful if this wireless limitation had been shared early on.
-
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
AD DS (static 192.168.10.250 / 2601:c9:200:60e::250 /64)
That may be the case for the server but as bmeeks alertly pointed out above the Windows client does not have a /64:
...which is likely due to using DHCPv6 from Windows Server as I mentioned.FWIW we have many clients using IPv6 and Windows just fine. Let the router handle IPv6, get rid of DHCPv6 on Windows Server, and set up a host override on pfSense so your example.lan domain is directed to the AD DNS server.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
Clarification - the ORBIs will 'pass' IPv6 information -- they will just not "get" an IPv6 address or even show one for the devices on the network. Only the IPv4 addresses show:
-
@bearhntr
That would make me a little nervous trusting them to correctly handle IPv6 traffic -- but that's just me. Perhaps they do it well. I'm not familiar with that AP brand having never used them.But going back to what @SteveITS says, your Windows clients (not the AD server, but the clients themselves) getting /128 prefix values is going to be problematic. Try as he says and let clients get their IPv6 setup from
radvd. There is a Netgate document describing this here: https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6-ra.html. -
@steveits said in pfSense 2.5.2 - Web Console super slow:
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
AD DS (static 192.168.10.250 / 2601:c9:200:60e::250 /64)
That may be the case for the server but as bmeeks alertly pointed out above the Windows client does not have a /64:
...which is likely due to using DHCPv6 from Windows Server as I mentioned.FWIW we have many clients using IPv6 and Windows just fine. Let the router handle IPv6, get rid of DHCPv6 on Windows Server, and set up a host override on pfSense so your example.lan domain is directed to the AD DNS server.
I am fine with that - but what do I need to turn on in pfSense to handle that?
-
@bmeeks said in pfSense 2.5.2 - Web Console super slow:
@bearhntr
That would make me a little nervous trusting them to correctly handle IPv6 traffic -- but that's just me. Perhaps they do it well. I'm not familiar with that AP brand having never used them.But going back to what @SteveITS says, your Windows clients (not the AD server, but the clients themselves) getting /128 prefix values is going to be problematic. Try as he says and let clients get their IPv6 setup from
radvd. There is a Netgate document describing this here: https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6-ra.html.The ORBI is a NETGEAR wireless router and satellite kit. They can operate in ROUTER mode (which pfSense is now doing) or in AP mode (where it is set now). Plans are - as soon as this 'limited supply' issue is resolved - is to install a UBIQUITI (UniFi) network at the house.
-
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
@steveits said in pfSense 2.5.2 - Web Console super slow:
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
AD DS (static 192.168.10.250 / 2601:c9:200:60e::250 /64)
That may be the case for the server but as bmeeks alertly pointed out above the Windows client does not have a /64:
...which is likely due to using DHCPv6 from Windows Server as I mentioned.FWIW we have many clients using IPv6 and Windows just fine. Let the router handle IPv6, get rid of DHCPv6 on Windows Server, and set up a host override on pfSense so your example.lan domain is directed to the AD DNS server.
I am fine with that - but what do I need to turn on in pfSense to handle that?
Have a look at the steps in this document: https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6-ra.html.
What you want to do is enable the use of SLAAC instead of DHCPv6. That happens when you enable the router advertisement daemon (
radvd) and choose an appropriate Router Advertisements Mode option. You can experiment to see which mode works best for you. I suspect "Stateless DHCP" might be what you want to use in order to provide a DNS server IP to your clients. -
I used that link - found in another search for COMCAST, IPV6 and PFSENSE. I appear to be getting IPv6 addresses to my devices. Some of them (like ANDROID and AMAZON devices - require a reboot to get these). Will do that later.
I have it enabled now as follows:
Also it appears that my IPv6 is working - based on this site --
-
I just gotta get passed this one:
As I have these rules set:
-
Break your ICMP rules on the WAN into separate rules for IPv4 and IPv6. Don't use the "IPv4+6" choice. Instead, create a rule for IPv4 ICMP traffic and then a separate rule for IPv6 ICMP traffic.
See the post here: https://potatoforinter.net/553/centurylink-ipv6-with-pfsense/.
-
I used to have a single ICMP rule for IPv4+IPv6 and it was as follows (it is still there - just disabled). When I was using that (before attempting to do the AD DS stuff - I would get a 19/20 from here: https://ipv6-test.com/
COMCAST (my ISP - does not yet set or use hostnames in the IPv6 realm for residential customers).
-
@bearhntr
Not sure you are understanding what I meant. In the ADDRESS FAMILY box, do NOT choose "IPv4+IPv6". Instead, create separate sets of rules for each protocol. So a set of rules where ADDRESS FAMILY is set for "IPv6" only, and then a set where ADDRESS FAMILY is set for "IPv4" only. For each family of rules you will choose ICMP in the PROTOCOL drop-down.In this link I posted earlier: https://potatoforinter.net/553/centurylink-ipv6-with-pfsense/, scroll down to #8 and read and follow those steps. Notice how it explicitly says "(don’t select IPv4+6 with ICMP – weird things happen)".
Also realized a bit later after my initial post above that the firewall on your testing client might be interfering. Windows by default will block unsolicited external traffic using the Windows Defender Firewall. External in your case would be the Internet. And with IPv6, there is no NAT usually, so your Windows client's IPv6 LAN address is exposed to the Internet. So that test site is going to attempt to ping the IPv6 address of your testing client (I assume that's a Windows machine). So you may have to put a firewall rule in place on the Windows machine to allow unsolicited inbound IPv6 if you want to pass the test.
-
I understood -- I have not gone through that 'potato' article yet.
I rebuilt my AD DS - got rid of the ESXi and move it back to a stand-alone server. I am still setting that back up - updates and such....then I am going to decide if I am going to do the AD DS stuff again - or just let the pfSense handle it all.
-
-
Thank you both for your assistance. Things appear to be back to the way they were before I tried to bring a Domain Controller into the mix. I still want to do that - but thinking I am going to let pfSense handle the Internet and DNS.
I guess I will have to do a little more research as how to do that - so as to prevent the IP BATTLE which is pfSense and Windows Server 2019 AD DS. LoL
I will keep looking for a setup guide, as I am sure that I am not the only one to have done this.
-
@bearhntr In the DNS Resolver "Domain Overrides" section add a line for your domain and each DC:
example.lan 192.168.0.2
example.lan 192.168.0.3Then any request for example.lan is forwarded to one of those two IPs.
and optionally for reverse:
0.168.192.in-addr.arpa 192.168.0.2
0.168.192.in-addr.arpa 192.168.0.3 -
Not following -- are your suggestions "should I decide to make a new Domain Controller" ??
I just find it so 'strange' that when I did this before (when Netgear ORBI was my router, DNS and DHCP) - I never had a problem. Perhaps it has logic in place to handle the IP Head-Butting. LOL
My goal (when I can get the UNIFI stuff I want) to remove the Netgear ORBI all together and install the Ubiquiti system for Wireless, etc. But, I have read someplace that I could do away with pfSense too with that system.
-
@bearhntr I thought you were asking how to get DNS functioning for your Windows domain, while using pfSense as a DNS server for IPv6. The options are: 1) don't, or 2) have pfSense forward requests for the Windows domain to the Windows DNS server, or 3) use only Windows DNS and have it forward all requests to pfSense.
The challenge with Windows AD is that when using Windows DNS under IPv4 and pfSense DNS under IPv6, pfSense doesn't know the Windows AD zone exists.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@steveits said in pfSense 2.5.2 - Web Console super slow:
The challenge with Windows AD is that when using Windows DNS under IPv4 and pfSense DNS under IPv6, pfSense doesn't know the Windows AD zone exists.
Unless you do as both @SteveITS and I have suggested and put the appropriate domain overrides and reverse pointer zones in the DNS Resolver options on pfSense so that it knows where to go (the Authoritative server) for DNS lookups related to your AD domain and local LAN IP space.
The bottom line here is that IF you want to use Windows AD and have some of your LAN clients be domain members, then you MUST let Windows AD do the DNS (and probably DHCP) stuff. You will never have good luck trying to run Active Directory with only
unboundas your DNS server running on pfSense.But if you abandon the use of Active Directory, then certainly it can be easier to use the default
unboundsettings in pfSense for DNS in your network. -
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
I just find it so 'strange' that when I did this before (when Netgear ORBI was my router, DNS and DHCP) - I never had a problem. Perhaps it has logic in place to handle the IP Head-Butting. LOL
But when you had this "other" working setup did you also have an Active Directory domain in use with your Windows clients all being domain members? If you did, and were not using AD DNS, then I really don't see how it worked properly. If you did NOT have AD in place, then most certainly the old setup would have been fine.
The use of Active Directory in the mix is what makes the setup more complicated. That's because Microsoft's AD configuration creates "stuff" that most DNS servers don't tolerate in their configuration. Thus you generally are forced to use the Microsoft AD DNS server when you set up an Active Directory environment. That in turn makes the overall configuration of DNS (and DHCP, if you use it) more complicated and nuanced.
You really have to understand how it all works together so you can get the pieces configured correctly. It most definitely does work just fine when correctly configured. I am using that setup now, and before I was switched over to CGNAT by my ISP, I had a functioning Hurricane Electric IPv6 tunnel setup working just fine with routable IPv6 addresses in my LAN and in use by my Windows clients and servers. I could pass the IPv6 test sites with no issue. Once I got moved to CGNAT and lost the ability to use my Hurricane Electric tunnel, I had to dismantle the IPv6 stuff.
