@rnelsen Did you configure the VLAN through the switch? I use VLAN 3 for my guest WiFi. I configured VLAN 3 on pfsense, my Unifi AP and the Cisco switch ports that connect to pfsense and the AP.

@adamsolar The SG-2100 only has two built-in NIC’s Mvneta0 = WAN Mvneta1 = LAN (Which is connected to the Built-in switch) So the 4 “LAN” ports are actually switch ports that switches traffic to/from the 2.5Gbit LAN NIC If you want VLAN capability on those ports (different VLANs on ports), you need to set up 802.1q mode on the switch: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/switch-overview.html

@lillianroot Getting Deja Vu, I feel like I've seen this question posted a while back. (my assumption is that they plugged into the layer 3 switch instead) I doubt it. They most likely did one of two things... they either spanned the appropriate VLAN out to that switch or put the end-users on a different VLAN and forced them to re-address their equipment. Are the layer 3 switches allows the VLANS to pass traffic across a trunk through routing but the layer 2 switch can't do that feature? A layer 3 switch is a switch that also has routing functionality. However, it would need to be configured and implemented properly to actually route traffic. The fact that the switch has layer 3 functionality doesn't necessarily mean it's routing traffic. So, the short answer to your question is no. A layer 3 switch will pass the same VLANs over a trunk that a layer 2 switch will. The difference is layer 3 switches can also do static routing, dynamic routing, etc. Best practice is for every closet to have unique VLANs. So, if the VLAN you're looking for isn't on the switch, it was probably left off by design. So, someone had to make a decision whether to span that VLAN out to that switch or force the end-users to re-address their equipment on a subnet that exists in that closet.

@swgarland said in VLAN Setup question: It currently tags all traffic as vlan10 unless it is changed on the switchport. Well change it if you don't want what you want.. If you want to use just native lan as vlan 10 - then just set the port to connected to lan port of pfsense to not tag vlan 10. So your saying if you put some pc connected to port X, that you have to set the PC to understand the vlan, ie the tag.. PCs sure do not do that out of the box.

@nickh-0 said in Home IP range overlap with Work VPN: @jknott Thanks for the reply. usually i would, but being a consultant and working with various clients and projects the risk of running into an overlapping IP is high and need a permanent solution to allow me to "adapt" and was thinking i could have a vlan that i can change as needed rather than continuously changing my home subnet - if that makes sense. Use 172.31.255.0/24, most of your customers if they have their heads screwed on won't allow split tunnels.

@gwaitsi  the client on vlan20 can ping all switches, routers and the firewall on vlan1 - but not the ipmi port the routers and the switches can ping all devices including the ipmi port pfsense can ping all routers, switches and clients - but not the ipmi port there is no inter-vlan routing on the switches, everything must go through pfsense. rule specifically allows all protocols / addresses from vlan20 to vlan1 and rule for vlan1 to vlan20 (for eliminating rules as a source) the test results are also the same if i put the IPMI port into the openwrt with untagged vlan1 port instead of the managed switch i don't understand why pfsense can't talk to this one device, when it can to all the others on the same network. ** to eliminate all possibilities, i put the ipmi port on the same vlan as the client on a openwrt port set to untagged. It was then able to get a dhcp from the client vlan

@roney-s-mathews How are you determining that? If you want VLANs, you configure them wherever you need them and you won't be able to see if you get the addresses, without something to connect to the VLAN. Also, did you configure a DHCP server on the VLAN?

@vtglockster The issue was the OpenVPN client. I needed to add some rules for Outbound NAT. Once I added the rules the VLANs started working properly.

Yes, adding a new IP range to the port connected to the switch will separate the devices. Then if you want you can do interesting things with rules to isolate or not isolate devices. Port 1 might have the IP 10.10.220.0/24 and port 2 might be 192.168.100.0/24. The only way they talk is if you allow (the default is to allow) them to talk.

@gertjan i found it. after days. works now. this here https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/switch-overview.html is not suitable for my config, because i need the 210 VLAN to terminate, so i dont need a dedicated Switch port, just a VLAN interface. this is the right tutorial: https://mitky.com/pfsense-virtual-lan-setup-vlans/ there it works. now the other VLANs should be working as well like this one.

@wc2l Those are aliases. Private is an alias for all RFC1918 IPv4 addresses and IPv6 ULA. Prefix is an alias for my /56 IPv6 prefix.

Under diagnostic menu.. Packet Capture. This allows you to see like the raw data that interface sees.. Here this might help in what packet capture (sniff) is. https://en.wikipedia.org/wiki/Packet_analyzer edit: example Here is a sniff (packet capture) on my dmz interface (192.168.3.253) while pinging an IP in my dmz network, from my lan network 192.168.1000 [image: 1614355630380-sniff.png] Now you can view more info by changing the verbosity level in that screen. Or you could just download the capture into your own software.. Wireshark for example (free).. And get all kinds of great info on what is actually going on.. For troubleshooting stuff [image: 1614355766223-info.png] In your specific scenario - you would of been able to see if pfsense was actually sending on the ping request, but not getting an answer, etc.

@cheezyadmin LLDP is a discovery protocol. My guess is their phones use LLDP to discover the voice VLAN. You will need to enable LLDP (and possibly LLDP-MED) on your switch.

adding a pass rule from(opt1) to source/dest/port(any) in the firewall on the opt1 interface solved the problem.

@madnet As has been mentioned here many times, avoid TP-Link, if you want to use VLANs. There are plenty of other brands that work properly.

@marvosa Thank you! It took me some time and a little nudge from a friend to translate your sentence but eventually I figured it out. I now have the gateway online and the interface up and learned some things in the process.