pfSense 2.5.2 - Web Console super slow

SteveITS

@bearhntr DNS needs to function on pfSense itself, or it will time out checking for updates and whatnot. DNS Resolver probably doesn't need to be running, per se, but I expect DNS servers would need to be configured in System/General, and "Use remote DNS Servers, ignore local DNS" selected.

I skimmed the thread and it looks like you have domain overrides set up for the domain. They aren't going to work if DNS isn't running. And aren't really necessary if no devices use pfSense for DNS.

Which DNS is used is dependent on the client's list of DNS servers. We can get into that in the other thread but generally on an AD domain the PCs use the DCs, and the DCs can use root servers or forward to pfSense or whatever else. If the devices use pfSense for DNS then it needs to forward requests for the AD domain to the DCs.

bearhntr

@steveits

OK - I went here and added these settings - seems to have improved things:

bmeeks

@bearhntr
I helped you in your other thread. I think you misunderstood something I was trying to convey over there.

I had you temporarily disable DNS Resolver as part of some troubleshooting on a client (when that client seemed to be using pfSense when it should not have). I did not mean to leave DNS Resolver permanently disabled on pfSense!

pfSense itself always needs a DNS server defined. That server can either be the local DNS Resolver (unbound) or the older and deprecated DNS Forwarder (dnsmasq). Or you can specify some other DNS server on the DNS Settings section of GENERAL SETUP.

bearhntr

@bmeeks said in pfSense 2.5.2 - Web Console super slow:

@bearhntr
I helped you in your other thread. I think you misunderstood something I was trying to convey over there.

I had you temporarily disable DNS Resolver as part of some troubleshooting on a client (when that client seemed to be using pfSense when it should not have). I did not mean to leave DNS Resolver permanently disabled on pfSense!

pfSense itself always needs a DNS server defined. That server can either be the local DNS Resolver (unbound) or the older and deprecated DNS Forwarder (dnsmasq). Or you can specify some other DNS server on the DNS Settings section of GENERAL SETUP.

I realize that you were helping me - and I appreciate it. I was following you, and did not recall seeing that I should re-enable to the DNS Resolver in pfSense once I tested the DNS features in AD DNS.

I am seriously considering putting pfSense back the way it was and doing away completely with the AD DS server in that role - Today.... everything is CRAWLING AGAIN that touches the Internet.

bmeeks

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

@bmeeks said in pfSense 2.5.2 - Web Console super slow:

@bearhntr
I helped you in your other thread. I think you misunderstood something I was trying to convey over there.

I had you temporarily disable DNS Resolver as part of some troubleshooting on a client (when that client seemed to be using pfSense when it should not have). I did not mean to leave DNS Resolver permanently disabled on pfSense!

pfSense itself always needs a DNS server defined. That server can either be the local DNS Resolver (unbound) or the older and deprecated DNS Forwarder (dnsmasq). Or you can specify some other DNS server on the DNS Settings section of GENERAL SETUP.

I realize that you were helping me - and I appreciate it. I was following you, and did not recall seeing that I should re-enable to the DNS Resolver in pfSense once I tested the DNS features in AD DNS.

I am seriously considering putting pfSense back the way it was and doing away completely with the AD DS server in that role - Today.... everything is CRAWLING AGAIN that touches the Internet.

Some things to check while it is slow.

Verify DNS lookups are actually succeeding on clients. Open a Command Prompt session on a Windows client and run this command:

nslookup cnn.com

Make sure it quickly comes back with a list of IP addresses for that domain.

Next, verify that your IPv6 prefix has not changed (assuming you are getting some kind of delegated prefix from your ISP if they are providing IPv6). If your WAN cycled up and down for some reason, that could result in you getting a new and different IPv6 prefix. If that happens, the IPv6 addresses you have hardcoded in places for the AD DNS server would be incorrect. That would manifest as DNS lookup failures and result in the Internet appearing to be "slow" because domain name lookups would have to time out and then fallback to IPv4, for example.

In short, do some testing to see if DNS lookup failures are the cause of the slowness. If DNS is working well,, then we can look elsewhere.

bearhntr

@bmeeks

