Thanks so much to everybody involved here. I was entirely wrong in my initial suspicion, but the analysis helped me better understand how networks work, so I do not consider this as lost time. Some revelations: for incoming traffic, wireshark, tcpdump and packet capture (pfsense) are king for outgoing traffic, ip route get [host ip] helps to see in which direction traffic leaves (or doesn't leave) the host

@derelict Thanks. You made my day. I will try that

@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: [image: 1616531784069-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": [image: 1616462963822-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.