@gbn1987 not sure what your trying to do, clients don't normally use dot, ie 853 - clients normally use doh so not sure what your trying to do.. if you want clients to ask pfsense for dns over normal 53, and then have it forward to clouldflare over tls (dot 853).. That would be setup like this. https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html

@stephenkwabena yeah that would mean its working - if you can not resolve www.google.com for example then no you would never create a state.. When you can not browse - validate that you can resolve the fqdn your trying to go to. If not then no its never going to work, if you get an IP for the fqdn your trying to go to. Then check you states.. If you see say syn sent, but no answer then were you trying to go didn't answer and problem is upstream, etc.

@ChrisLynch This thread was specifically about a bug in pfBlocker that is long since fixed. I’d suggest a new thread and look at the output of Diagnostics/System Activity or “top” at a command line to see what’s using CPU.

@viragomann so how my home assistant works is pfsense === >dhcp ===> (main server)unraid server(HA VM) gets 192.168.0.12 and has the hostname homeassistant inside the software pfsense === >dhcp ===> (backup server)unraid server(HA VM) gets 192.168.0.10 and has the hostname homeassistant2 inside the software i dont do host override etc and thats how i access home assistant http://192.168.0.12:8123 or http://homeassistant:8123 ok i set the host over ride to homeassistant.home in the dns resolver [image: 1687641596160-issure1.jpg]

Hmm, you might try adjusting the dhcp protocol timing options in the advanced DHCP config options. We have seen edge cases where a modems boot time hit's pfSense's still booting WAN and the client ignores it. Steve

@kn4thx this might help with the DoH: https://github.com/jpgpi250/piholemanual/blob/master/doc/Block%20DOH%20with%20pfsense.pdf

@nanoken said in Is pfSense blocking Outlook login (TPM)?: may as well blame pfsense for Covid it’s that unrelated. I wouldn't be surprised to be honest that someone prob has blamed it ;) It was routing their 5G connection and brought it into the house - what is the good of firewall that can't filter out the covid from the 5G signal.. hehehehe

@stephenw10 Yes, using 2 different models of CyberPower UPSs (SL700U & CP425SLG) and have been experiencing this flapping since the 2100s were new with v22.05 - 6mo ago. I removed the Nut package shortly after the install when these disconnects were causing the instability of Nut. They are both HID compliant and I was using the usbhid-ups driver with Nut, but it still was flapping. As mentioned, I have them connected to a Raspberry PI with Nut and usbhid-ups driver and it is working great (see pic). [image: 1687473007497-screenshot-2023-06-22-152945.jpg] In case you're interested, I saved this output. When it disconnected, the UPS device didn't show in a usbconfig listing. [23.05-RELEASE][jonsmall@pfSense-rider.home.lan]/home/jonsmall: sudo usbconfig ugen0.1: <Generic XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: <Marvell EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: <CPS ST Series> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (50mA) [23.05-RELEASE][jonsmall@pfSense-rider.home.lan]/home/jonsmall: sudo usbconfig -vd ugen1.2 ugen1.2: <CPS ST Series> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (50mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x0764 idProduct = 0x0501 bcdDevice = 0x0001 iManufacturer = 0x0003 <CPS> iProduct = 0x0001 <ST Series> iSerialNumber = 0x0000 <no string> bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0022 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes = 0x00a0 bMaxPower = 0x0019 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 <HID device> bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0000 <no string> Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x10 RAW dump: 0x00 | 0x09, 0x21, 0x10, 0x01, 0x21, 0x01, 0x22, 0x5f, 0x08 | 0x02 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0008 bInterval = 0x000a bRefresh = 0x0000 bSynchAddress = 0x0000

@stephenw10 Thanks for reply. I was also informed on redline last night.

Hmm, bizarre! Glad it was solved.

Mmm, is that in line with what you get when connected directly? I agree WAN1 and WAN2 should be identical. I would still test using one of the igc NICs as WAN if you can. If there's some low level issue with the ix NIC/driver the igc NIC may not hit that. Steve

Yes, by default the gateway monitoring pings the gateway IP. It's entirely possible the gateway stopped responding to ping at that time or was under some far greater load causing it to add latency but was still routing traffic through it no problem. Replying to pings is usually very low priority! You should set the gateway monitoring to something further upstream like 8.8.8.8 or your ISPs DNS server to get a better idea of real connectivity. Steve

@nelox - for me it doesn't work at all, but maybe because I have a locked down vlan set up with default drop. Specifically, my controllers on vlan A are whitelisted and can see and connect to anything on vlan B (where the Sonos players are). So technically there's no need to open ports from controller to Sonos Players. My issue is the other way around. When you open the app and it goes through the multicast discovery, the Sonos player try to respond back via UDP to the controller. But unless I explicitly allow this UDP traffic from Player to Controller, it won't work, and I can see it in my logs. And given UDP is stateless, pfSense can't use the connection state, so unless I have an explicit rule, it won't work. I tested this extensively, and in my case Sonos players usually use UDP source port in the 35000-42000 range, so that's what I used to allow traffic in pfSense. Caveat that I'm not using UPnP, so maybe that explains the difference.

@stephenw10 Yes it is. And I disabled vmware virtual network local dhcp ANd it works. Thank you for your patience ! You really helped me out on this, have a nice day/night [image: 1687387415421-c3e53068-4ad2-4014-9e91-1c1ec4ab18d3-image.png]

@jfish said in new set up download very slow: Broadcom Xtreme 4 port NIC PCI-X Actually PCI-X? Very unsual these days. But should still pass way more than that. Do you see errors on either interface in WAN or LAN? How are you testing? I assume you mean 1G down and 100M up? Have you confirmed that by connecting directly? Steve

Hard to say. Check the system log. If the Orbi stops allowing connections because it loses it's DHCP lease or has DNS issues then I'd check those logs.

@dedskwirl also, apparently a .1 upcoming: https://docs.netgate.com/pfsense/en/latest/releases/23-05-1.html "Fixed: PHP error when attempting to bulk import Alias content #14412"

@stephenw10 said in MS RDP traffic problems after upgrading to 2.6.0 (with no MS RDGateway involved): Azure is not affected because it doesn't support RSC Funny how that works.

Ill just leave this here for all the haters. [image: 1687374183692-19fa718b-e461-4373-82cf-01de284b2e63-image.png]

I found !!!! The problem was with the latest version of the ubiquiti interface! Thanks to this message https://community.ui.com/questions/Can-not-deactivate-Traffic-Restriction-on-one-Port/0175f236-05a4-4a79-bfda-9348dd42f94f I deduced a possible cause. You "just" have to put the two interfaces on the same port, it looks like a bug ... because it's illogical to have to create a false VLAN just to be able to assign the right ..... days lost just for these problems. MANY THANKS TO ALL THE USERS WHO TRIED TO HELP ME