@urbaman75
So 10 port router, all have a separate subnet?
If so, what I said previous still stands.
Whatever vlan you use in the switch on any port that goes to a router port, that router port will use that vlan.
So Router Port 1 is connected to switchport 1 with it set to vlan 10. The network on router port 1 will use vlan 10 on any other switchport that is set to vlan 10. If you set switchports 1-6 to vlan 10, 2-6 are available to use for devices to connect to the subnet on router port 1. Same with router port 2 and 3 and 4 and ....

Whatever switchport you connect to a physical router interface determine the vlan it uses by the pvid of that switchport.
If you had a trunk port from router to switch, that's different.
You can set the switches management interface to whatever vlan you want. In your example, assign an IP for the switch in vlan 100 (or use dhcp) and it will use that vlan as management.

@johnpoz said in SG-3100 switch weird behavior (resolved):

once you put it up, I will give it a go via a VM maybe. I don't as of yet have a pi4 to play with.. Been looking for an excuse to get one hehe.. But they have been hard to find as well, I would prob go with the 8GB ram model as well.

Done, english is not my first language so I hope its okay.

https://forum.netgate.com/topic/175394/graylog-server-on-a-raspberry-pi

@zipping8761 haha - I warned you, but it a good learning experience ;)

@johnpoz said in How to keep networks separated:

Seems odd to me that your saying pfsense is getting a public IP - but other devices are getting 192 - this isn't normally how a gateway in bridge mode works.

That's how the att garbage works. Their gateways have what's called passthrough mode. Via dhcp it assigned the public ip to a single device on the lan side.

However, the public ip still remains assigned to the gateway's wan as well. It's a pseudo passthrough mode of sorts, fake bridge.

The end result, customer's device (router, pfsense, etc) has what appears to be a public ip as well as the gateway. As such, the gateway can assign various private ip's to other devices (wired and wireless) connected its ethernet ports and/or wifi ssid. A traceroute behind the customer's router (pfsense or other), will show the gateway ip as the first hop (192.168.1.254) rather than the real wan gateway.

For those of us on fiber in areas not get upgraded to xg-pon, several bypass methods exist which eliminate the isp gateway box entirely. The best is extracting (or buying) the 802.1x certs then implementing them in software using wpa_supplicant. This gives customer full access and control of the network, no double nat, etc. Also a /60 PD for ipv6 vs /64 from the gateway box.

The other methods still rely on the gateway box in one manner or another.

No worries, glad you're up and running. 👍

You can only choose a switch port on one interface as you found. If you leave unset it will use the actual VLAN status which takes it's state from the parent interface. In this case though that's the in internal port which is always UP.

No, there's no private VLAN type function. That would need to be on a switch where hosts are connected directly.

Steve

@JKnott

I tend to heir on the side of caution when it comes to using terminology I'm not 100% familiar with, but I have the basics down that's for sure.

Regardless, after some extensive troubleshooting I got rid of the Aruba switch and swapped it out with a Ubiquiti.
Had my network infrastructure team troubleshoot the Aruba... nobody could get it working. They let me know about how others have not been able to use Aruba equipment in the past, so i chalked it up to the switch.

@mohkhalifa said in pfSense on ESXi | Best Practices:

problem SOLVED after "Disabling hardware checksum offload"

Awesome. I poked around on a few of mine and didn't find any with that enabled. Mostly Dell hardware here. Good find.

@Asamat: Your 'this Bug' URL is this thread here. ☺

-Rico

Correct, the patches above are copies of the changes made in the repository that will be used to build pfSense 2.4.4-p1. So not "hacks" exactly.

If it's all working for you now then there shouldn't be anything to worry about. When you upgrade to 2.4.4-p1 the manually edited files will be replaced with the copies from the new release, which already contain these changes.

@jknott said in Hardware switch or NIC brridge?:

There used to be some cut through switches, that would start switching as soon as it learned the destination MAC, but those have disappeared

And there still are, the cisco nexus 5000 line did/does it... The 9000 series nexus I believe default to cut through but can be put in store and forward, etc.

So disappeared is not true... But cut through was never in the soho or budget lines of any switch maker..