@the-other said in VLAN's, what to do with "default LAN" ?:

Now, I read that (as mentioned above) for security reasons it ist not recommended to have clients or productive data running on that default VLAN.
So, everything is in its VLAN here.

If you're sending different VLANs to the various rooms, then you're using a managed switch to make the VLAN the native LAN to that room. Users in that room will never see the original native LAN from pfSense.

@JKnott

I had a look inside the configfile. There you see this

<laggs> <lagg> <members>igb0,igb1</members> <descr><![CDATA[LAGG TO 1G MAIN SW (GS1920)]]></descr> <laggif>lagg0</laggif> <proto>lacp</proto> <lacptimeout>slow</lacptimeout> <lagghash>l2,l3,l4</lagghash> </lagg> <lagg> <members>ix0,ix1</members> <descr><![CDATA[LAGG to 10G MAIN Switch (SX3008F)]]></descr> <laggif>lagg1</laggif> <proto>lacp</proto> <lacptimeout>slow</lacptimeout> <lagghash>l2,l3,l4</lagghash> </lagg> </laggs>

AND

<opt17> <descr><![CDATA[Emerg_Mngt]]></descr> <if>igb2</if> <spoofmac></spoofmac> <enable></enable> <ipaddr>192.168.9.1</ipaddr> <subnet>24</subnet> <mtu>9000</mtu> </opt17>

However there is no config block as show above for igb2 in favor of
igb0 / igb1 / ix0 / ix1

Neither is there such a config set for em0 .

The only situation where I see an ^<op117> like control blok, is in case of a "Physical LAN"

So adding not yet existing control block types, feels very hazzy

I think I will open a ticket. Lets see how the developers react ...

Ah, Smoothwall memories. My AMD K-6 233 with 8MB RAM, 3x 10Mb ISA NICs (that did BNC, Ethernet, and whatever the pin interface was), single-floppy system and dial-up on demand.

@spearless said in VLAN interface Parent:

Does a parent interface have to be enabled?

Yes. All that it takes to make a VLAN is the VLAN tag inserted in the frame. If the parent isn't working, there's no frame to insert the tag into.

@louis2 said in How to change physical interface / LAGG MTU-size?:

However .... I can not find a setting to change the (maximum) MTU-size !!??

There's an MTU setting on the Interface pages. However, I have no experience with LAGG, so can't say about there.

@viragomann yes, it is checked

@keyser Thanks for that. Time to get the console cable ready!

@ciclopeblu said in Vlan and phisical interface:

for a switch that will connect

I'm still reluctant on adding another switch

Huh? Thought you already had a switch, that you stated in your first post? But now your reluctant to just plug it into your existing switch?

Here is what I would expect a typical setup to look like.. Where lets call vlan Z where you put your cameras and your DVR.

IPcamera.jpg

How does adding another switch, that you put on your camera network complex up the setup? If you already have a switch that you have your camera vlan and other vlans on?

Really the only time you would have traffic flow over a pfsense interface or interfaces would be if your accessing the camera or the DVR from some other network like vlan X or Y.. Your DVR and Cameras should all be on the same network/vlan.

You know what for sure would complex up the setup, trying to setup a bridge ;)

First, configure mvneta1 interface with an IP address in a MGMT network that you choose (not vlan). And use this same network in the switch and AP for management purposes.

Checking your screenshots, everything seems to be correct at the pfSense side.
Check your netgear, make sure the MGMT network is correct (untagged) and in the same network as mvneta1 in pfsense, check if this same port is configured to receive vlan20 and vlan30 tagged, and the downlink has the same configuration.

The port connecting pfSense to Netgear switch should be like this:
VLAN 1 Untagged (MGMT of the switch)
VLAN 20 Tagged
VLAN 30 Tagged

Netgear Switch to AP:
VLAN 1 Untagged (MGMT of the AP)
VLAN 20 Tagged
VLAN 30 tagged

Then, assign the wifi networks to use VLAN 20 and VLAN 30 respectively.

@houseofdreams

did you set the the portgroup to vlan 4095 on your esxi / vmware ? (required to passthrough/trunk vlans from host -> vm)

this is what you are doing right?
<telenet router>--untagged vlan 30--<switch>--tagged vlan30--<pfsense-wan>

@NightlyShark

Nobody is arguing the difference between L2 and L3. You said I needed a managed L2 switch which won't do me any good for routing vlans on different subnets.

