pfSense 2.5.2 - Web Console super slow
-
Yes -- When I do this from the domain controller -- it comes back within a second.
From the other Windows machines -- I get this:
They have not been joined to the domain.. but they are pulling an IP address from the DHCP on the AD DS and the network configs look correct for GW, SNM and DNS.
This is one of the Windows boxes (not the AD DS)
-
@bearhntr Seems like your server isn't responding to DNS on its ::250 address, except to itself. Is its firewall blocking IPv6?
That shouldn't affect the pfSense GUI at all though.
-
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
Yes -- When I do this from the domain controller -- it comes back within a second.
From the other Windows machines -- I get this:
They have not been joined to the domain.. but they are pulling an IP address from the DHCP on the AD DS and the network configs look correct for GW, SNM and DNS.
This is one of the Windows boxes (not the AD DS)
Isn't the subnet on the Windows client's IPv6 address incorrect? Been a while since I've used IPv6 in my domain due to being put behind CGNAT by my ISP, but the IPv6 subnet should be /64 instead of /128, I believe. An incorrect subnet mask would explain why your clients are unable to talk to the AD DNS server.
-
@bmeeks said in pfSense 2.5.2 - Web Console super slow:
Isn't the subnet on the Windows client's IPv6 address incorrect?
Yes. So, the PC can't talk to anything else over IPv6.
If one configures DHCPv6 on Windows, it does that. Also Windows DHCPv6 doesn't configure a gateway, because that's not how IPv6 was designed to work. In summary, many years ago I banged my head on it for a while and decided it was pointless trying to use Windows DHCPv6, and to just let the router handle IPv6, as designed. Then set pfSense to use a domain override to forward those DNS requests to the local AD DNS as discussed.
-
I do not see anything in the firewall specifically blocking IPv6. So far the Windows devices that I have powered on - do get an IPv4 and v6 address from the DHCP server on the AD DS box - and most times they make an entry in the DNS table as well.
I just tried 2 other Windows boxes - they grabbed an IPv4 and v6 address --- but NSLOOKUP to a domain name (amazon.com / cnn.com / comcast.net) all fail on them as well. But work from the AD DS box with no problem.
It makes no sense. All of the boxes are getting an IPv6 address in the scope that I configured.
-
@bearhntr said in pfSense 2.5.2 - Web Console super slow:
I do not see anything in the firewall specifically blocking IPv6. So far the Windows devices that I have powered on - do get an IPv4 and v6 address from the DHCP server on the AD DS box - and most times they make an entry in the DNS table as well.
I just tried 2 other Windows boxes - they grabbed an IPv4 and v6 address --- but NSLOOKUP to a domain name (amazon.com / cnn.com / comcast.net) all fail on them as well. But work from the AD DS box with no problem.
It makes no sense. All of the boxes are getting an IPv6 address in the scope that I configured.
The firewall does not come into play at all when two clients on the same L2 network want to talk to each other. They do so directly via the switch fabric (port to port within the Ethernet switch). The firewall is not part of the conversation at all UNLESS the clients reside in different subnets.
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?
-
When the IPV6 scope was created - it was created as /64 -- I do not know why Windows shows the 2601: address as /128 (for addresses handed out from DHCPv6).
As I stated - I think I am just going to bite the bullet and start everything over from scratch. I hate to do this - as the CloudFlare stuff in pfSense was a 'bee-atch' to get working...but thank goodness I have notes of what I had to do.
I will forget setting up AD DS to do IPv6 - as it appears that Windows still has issues with it. Been fighting with it for almost 2 years - where something will flip in the background and everything I have set as STATIC in IPv6 will go back to "auto-configure".
I am thinking that there is a setting still pfSense - that I cannot remember setting or is "not really" turning off - causing some of this.
I will just build a new pfSense instance using the latest....and leave everything at the default - except the FIREWALL (and DDNS) so that my HomeAssistant (SmartHome) will work.
As much as I do not like the idea - I will just let pfSense handle the DNS and DHCP - as apparently I am too stupid to get the AD DS to do what I want it to do.
-
@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 mode -
@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.
-
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.