@SteveITS After isolating the vlan on the switch, I had to configure a static IP, and now must configure for the WAN access. Would you know anything about this?

I ended up just plugging a Raspberry PI into a port on the N3K-C3172 TOR, and configured the network stack to implement the L2TP pseudowire, so it ends up being the same number of hops, but it would have been nice to implement it either in the switch or the firewall and not have to live with a single function appendage... but that's life in technology.

@johnpoz

Then I was just discussing it. I hadn't actually tried it on pfsense. Today, I thought I would, given I have so much time on my hands with the pandemic. I run openSUSE Linux on my network and it supports VLAN 0. In fact, it's what pops up when you create a VLAN. In my previous experiment with VLANs, I was using VLAN 5, which pfsense supports. I also have VLAN 3 for my guest WiFi.

BTW, I just came across this. In reading it, I get the impression someone doesn't understand what VLAN 0 is for. The "reserved" purpose is for putting the CoS bits on a frame, without having a separate VLAN. That is a VLAN 0 frame should be treated identically to a native frame, other than CoS.

@duvel

If you have 4 NICs, there's likely not much use with using VLANs. If you want to learn about VLANs, you have to actually set them up and have something at the other end of the wire that can handle them. A managed switch will do that. You can create multiple subnets and put them on individual VLANs. Then use the managed switch to sort them out, so that when you plug a computer into the different ports, it will be on the different subnets. Depending on your WiFi situation, you might get a proper AP and use a VLAN to provide a guest WiFi.

One other thing you can do with a managed switch is create a data tap, so you can monitor a connection with Wireshark. This is very handy when learning about networks.

Again, small managed switches are cheap. Just avoid TP-Link.

@jamesdav It's just a switch. If you must use the switch built into the SG-1100 for this and not an actual external outside switch, you can modify this procedure:

https://docs.netgate.com/pfsense/en/latest/solutions/sg-1100/switch-overview.html

That puts two ports on the same LAN broadcast domain but it will work equally well for VLAN 4090 (WAN).

@derelict & All

Thanks for your help. The issue is resolved.

The problem was the Netgear switch port was being blocked because of STP rules.

Issue Resolved!

I came up with this topology:

210322 Network Diagram.jpg 

I also set took these configuration steps:

set up a bridge between the interfaces corresponding to the LAN and OPT ports in Interfaces→Bridges, set the OPT port to have the IP address 192.168.4.1, set up a DHCP server for the entire 192.168.4.0/24 subnet on the interface corresponding to OPT, with 192.168.4.1 as the gateway address, turned on the Avahi package to route mDNS traffic between the 192.168.4.1/24 and 192.168.1.1/24 subnets, turned off the Velops’ DHCP server, and set the LAN base address to 192.168.4.2, so as to not create a conflict with the OPT port.

The second Ethernet connection on the master Velop node is purely for remote administration purposes. That’s how it communicates to the LinkSys configuration servers.

@Derelict & @teamits : you were both right. Sorry, my bad: it was bad Ubiquity configuration.

If anyone falls in the same trap, the solution is to set "Corporate" + "VLAN". Not "VLAN Only" + "VLAN":

98a25145-0f81-4440-85e0-ab5af871da71-image.png

Thank you both very much!

@mcury Perfect, got it working as expected.

Still curious about what causes the underlying issue wrt routing from the gateway but it's less of a concern since I can address the symptom.

I eventually solved it by using the ISP modem/router for IPTV and but pfSense behind it. It's double NAT but that's ok for now.

I solved the issue a while ago and forgot to answer here.
After entering the IP in Captive Portal / Allowed IP Addresses, everything was perfect.
As my CP is authenticated, so I believe that the question was precisely at that point. The other end had no way to authenticate itself to be able to pass and from the moment I released the IP there, he started to communicate. I even thought about doing a test of this type, taking the CP's authentication to see if it worked directly, but I ended up not having time.

Anyway ... it's resolved.
Thanks to everyone who was willing to try to help.

@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.