Even while it was slow - NSLOOKUPs appeared to be working. I am just not sure where/what is resolving them. They were a little slow - but always came back.

I considered resetting the pfSense to FACTORY - or doing a fresh install of 2.6.0 and leaving it at the defaults....but afraid that I might make it worse.

Seriously considering a reload of the AD DS box (on a stand-alone server rather than a VM). The VM - something keeps peaking out the CPU and it will run at 95-100% CPU for hours. It is not a 'true server box' but has a CORE i7-3770 CPU with 32GB RAM. The AD DS VM is set to use 16GB of the RAM - and there are 3 other VMs there - but I only turn them on as I need them.

I may just make the whole box a Server 2019 box, and use HyperV for my VMs (they are just test boxes). The problem going that route - is that I would have to have pfSense be my Router/DNS/DHCP again while I rebuild. Then I would have a fresh pfSense reload, and figure out how to best configure it - and ease of then putting the AD DS back into play.

It is a P.I.T.A. that I have to work at home and deal with setting up these lab stations
"on my dime".

SteveITS

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

NSLOOKUPs appeared to be working. I am just not sure where/what is resolving them

Usually it tells you with a "Server" and "Address" line before the answer. :)

Server: dns.google
Address: 8.8.4.4

Non-authoritative answer:
Name: netgate.com
Addresses: ...

I think you need to differentiate between pfSense being slow (this thread?) and other issues.

pfSense GUI can be slow if it can't resolve DNS. It and/or other devices can seem slow if they work through DNS servers waiting for them to time out. Windows hides this a bit because it uses the "last known good" DNS server first and doesn't go in order, unlike other OSs. 4 DNS servers (3 not working) with 2 seconds of timeout is 6 seconds to get to the last one.

bmeeks

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

@bmeeks

Even while it was slow - NSLOOKUPs appeared to be working. I am just not sure where/what is resolving them. They were a little slow - but always came back.

I considered resetting the pfSense to FACTORY - or doing a fresh install of 2.6.0 and leaving it at the defaults....but afraid that I might make it worse.

Seriously considering a reload of the AD DS box (on a stand-alone server rather than a VM). The VM - something keeps peaking out the CPU and it will run at 95-100% CPU for hours. It is not a 'true server box' but has a CORE i7-3770 CPU with 32GB RAM. The AD DS VM is set to use 16GB of the RAM - and there are 3 other VMs there - but I only turn them on as I need them.

I may just make the whole box a Server 2019 box, and use HyperV for my VMs (they are just test boxes). The problem going that route - is that I would have to have pfSense be my Router/DNS/DHCP again while I rebuild. Then I would have a fresh pfSense reload, and figure out how to best configure it - and ease of then putting the AD DS back into play.

It is a P.I.T.A. that I have to work at home and deal with setting up these lab stations
"on my dime".

If you have that kind of CPU load for hours, then something would obviously be "not optimal".

As @SteveITS says, slow DNS lookups can present as a stalled Internet experience because everything runs on hostnames/domain names that need to be resolved. But that may not be the only issue you have. That high CPU loading bears investigation as well. Is the VM trying to do some series of updates? Is there a disk I/O bottleneck perhaps? If the VM with that CPU utilization is your AD DNS host, then name resolutions could definitely be impacted.

The pfSense GUI (especially the landing or home page) attempts to perform a DNS lookup when checking for the most recent version. If DNS is sluggish, ,then the display of the home page is sluggish. But not every action you take in the pfSense GUI results in a DNS lookup. In fact, most do not. So is the pfSense GUI slow everywhere no matter when menu section you are on, or is it only slow when on the "home page" dashboard?

bearhntr

@bmeeks

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)

SteveITS

@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.

bmeeks

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

@bmeeks

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.

SteveITS

@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.

bearhntr

@steveits

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.

bmeeks

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

@steveits

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?

bearhntr

@bmeeks

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.

bearhntr

@bmeeks said in pfSense 2.5.2 - Web Console super slow:

@bearhntr said in pfSense 2.5.2 - Web Console super slow:

@steveits

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

bmeeks

@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:

@steveits

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

Well, 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.

SteveITS

@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.

bearhntr

@bmeeks

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:

bmeeks

@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.