Edit3: Finally the things have worked. What I did based on @jasonlitka post on another thread. I open up the cli to check the running config file on the ports 3 and 36. I have cleaned all the configurations on each port. So the configurations are below:
Switch01 Core(config)#do show running-config interface GigabitEthernet1/0/03
description "Live Esquerda"
switchport access vlan 10
Switch01 Core(config)#do show running-config interface GigabitEthernet1/0/36
switchport mode general
switchport general allowed vlan add 10 tagged
switchport general allowed vlan add 1 untagged
There are many bridged interfaces on the host system connecting to various vlan tagged interfaces:
Screenshot 2023-05-17 at 7.13.36 AM.png
The bridge0 interface is a non-vlan tagged interface [vlan1?] and is accessible to all systems on the network.
I was under the assumption that if a network interface was tagged with vlan information that it would be accessible to other systems that are part of that same vlan?
Another thing about my setup is that these vlans are configured on a pfSense box for lab purposes, they are not configured on my main pfSense box [which I don't think matters]. So even though the opt ports of this system are technically on their own network, they are connecting to my main network.
where they just manually switched back and forth between the VLANs,
You can - where you set the pc to understand the tag, but again that is not a vlan... That is some user without a clue to networking thinking they have setup a vlan and all they did is run multiple IP schemes on the same network. There is no actual security there, anything can talk to anything, be it you setup a firewall rule or not - broadcast and multicast traffic is going to be seen by every device.
That is not a vlan. A vlan actually isolates traffic at layer 2..
You could move your pc into another vlan that is on that port, by changing the pvid on trunk port so the untagged traffic is now in X vs Y, etc. But just changing on the IP on the pc isn't going to work if you actually have vlans setup.
@wifi75 non mancava nulla.
Avevo fatto tutto esattamente come hai suggerito tu, ma non c'era login.
Ho chiamato il provider il quale ha inizialmente detto che poteva essere un problema del mio router, così mi sono procurato un altro router ma neanche con questo c'era login.
Di conseguenza hanno aperto un ticket con OpenFiber, e alla fine è venuto fuori che quando hanno fatto l'allacciamento si sono dimenticati di attivare qualcosa, per cui non c'era possibilità di connettersi.
Io avevo dato per scontato che fosse un problema di configurazione perché dopo che OpenFiber ha fatto l'allacciamento ho chiesto espressamente se la linea dovesse essere attivata dal provider, ma mi hanno assicurato che "potevo già navigare!"
Or is it enough to disable
"Hardware TCP Segmentation Offloading"
"Hardware Large Receive Offloading"
Those should be disabled anyway, they are disabled by default so definitely disabled them if you have set them enabled.
Hardware offloading requires the driver and hardware to work correctly together. Something that works on an igb NIC might work on ix. It might not even work on a different NIC that also uses the igb driver.
They usually do though because those Intels are the best supported. Intel contributes their own driver code to FreeBSD.
To disable that as a test you can run at the command line:
Yes you could use pools in one subnet and filter them differently using aliases but you can't filter traffic between the clients on one subnet that way. Traffic would just go between them directly without passing through pfSense. Only one interface.
Really you need to use VLANs in there to separate the traffic at layer 2.
OK i got it! when i block UDP traffic from LAN see rule (or image below) to the IPcam ipaddress it works as it should. what i think happened is that default UDP doesn't work, still don't know why btw, then the camera is forced to use TCP. Its just a guess.
I moved the WAN by changing the parent interface for the default WAN VLAN.
The VLAN on WAN, 4090 by default, only applies to the internal switch. So simply moving the VLAN parent to ix0 or igb3 would only work if VLAN 4090 is defined correctly on the external switch they are connected to.
If that's not the case the new WAN interface would be directly ix0 or igb3 without a VLAN.
The switch = Cisco WS-C3560E-48PD-SF. Also running a 2960-CG
Re: There is really no reason for it
I am well aware that what I'm doing falls in the realm of completely unnecessary for a home network. Just a learning exercise.
I figured out the answer to my convoluted post from yesterday. You touched on it in your post but I'll type it out in my words...
From what I can tell, the pfSense LAN is the only untagged network available on the router. Changing the native VLAN on a switch, for example, to VLAN 20, would require that the ip address assigned to that VLAN be in the address range of the LAN network on the pfSense box (because it also is untagged) to maintain web access to the switch.
Key takeaway - the native VLAN on switch (untagged) should not be assigned to a VLAN network (tagged) on a pfSense box (else one loses web access to the switch). Also, the ip address assigned to native VLAN on switch must be in the same subnet as the router LAN.
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.
Yeah 10.0.12/22 or 255.255.252 would be 10.0.12.0 - 10.0.15.255
What are the rules you put on these vlans?
And yes a drawing would be most helpful.. Your saying the devices pull the correct info via dhcp.. If so that would point to connectivity being good, so first thing that comes to mind is wrong rules or lack of rules on the vlan interfaces.
In Interfaces > Bridges you can define a new bridge and add interfaces to it. The go to Interface Assignments, assing an interface to the new bridge and enable it. No further settings are needed on the bridge interface.
But befor you have to ensure that there is no configuration on the vlan 10 interface. It has only to be enabled.
However, with this setting results in the vlan 10 going down, when WAN goes down. To avoid that you can move the IP settings from the WAN interface to the bridge.