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

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.

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 👍

@stephenw10
Thx a lot Steve this was a very good overhaul for me and a good thing to me understand more this. Helped me a lot and thx to show whre was the errors I couldn't figured out.

And yes this is a very old hardware that no one never maintain the hardware.

Vitor

Hmm, seems like it didn't upgrade completely and was still referencing some older modules.

If you reinstall Wireguard I'd expect it to work.

Steve

@stephenw10
Strange things can happen. Computers...

Simply reducing the notifications will certainly help.

2.7 is in Beta and it's looking good. So unless something show stopping is found I would anticipate 'weeks'. Hard to be more accurate than that.

Steve

@stephenw10 said in Crash Report:

arp: packet with unknown hardware format 0x06 received

Something on LAN is sending bad packets. You should find out what that is and stop it if you can. However that shouldn't cause a kernel panic.
https://forum.netgate.com/topic/152050/arp-packet-with-unknown-hardware-format-0x00

With php core dumping like that I would expect to see some errors in the system log? Whatever else is happening at that time could tell us something.

Steve

@stephenw10 I could not use chatgpt and may have done a poor job of translating, but before the L2 switch was installed, I would wake up from sleep or reboot and the connection would stay online or be disconnected. The gateway was not up (the network icon was an X) and 192.168.1.1 was also not connectable.

I have been trying to put an L2 switch in between and so far the connection never seems to get disconnected. I will keep an eye on the status a little longer.

Translated with www.DeepL.com/Translator (free version)

Yup, rules are applied per interface. Interfaces can be (are usually) a single port.

Exceptions to that would be, for example, VLANs where one port can carry multiple interfaces or bridges where one interface can span several ports.

Steve

Hmm. It still seems like unexpected/unwanted behaviour on an internal interface. We should look at it anyway.

Mmm, that is old but still. One 3GHz core would usually be enough. If it's actually running at 3GHz....

Thanks for the replies everyone, I was able to fix the issue last night. I did end up reviewing and trying out proxmox instead of VMware Workstation, and was able to get it working.

I'm not exactly sure what the issue was, but I think there was an issue with how i set up the network interfaces on the VMware. On proxmox i wasn't able to reach the gui at first from the PC connected to the LAN port, which made it more clear what to look for when debugging the problem. When running VMWare on windows I was able to connect to the GUI from the PC running VmWare, which I think was causing me to misdiagnose the problem.

Eventually got it working on Proxmox and noticed I had the gateways misconfigured on the client, which could have been the issue on my setup with VMware Workstation.