@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. [image: 1710937677992-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.

@Zak-McKracken yeah you can have untagged or native vlan along with tagged vlans.. Unless your wanting to have a hard time, you can only have 1 untagged vlan.. Keep in mind a anything connected a port that sends out tagged traffic can be seen by the other end.. So they would be able to see broadcast and multicast traffic that is on those vlans.. But that seems fine from your info.. if you want to get to the management Ip that is not on a specific vlan, you would just need to add an untagged/native network on this interface that matches up with whatever IP scheme they are using.

@submitform said in Issues with 2 VLANS: Any Ideas on what the issue is? I think I know the answer.

@provels said in Cannot print over wifi to hardwired printer ... vlan issues ?: o print to the printer's Wi-Fi directly? That is not how I read that.. But maybe - I took it had a wireless vlan X, and a wired Y, and was printing from X IP to Y.. If its a true OS, like mac OS then he should be able to print even if the printer is on another vlan, because discovery is not involved.

@brannenj that screams firewall on the device.. Simple test.. from your wireless vlan ping the IP of the server, when you sniff on pfsense interface on the server interface.. Do you see pfsense send on the ping? If so - and no response then there is something on that device not answering the ping, ie firewall.. Here... pinging another on one of my vlans 192.168.2.50, from my 192.168.9.100 device.. While sniffing on the interface the 2.50 device is on.. [image: 1709593271578-request.jpg] If you only see the request, then pfsense sent on the traffic, but the device your pinging is not answering. If you don't even see the ping requests go out, then pfsense never saw it? Your policy routing traffic, or your rules are not actually any any.. If you dont even see the requests go out on the interface for the server, validate the traffic gets there by sniffing on the pfsense wifi network interface.

@viragomann Hmmm. I could access it when it was on 10.0.0.1 as 10.0.0.3 from other 10.0.0.x addresses.

Investigated a bit more, and just installed a new pfsense 2.7.2, and everything works ok. So the issue is most likely in old pfsense configs, but I think I'll just migrate all services to the new one and call it a day.

@lrqnet Oh, good that I do inter-VLAN routing on my routing switch.

@the-other Thanks. the interface is set to auto... the TrendNet will auto negotiate at whatever is needed up to GB speeds Bouncing the TrendNet makes everything work...for about 5 minutes... this is driving me crazy