Aha! This makes perfect sense. This exchange is happening over a physical link in your case vs virtual in mine.
I don't believe I ever used this method. Mainly started with the dumbswitch/rg, then went certs/wpa a year later in 2019.
How to pass VLAN 0 Priority Tags to pfSense for DHCP
- Thread starter chocolateturtle
- Start date
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
I don't believe I ever used this method. Mainly started with the dumbswitch/rg, then went certs/wpa a year later in 2019.
Take a look here: https://www.reddit.com/r/ATT/comments/g59rwm/comment/fskwgd7/
This appears to be exactly what I'm doing, but he makes no mention of the fwbr flag.
This appears to be exactly what I'm doing, but he makes no mention of the fwbr flag.
Yes that is the same guy I linked from reddit a few post back. He helped me get set up about 3 years ago.Take a look here: https://www.reddit.com/r/ATT/comments/g59rwm/comment/fskwgd7/
This appears to be exactly what I'm doing, but he makes no mention of the fwbr flag.
Tried that. The wpa auth works on the host, but no dhcp on the guest. Vlan0 is passed.or can you move the wpa-sup into Proxmox and let Debian do the EAP-Auth, then, just pass vlan0 to *sense as wan.
Looking at my working utm system, the request goes out untagged. Response comes in tagged vlan 0 priority 7. Wan nic is in passthrough mode to utm.
With the proxmox wpa on host, with vlan0 enabled, the request is going out on vlan0, which may be ignored because it is vlan0 as opposed to no vlan at all. So a bit of a catch 22.
Someone more knowledgeable in proxmox is needed to figure this out. I think it's doable, but the vlan bs to the guest has to be mapped out correctly.
Maybe I am inferring wrong, but sort of confused on how you might be doing wan nic passthrough (iommu or sr-iov?) to UTM at the same time the proxmox host is using that same nic to do the wpa-auth?
In case I want to give this a try in the future, what steps did you use to do WPA-auth on the promox host?
In case I want to give this a try in the future, what steps did you use to do WPA-auth on the promox host?
Last edited:
My apologies. There are 2 servers involved. I was doing the host wpa auth on a test box so as not to muck up the main one.
On the main (production), utm has wan nic in pass through to sophos utm (suse linux based). Within utm nothing special at all is done with respect to vlan0. Literally wpa_sup references the certs, loads at boot time to handle eapol requests. Standard wan dhcp, no special flags or anything else set. Everything works great. Except I want to move away from UTM.
On the test box wpa_supplicant was installed to the host itself with nics presented to the vm (pfsense and utm) as virtio devices.
To handle wpa auth on the host I installed the wpa_supplicant package. Used the same wpa_supplicant.conf file from utm above. It doesn't change - still referencing the same certs and has same rg mac address. I confirm auth in wpa_cli. I can see the exchange occurring then "status" command indicates;
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
In the previous test scenario, wpa_auth was happening within the guest pfsense vm, with wan dhcp working properly. This is with the wan nic vlan0 being set in the proxmox network config. Quite confused why this isn't happening when wpa auth on the host.
I did try setting the host wan nic mac to that of rg. Auth works every time, but no dhcp.
On the main (production), utm has wan nic in pass through to sophos utm (suse linux based). Within utm nothing special at all is done with respect to vlan0. Literally wpa_sup references the certs, loads at boot time to handle eapol requests. Standard wan dhcp, no special flags or anything else set. Everything works great. Except I want to move away from UTM.
On the test box wpa_supplicant was installed to the host itself with nics presented to the vm (pfsense and utm) as virtio devices.
To handle wpa auth on the host I installed the wpa_supplicant package. Used the same wpa_supplicant.conf file from utm above. It doesn't change - still referencing the same certs and has same rg mac address. I confirm auth in wpa_cli. I can see the exchange occurring then "status" command indicates;
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
In the previous test scenario, wpa_auth was happening within the guest pfsense vm, with wan dhcp working properly. This is with the wan nic vlan0 being set in the proxmox network config. Quite confused why this isn't happening when wpa auth on the host.
I did try setting the host wan nic mac to that of rg. Auth works every time, but no dhcp.
I did some more testing today on the test box.
From scratch, got it to a state where wpa_sup auth worked within the pfsense guest. Then killed the daemon and re-enabled it on the host. It appears if wpa auth happens on the host, dhcp requests from the guest are not making it out.
Tried using the vlan and native interface as bridge members, no go.
Adding any vlan0 to the guest seems to break the host's wpa auth ability.
From scratch, got it to a state where wpa_sup auth worked within the pfsense guest. Then killed the daemon and re-enabled it on the host. It appears if wpa auth happens on the host, dhcp requests from the guest are not making it out.
Tried using the vlan and native interface as bridge members, no go.
Adding any vlan0 to the guest seems to break the host's wpa auth ability.
^^I can still get an ip in pfsense if I revert the network config so pf is doing the wpa auth. Also, reconnecting wan back to prod server, utm (where wan nic is passed through) was able to get an IP no problem.
If the ont was the issue, I'd expect to NOT get an ip on one or both of the above vm's.
If the ont was the issue, I'd expect to NOT get an ip on one or both of the above vm's.
Progress...
https://www.dslreports.com/forum/r33645618-
I will create a more detailed post later with all the details some others can reproduce.
https://www.dslreports.com/forum/r33645618-
I will create a more detailed post later with all the details some others can reproduce.
Further testing has revealed an unfortunate side effect of this vlan0 use. Using virtio for both wan/lan interfaces results in significantly higher cpu usage.
I can't compare apples/apples yet because I haven't gotten pf 23.01 to recognize eapol traffic when nic is in passthrough. However, this does work great with utm.
Running speed tests (speedtest windows app), download is saturated and upload is about 90-95% of line speed in pf. Cpu usage is a good 2-4x more compared to utm w/ wan in pass through. This is especially prevalent on the upload. In terms of watts;
utm (pass through) - ~105 watts
pf - ~115w (download) , 150-155w upload
Multiple queues are enabled in the virtio setting for both (at 4, as 4 vcpu's are allocated to pf vm).
With utm (pass through), upload saturates fully.
When I get a chance to take the network down again I'll try pf with passthrough using -vlanhwfilter option to see if that passes eapol traffic on the igb interface (i211).
This has all been quite the rabbit hole. In fact one i'd love to avoid but will be confronted with sooner or later as utm is going EOL. Office date is 6/2026, but it's been eol for some time now with no feature updates in at least 2 years, and bare minimal bug fixes along the way.
I can't compare apples/apples yet because I haven't gotten pf 23.01 to recognize eapol traffic when nic is in passthrough. However, this does work great with utm.
Running speed tests (speedtest windows app), download is saturated and upload is about 90-95% of line speed in pf. Cpu usage is a good 2-4x more compared to utm w/ wan in pass through. This is especially prevalent on the upload. In terms of watts;
utm (pass through) - ~105 watts
pf - ~115w (download) , 150-155w upload
Multiple queues are enabled in the virtio setting for both (at 4, as 4 vcpu's are allocated to pf vm).
With utm (pass through), upload saturates fully.
When I get a chance to take the network down again I'll try pf with passthrough using -vlanhwfilter option to see if that passes eapol traffic on the igb interface (i211).
This has all been quite the rabbit hole. In fact one i'd love to avoid but will be confronted with sooner or later as utm is going EOL. Office date is 6/2026, but it's been eol for some time now with no feature updates in at least 2 years, and bare minimal bug fixes along the way.
^^Thanks. Worth a shot.
It is curious why you didn't have to set the flag on the fwbr interface while others did. Wonder what's different.
If the vmbrx interfaces have the firewall option checkmarked, then the fwbr interface will also need to have the "8" flag set. Not sure why one would have the proxmox host firewall enabled as *sense (or whatever firewall vm) is doing the firewalling.
OK, I do not have the proxmox host firewall enabled on. In addition, I define this bridge at /etc/network/interfaces.d/eap_auth and my /etc/network/interfaces file has the below line: source /etc/network/interfaces.d/* so proxmox is blind to this bridge, but by memory this worked for me when I defined it in /etc/network/interfaces as well.If the vmbrx interfaces have the firewall option checkmarked, then the fwbr interface will also need to have the "8" flag set. Not sure why one would have the proxmox host firewall enabled as *sense (or whatever firewall vm) is doing the firewalling.
https://forum.proxmox.com/threads/h...y-tags-to-pfsense-for-dhcp.112374/post-544795
Sorry to necro this thread but did either of y'all ever figure this out? I'm migrating from ESXI and I'm (hopefully) trying to bring over OPNsense with the pfatt auth script. This is literally the only feature I cannot get parity or better yet.
I tried a few basic configs hoping I could pass through the port traffic unadulterated to OpnSense before googling and then finding this thread. It seems this is not as easy to do as I was hoping.
With ESXI it was easy because the network layer stripped out vlan0 but other than that did not seem to interfere.
I tried a few basic configs hoping I could pass through the port traffic unadulterated to OpnSense before googling and then finding this thread. It seems this is not as easy to do as I was hoping.
With ESXI it was easy because the network layer stripped out vlan0 but other than that did not seem to interfere.