And there are such things as dhcp relay agents to get IPs from different subnets. Pfsense actually has that feature.

People with a great deal of experience setting up networks would know that...friend.

@granroth That smells like bad port quality + cheap cable. Won't create problems in TCP, but UDP suffers quietly, and ends up wrecking your nerves, by breaking DNS. Start wireshark and you will see the the tale-telling "Spurious TCP retransmission".

@granroth said in Enabling access between LAN and other non-WAN interface:

I followed @viragomann's line of thinking and focused very intently on the devices in question. Specifically, I started by concentrating multiple hosts on the single proven-working Omada managed switch and experimented with them being part of OPT5 or part of IotVLAN or both and then in each case, connecting and receiving connections from/to LAN, OPT5, and IotVLAN.

When the dust settled and I collated all of the successful and failed attempts, it was pretty obvious that the root problem was my original SG116E "Smart Switch" since it was only connections to and from that switch that potentially failed. As long as the hosts were all on the Omada switch -- regardless of what LAN or VLAN they were on -- they would work with each other. Furthermore, any hosts on the Omada switch could typically connect to any host on the LAN network, even though that went through the suspect "Smart Switch".

My plan, now, is the replace the "Smart Switch" with my new Omada switch and see if all of my problems just disappear.

@cyberconsultants I had not! That's exactly the point in a direction I was looking for, thank you!

Adding these as loader tuneables seems to have fixed me right up:

hw.cxgbe.niccaps_allowed="1"
hw.cxgbe.toecaps_allowed="0"
hw.cxgbe.rdmacaps_allowed="0"
hw.cxgbe.iscsicaps_allowed="0"
hw.cxgbe.fcoecaps_allowed="0"

iperf3 -c 172.18.25.25 --parallel 2
Connecting to host 172.18.25.25, port 5201
[ 4] local 172.18.0.103 port 52800 connected to 172.18.25.25 port 5201
[ 6] local 172.18.0.103 port 52801 connected to 172.18.25.25 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 53.9 MBytes 452 Mbits/sec
[ 6] 0.00-1.00 sec 51.2 MBytes 430 Mbits/sec
[SUM] 0.00-1.00 sec 105 MBytes 882 Mbits/sec

[ 4] 1.00-2.00 sec 53.5 MBytes 449 Mbits/sec
[ 6] 1.00-2.00 sec 51.2 MBytes 430 Mbits/sec
[SUM] 1.00-2.00 sec 105 MBytes 878 Mbits/sec

(etc.)

(I added the parallel connections to squeak out a bit more; without it it's running around 790-ish Mb, which I'm calling good enough.)

And my speed tests to the internet are back in the comfortable 940-ish Mbit range (1G/1G), so I'm calling it fixed, or at least as fixed as it needs to be until my new switch shows up.

Thanks again!

@itschloegl There is no way to avoid this without extra hardware. You could use a Raspberry Pi with linux on it configured as a bridge. Then, separate VLAN (eg, 4000) that only goes to/from the Raspberry Pi port to the PfSense port, PVID of Raspberry Pi switch port 4000 member of 4000, PVID of PfSense switch port whatever you have now, "member of" on PfSense switch port, whatever you have now + 4000, new VLAN of 4000 on PfSense (on the network card you have), create new interface WAN2 or 4G or whatever using the 4000 VLAN. Now, that is a setup that will never have the problem you have now.

@Jarhead @kjk54
Thank you BOTH for taking time and helping out....

I finally found the issue, used backup\restore to my test duplicate setup....

There is a IPSEC VPN tunnel that is grabbing 192.168.0.0/16 traffic. Once I disable the VPN, everything is working... So I need to change LAN2(or OPT1) to a different class C address away from 192.168...

Thanks again, really appreciate the help!!!!!!
Brian

@anishkgt OK, then if you go through the steps of:
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html
...it will be a separate port. No VLAN configuration is necessary for the wireless clients or APs, since the 2100 handles that as the packets arrive over that cable. That example is port 4 but you can use any port and VLAN number.

@John_McNoob
Your first post showed a picture of the DHCP setup for your main network (or at least I assume that's what it is). You need to create a second DHCP server that is attached to the wifistrangers interface and serves out the 10.10.2.x address range.

@HLPPC

I suspect you're imagining problems. Any hardware that does what you suggest is NFG. Also, if you lock one end, you also have to do the other end and that often can't be done.