@louis2 Why? Bridges bridge Interfaces. Vlans in pfsense are not interfaces. So yes, it takes a few more steps, but it works. And as a matter of fact is also performant. You can also try vxlan if you wish which is a new feature in pf plus.

@big_blue oh! Well good job me then.

@Hoser7632 no connection like link would have nothing to do with what networks you might pass over this wire. Not exactly sure what you mean when light just flashes red, on your AP, on the interface? I take it your powering this via ac adapter since I doubt your x550-t2 interface is going to provide poe. Why would you tag traffic over this interface to your AP, unless you were going to carry more than 1 network on the wire? Seems kind of pointless to me to tag this traffic if only 1 device is going to be connected to this port.

Architecturally similar to my installation. I have a "core" switch which connects to the firewall, but with one switch port with half the VLANs going from the core switch to the firewall and another switch port with the balance of the VLANs going to another firewall port. Then, the core switch connects to my two remote switches (analogous to your switch by the firewall and your garage switch). Without bridging the firewall ports, I don't think you can home-run both switches to the firewall and route all VLANs to both. And Netgate here has repeatedly discouraged using bridging on the firewall. Thus, a "core" switch is necessary, or, daisy-chain your switches. A couple of down-sides to daisy chaining switches is the single-point of failure in the daisy chain. If your top switch fiber goes bad, or the top switch goes bad, your entire LAN goes down. Also, all your traffic then has a single collision domain between your top switch and your firewall. Probably not a real issue on a 10G fiber, but if you have tons of traffic on that fiber it could degrade performance. A core switch could alleviate the collision domain issue, and if you connect the core switch to your firewall with two fibers, one for half your VLANs and the other for the rest of your VLANs, you'd remove a single point of failure for your entire LAN at least as far as the fibers go. If the core switch fails then everything fails*, but that would be easy to diagnose. If just one fiber or fiber port goes down, only half your LAN (one of your two switches) would go down and that would be easy to diagnose. YMMV. *You could certainly design some kind of redundant core-switch arrangement with spanning-tree protocol and multiple switches and fibers and so on, but that's out of my league.

Hi all! Thank you for your quick answers! It was connected to the PFBlocker NG; once it has been deactivated and reactivated, it works. cheers!

@patient0 Not a production environment just home environment. Thanks for your suggestion I'll give it a try. Best Regards and thanks again....

Thank you for the replies, I was sort of able to figure it out and get it/them working But its not how I expected? I setup the VLAN's on the switch and according to everything I could figure and you guys too it should have worked but it didnt? After going back-n-forth with this for a few days I decided to give it a rest for a couple days. When I got back to it I went to login to the switch and was unable? No matter what I tried couldnt get it so I did a hard reset (unplug) and tried to log back in, I was able to get into the switch and all the config was there so I plugged my laptop in and it pulled the .20 IP??? More testing and it did what it is supposed to do? Best I can figure is that the switch didnt like what I was telling it and decided it needed a refresh to then give what I was telling it? IDK but its working now. To all Thank You especially johnpoz , theother, and patient0! :-)

@bjks87322 It sounds like your goal is to get the VLANs working on LAN? LAN is a 4 port switch as noted. The docs explain how to separate/isolate the ports. If you are trying to have them work on any port I think you need to add it on LAN Uplink, 5...step 19 in that doc. Though I haven't tried it so don't quote me. :) Office (lan): mvneta1.3 -> v4:192.168.10.1/24 ...if you are trying to reassign LAN I think that needs to remain on port 5, the uplink?

@patient0 I don't know about that PC. But it's very unlikely that it's configured to understand VLAN 150. This VLAN comes from me and exists only on my systems (pfSense, switches, PVE). But sure, I will take away the VLANs from that port at first. thanks so far I wrote an issue on the german Proxmox-forum as well, to check my bridging setup on the PVE. I link it here, maybe somebody is interested as well: link

@viragomann said in Can't get pfSense bridge to work with VF NIC: Yeah, if you pass through the hardware to a VM, the host cannot use it anymore. That is 100% not true. As I mentioned, I pass through VF, SR-IOV is designed just for this. Host device remains and is supposed to be able to talk to guests and to the outside. @viragomann said in Can't get pfSense bridge to work with VF NIC: You should rather create a bridge in Proxmox, connect the hardware NIC to it and assign and IP and connect the virtual interface of the VM, if you want to access both devices over the single NIC. That is exactly the description of the virtio interface I have, but it is slow, just ~1.3 Gbps in pfSense due to multiple reasons (issues opened for years and little if any progress is happening on them, so I wanted to pass through the physical hardware). On Linux virtio interfaces trivially push over 10 Gbps, but not in pfSense.

Just tried on pfSense 2.8.1, seems to work fine. The VLAN is working fine, but the ixv driver itself seems to be flaky and sometimes not really working properly on boot, which in turn causes VLAN issues as well. But it is not happening nearly as often as it did in the past.

Ok this is all kinds of messed up - nothing is actually wrong, the server management keeps showing me absolutely nonsense IP connected on that particular port. Even after a reboot. WTF?

@patient0 said in Identifying Rogue Traffic: @james_h it's more the last rule with 'PreferFIBRE'. The default allow-all rule after installation is source 'LAN subnets' and the rest any. You rule allow anything as source on the PRIVATE interface. If you do expect traffic with source IPs of PRIVATE subnet then changing it from * to 'PRIVATE subnet' would have blocked the 172.20.* traffic. Are the 'admin_devices' all in the PRIVATE subnet? Yes I think thats what I should do. The admin devices are indeed in the PRIVATE subnet.

@jogovogo said in No Internet access with VLAN via OPT1: My first surprise is that I'm now on the firewall, but why? The web server that serves the pfSense GUI runs on all assigned interfaces. When you installed pfSense, there was a pass rule for incoming traffic on the initial LAN interface : it accepts all traffic. When you add more LAN type interfaces, the ones called OPTx, there will be no inital rules, so you can't access anything. DHCP will work as pfSense will add hidden DHCP (UDP port 67 and 68) rules, but nothing else (no http https dns icmp etc etc etc etc). When you add a pas rules for TCP, UDP, etc, things "start to work". When you use addresses like this : [image: 1758697659291-89b7f27a-e729-4579-81c1-cb12989a7d3f-image.png] you use IP addresses. So, even is DNS is not working, then that won't be an issue. Your browser doesn't need to use use DNS (for translating host names to IP addresses) as you already gave an IP. It can contact the device 192.168.151.1 right away. You've allowed TCP IPv4 traffic to port 477, which is apparently your changed your pfSense https web GUI interface port. @jogovogo said in No Internet access with VLAN via OPT1: The issue has been resolved, simply, by restarting the DNS resolver. Euh ...... As you've changed lost of things at the same moment, it's hard to tell why dns (== the resolver) didn't work initially. Normally, when you add an new interface like your OPT1 interface, system processes like DNS (the resolver) gets restarted. The resolver will listen to All Interfaces : [image: 1758698045123-e07276c8-27b7-4a13-b999-ca154f396adf-image.png] by default so it would work right away on the new OPT interface. Again, you still have to add a firewall rule to allow DNS traffic to reach the pfSense DNS port 53 of course.

@patient0 Got it, will explore 'Shellcmd' package Thank you!

@Monta you could do a traffic capture and look out for dhcp related packets...coming from, going to...pfsense offers that already. here: https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/webgui.html you could also provide screenshot(s) of: vlan config pfense and vlan interfaces for dhcp vlan config of switch config of AP maybe that gives a hint... as already said: said in How to view VLAN: you possibly get more help if you give precise info ;)