@stephenw10
Lost again - hopefully you will have time / energy to help:

As I mentioned I am trying to setup the addnl WAN ATT modem on my second store system. I mentioned that my pfsense device is a 4 port device with all 4 ports utilized. We talked about a VLAN capable switch - I purchased a TP-Link TL-SG105E
I am 5hrs off site so I am trying to get up to speed to manage remotely by trying the switch on my current system.

So I have created a VLAN with a tag of 10 on interface igb3.

I have TRIED to setup my TP-Link switch (in preparation for the setup that I am currently offsite from) with port 1 being the "trunk" that a cable will be connected to igb3 (on the pfsense).
Port 1 is untagged for VLAN ID 10 and is identified as a "1" in PVID Settings
Port 2 is tagged for for VLAN ID 10 and is identified as "10" in PVID settings
(Port 3 and 4 if needed will be VLAN ID 20 for the additional LAN cable that is needed for the Camera segment of my network)

The current trouble I am having is that my identical ATT device, when connected to port 2 of the switch, is not passing through the IP address when I created or setup the interface as DHCP -- the other ATT device when connected directly to one of the pfsense interfaces pushed through ATT static publc IP address. And if I try to set the IP address manually it doesn't behave correctly- says offline

I think I must be setting the VLANs and the switch incorrectly (tags vs untagged, etc). Would you expect a device (in this case the ATT modem) to behave the same way when connected via VLAN and the switch compared to connecting directly to the pfsense physical port? I thought that was the whole purpose

Do you see any glaring errors in my setup?IMG_0228.jpeg Image 11-20-24 at 6.21 PM.jpeg IMG_0229.jpeg

@Antibiotic get rid of that torrent client eventually it’s gonna break stuff if you keep using it. Trust me. Stop using it, think about how many ports you need open. It just takes one bad download

Mmm, work to be done!

@stephenw10 I'm also noticing this behavior. I'm on pfSense version 24.03-RELEASE.

@jwt Definetly looking forward to it and be glad to test it out in first snapshots/betas that will have it. We can easily hook up an v6 only network in the lab (there should already be one) and give it a spin :)

@marcosm I've Lab time scheduled tomorrow for preparing a workshop next week so will definetly play it through first thing in the morning, just need a few hours sleep in between.

Will have the results by the morning your time :)

@stephenw10 said in SG-2220 finally got the bug:

It would have been 2014. Might have been some in 2013.

No worries.. I was just curious.. Decent little box.. I shall miss it. ;)

Same here. Does not seem to do any harm but it just feels not right, having so much errors on an interface and not knowing why...

@stephenw10 Okay great, thanks. I’ll feedback. It’s usually obvious within a couple of hours if the firmware is going to provide a stable connection.

We've worked it out, root cause identified and a fix proposed. Unsure yet how this will impact the 24.11-RELEASE.

If you are impacted by this, make sure to uninstall any packages that you are not actively using.

@johnpoz said in Fake Accounts and SPAM Posts:

Reports are prob best on those ones that they came back latter and added spam links in them and the like.. Even ones on old threads, etc. buried deep in the thread that nobody noticed when they were posted, etc.

Yup that ^. Those are the hardest to pick up otherwise.

I upgraded to 24.11 RC from command line, and now all is working in GUI again.

@stephenw10

Both really.

My infrastructure segment is inaccessible unless you can either get on that vlan through a physical port on the switch, or via a VPN that the FW originates as the server to get on an administrative network.

There are also client mode VPN connections to a commercial provider.

Regardless of if the traffic is coming in via the admin VPN and then out WAN, or on the local segment and then routed over the client VPN out to the web it takes a big hit to throughput. It would be difficult to pin down if it affects traffic both ways given the huge imbalance in the down/up speeds.

It does seem to be limited to traffic routed externally that has the issue though. Running a speed test from the admin net to a local server works as expected despite going through a vpn tunnel to get to that network. But anything either from the admin vpn or going over the external commercial vpn to an external site is heavily limited.

I've been able to confirm...

If the interface does not show in the PIMD Virtual Interface Table on the Status Tab, it gives the "Invalid phyint address" error in the logs. Sooo....

It appears that there is some limit that is preventing PIMD from seeing all the interfaces. The closest information I found is related to Linux and the limit is defined in the kernel...

I'm guessing even though I've been able to reverse my settings and avoid the errors in the logs, that any interfaces not shown in the Table are just ignored and are not participating in IGMP :-(