Did you test some other client device behind the switch pulling a lease? How that differs from the switch as a client?

Bizarre. Hard to see what might be different there.
One possible test you could do would,be to assign mvneta0 as the LAN on the 2100 to remove the on-board switch. That's quite involved though.

@johnpoz

Thanks a million, That's exactly what I was looking for!

@mhd353 Yeah you could do that. Or like I said earlier, just change the 3.1 to 30.1 and use it as the native on that port, you can then add vlans later if needed. I've done it where I name the physical port "Trunk" and had no native network on it. I've also read recently that the physical port doesn't even need to be enabled but I never did that and doesn't sound like something that would work to me. Maybe I'll try it sometime just to find out.

Just add ports 1 and 5 as tagged members on those VLANs in the switch config.

Screenshot from 2024-01-14 22-48-58.png

@johnpoz So I checked the settings and the following are how the switch is set up and the packet capture I did when trying to connect to vlan 10 on port 5 of the switch while it was looking for an address assignment:
![alt text]3da348ce-18db-464a-8c78-8d961cd08423-image.png

0f152dc9-ff6b-4451-8eb6-e16b8de65cfe-image.png

4971b310-2b0e-414a-bb4c-f0ed8e08c7c7-image.png

It still isn't working.

@root1ng said in Can someone explain to me how i can do this ?:

the network card of the motherboard is disabled in the bios

Most of us who use Proxmox reserve that port for Proxmox...makes it a lot easy, and once you passthrough the PCIe NIC in your setup, Proxmox won't have a gateway. Please visit here: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

@johan-2 Ah. Not using pfSense as the gateway, then. :)

@danioj Bigger takeaway: Netgate Device ID is based on your NICs and their MACs.

Add VLANs over interfaces to your VM guests -- you'll be happier long-term.

@rennit I guess? With VLANs AFAIK there are two ways to get the VLAN assigned. Either something assigns it (AP, switch) or the device's network config has a VLAN. With the latter, someone with knowledge can change, add, or remove the VLAN tag. If the switch allows the new-VLAN packet on that port then it gets passed on. Normally that's blocked by a managed switch, but generally unmanaged gigabit switches will pass packets without regard for VLAN.

Otherwise something would need to be removing the tag from the packets, in order to cross over to another VLAN.

@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful!

Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense.

Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified.

Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule.

Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule.

Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality?

edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule.

Thank you again for your time and great detailed answer above!

@zipping8761 haha - I warned you, but it a good learning experience ;)

If you mix internal networks into EXTERNAL_NET, you very likely will increase the number of false positive alerts from routine traffic.

If you have specific design goals, it is very easy to provide your own customized rules. You add them by choosing Custom Rules in the drop-down on the RULES tab and then typing in or pasting in the rules you need. They will be combined with any other rules from previously selected categories.

@bogusexception said in pfSense Captive Portal on VLAN with Unifi WiFi APs... ...oh my!:

@stephenw10 Sorry I wasn't clearer. Most like brevity and complain when there are details. The following use case is strictly for the VLAN operation desired:

Employee see AP's SSID, "Team" for example. They enter the known password, known by all team peeps. They are presented with the CP (captive portal) challenge for user & pw from pfsense. They have their own user & password on pfSense, and use it to get past the challenge. Once successful, they are on their own, with traffic restricted at pfSense using VLAN firewall rules, like the other VLANs.

Now for each of your questions:

Do you mean simply entering the wifi pass key (WAP2/3)?
Yes. Steps 1 & 2 above.

Or are you using the Unifi captive portal for that?
I was/am not aware that is an option-that is, only entering their unique creds when connecting to AP. I'm fine with that!

If it's the latter then serial captive portals could be a problem.
I see what you mean, like cascading them. No, none of the incomplete/outdated examples I found do that.

Really, as long as each user can log onto the network (VLAN 20) via WiFi, i is a win. I just picked the closest examples I could find, and none are working as the OPs say they do.

P.S. Not that it should matter, but there is no addressable switch in this scenario: just a pfSense box with 2 physical interfaces, and a few APs. They just have user access group restrictions more involved than most.

I hear you can't use the LAN interface if there are VLANs on it by some, but at the moment I can't get the CP credential challenge page to come up once they log into the AP's SSID that matches traffic for VLAN 20.

Seems overly complex, thought about using wpa2-enterprise & freeradius ?

@fcs001fcs No, as far as I know there is no Mac-Auth L2 support on ports in pfSense.

@johnpoz

The switch = Cisco WS-C3560E-48PD-SF. Also running a 2960-CG

Re: There is really no reason for it
I am well aware that what I'm doing falls in the realm of completely unnecessary for a home network. Just a learning exercise.

I figured out the answer to my convoluted post from yesterday. You touched on it in your post but I'll type it out in my words...

From what I can tell, the pfSense LAN is the only untagged network available on the router. Changing the native VLAN on a switch, for example, to VLAN 20, would require that the ip address assigned to that VLAN be in the address range of the LAN network on the pfSense box (because it also is untagged) to maintain web access to the switch.

Key takeaway - the native VLAN on switch (untagged) should not be assigned to a VLAN network (tagged) on a pfSense box (else one loses web access to the switch). Also, the ip address assigned to native VLAN on switch must be in the same subnet as the router LAN.

Thank you. -jeff