Feature #12070
closed
Support for VLAN ``0``
Added by Michael LaCroix almost 3 years ago. Updated about 1 year ago.
100%
Description
Hello, I'm not sure if this should be a bug or feature request. Internet fiber providers in the USA and abroad tag their packets with vlan0 id and pfsense is unable to negotiate an IP address from their DHCP servers. Their are several 3rd party scripts out there that are being used to accommodate pfsense users who are using these services like myself. But, it would be so much better if pfsense can handle this itself without using such scripts. If a $30 dollar router off of a Walmart shelf can negotiate an IP address from these providers pfsense should also be able to. Thanks
Files
Updated by Marcos M almost 3 years ago
- File dhcp_vlan0_pcap.png dhcp_vlan0_pcap.png added
This would likely have to be resolved in FreeBSD itself. More details on the issue here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961
There have been workarounds using netgraph - most prominent is pfatt ( https://github.com/MonkWho/pfatt ) which can be adopted for VLAN0 specifically, e.g.:
#!/bin/sh
set -e
# LOCAL_IF: Device interface to use with netgraph
# UPSTREAM_MAC: MAC address of ISP device
# tap_ng0: Uses excluded interface name https://github.com/pfsense/pfsense/blob/8707550072636f852ed6755ed430174b307ab1e2/src/etc/inc/util.inc#L2401
LOCAL_IF='xx0'
UPSTREAM_MAC='xx:xx:xx:xx:xx:xx'
LOG=/var/log/vlan0bypass.log
getTimestamp(){
echo `date "+%Y-%m-%d %H:%M:%S :: [vlan0bypass] ::"`
}
{
echo "$(getTimestamp) LOCAL_IF: ${LOCAL_IF}"
echo "$(getTimestamp) UPSTREAM_MAC: ${UPSTREAM_MAC}"
echo -n "$(getTimestamp) attaching interfaces to ng_ether... "
/usr/local/bin/php -r "function_exists('pfSense_ngctl_attach') && pfSense_ngctl_attach('.', '${LOCAL_IF}');"
echo "OK!"
echo "$(getTimestamp) building netgraph nodes..."
echo -n "$(getTimestamp) creating vlan node and interface... "
/usr/sbin/ngctl mkpeer {$LOCAL_IF}: vlan lower downstream
/usr/sbin/ngctl name ${LOCAL_IF}:lower vlan0
/usr/sbin/ngctl mkpeer vlan0: eiface vlan0 ether
/usr/sbin/ngctl msg vlan0: 'addfilter { vlan=0 hook="vlan0" }'
/usr/sbin/ngctl msg tap_ng0: set ${UPSTREAM_MAC}
echo "OK!"
echo -n "$(getTimestamp) enabling ${LOCAL_IF} interface... "
/sbin/ifconfig ${LOCAL_IF} up
echo "OK!"
echo -n "$(getTimestamp) enabling promiscuous mode on ${LOCAL_IF}... "
/sbin/ifconfig ${LOCAL_IF} promisc
echo "OK!"
echo "$(getTimestamp) tap_ng0 should now be available to configure as WAN"
echo "$(getTimestamp) done!"
} >> $LOG
More info here:
https://forum.netgate.com/topic/160592/how-to-get-pfsense-wan-to-accept-vlan-0
Updated by Jim Pingle over 2 years ago
- Priority changed from High to Low
Anything that would potentially touch VLAN0 needs to be aware of potential security problems with it as well:
- https://blog.champtar.fr/VLAN0/
- https://lore.kernel.org/netdev/CAOdf3grDKBkYmt54ZAzG1zZ6zz1JXeoHSv67_Fc9-nRiY662mQ@mail.gmail.com/
- https://bugs.launchpad.net/neutron/+bug/1884341
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17040
- https://github.com/lxc/lxd/pull/7575
And likely more vendors to come as that is still being actively worked on by others.
Since FreeBSD and pfSense reject VLAN 0 by default that is currently a non-issue, but if that is relaxed then we must ensure it is done in a safe manner.
Updated by C HL over 2 years ago
Jim Pingle wrote in #note-2:
Anything that would potentially touch VLAN0 needs to be aware of potential security problems with it as well:
- https://blog.champtar.fr/VLAN0/
- https://lore.kernel.org/netdev/CAOdf3grDKBkYmt54ZAzG1zZ6zz1JXeoHSv67_Fc9-nRiY662mQ@mail.gmail.com/
- https://bugs.launchpad.net/neutron/+bug/1884341
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17040
- https://github.com/lxc/lxd/pull/7575
And likely more vendors to come as that is still being actively worked on by others.
Since FreeBSD and pfSense reject VLAN 0 by default that is currently a non-issue, but if that is relaxed then we must ensure it is done in a safe manner.
I see that Mellanox cards allow vlan 0 tagging in FreeBSD [https://docs.mellanox.com/display/FREEBSDv370/Quality+of+Service]. What is the expected behavior of pfsense when user runs "ifconfig {interface} pcp 2" for example?
Updated by Marcos M over 1 year ago
It seems this is fixed by:
https://reviews.freebsd.org/rGabf5bff71d38da3c797a3b6decb426c375cc0f8f
Updated by Steve Wheeler over 1 year ago
- Status changed from New to Feedback
- Target version set to 2.7.0
- Plus Target Version set to 22.11
This works in 2.7 and 22.11 with the exception of Intel e1000 NICs where vlan hardware filtering must currently be disabled.
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 22.11 to 23.01
Updated by Christopher Cope over 1 year ago
- Status changed from Feedback to Resolved
Tested on
23.01-DEVELOPMENT (amd64) built on Thu Nov 10 12:15:56 UTC 2022 FreeBSD 14.0-CURRENT
Working successfully with AT&T on my edge without the need for the pfatt script. Been using heavily with no issues.
Edit: A custom solution is still needed for AT&T, however the priority-tagged DHCP traffic with a VLAN ID of 0 now works natively.
Updated by Jim Pingle over 1 year ago
- Subject changed from VLAN0 for WAN DHCP to Support for VLAN ``0``
- Category changed from DHCP (IPv4) to Interfaces
Updating subject for release notes.
Updated by Jim Pingle over 1 year ago
- Tracker changed from Bug to Feature
- Start date deleted (
06/22/2021) - % Done changed from 0 to 100
- Affected Version deleted (
All) - Affected Architecture deleted (
All)
Updated by Matt Johnson over 1 year ago
Christopher Cope wrote in #note-7:
Tested on
[...]Working successfully with AT&T on my edge without the need for the pfatt script. Been using heavily with no issues.
Would you mind sharing how you were able to get this working, I have tried booting up and disabling vlanhwfilter and then running my wpa_supplicant and I am not able to get a successful authentication.
I have used this same supplicant config successfully on an ESXi install where I am able to set the vswitch to VLAN 0 and the MAC address to my RG's MAC and all I have to run is this wpa_supplicant and everything works.
Please post what commands you are running to be able to wpa_auth and receive a DHCP address on WAN.
Thanks in advance.
Updated by Matt Johnson about 1 year ago
Christopher Cope wrote in #note-7:
Tested on
[...]Working successfully with AT&T on my edge without the need for the pfatt script. Been using heavily with no issues.
Just following up on this request.
The request was closed as completed but nobody seems to know how to implement.
I have tried disabling vlanhwfilter (I have an Intel I350-t4 card effected by the unified e1000 driver bug) and then assigning a PCP attribute to the WAN interface (have tried 0, 1, 2, etc) and then ran my wpa_supplicant command and not been able to receive a DHCP address from At&t.
Here are the commands I was running
ifconfig igb0 -vlanhwfilter
(run ifconfig to confirm vlanhwfilter no longer is listed)
ifconfig igb0 pcp 1 (or 2, 0, etc)
(run ifconfig to confirm PCP setting)
Then I run the wpa_supplicant and authentication eventually times out.
This all still works using pfatt script BTW, but if possible I would rather not have to use netgraph.
Updated by Steve Wheeler about 1 year ago
For clarification this issue is marked resolved because pfSense can now accept priority tagged dhcp replies (vlan0). That means it will work with ISPs using this tagging by default.
It does not mean it will work with AT&T where 802.x authentication is required. For that to function the auth requests still need to be redirected using something like the pfatt netgraph script.
Updated by Matt Johnson about 1 year ago
Steve Wheeler wrote in #note-12:
For clarification this issue is marked resolved because pfSense can now accept priority tagged dhcp replies (vlan0). That means it will work with ISPs using this tagging by default.
It does not mean it will work with AT&T where 802.x authentication is required. For that to function the auth requests still need to be redirected using something like the pfatt netgraph script.
I noticed the fix was implemented at the dhclient level which is good but the original request was under the att bypass context.
And I understand you all are at the mercy of FreeBSD devs but it would be nice to have real VLAN0 support where we could actually create a VLAN0 interface like with other operating systems.
I guess it's just frustrating to get your hopes up on a solution only to find out it wasn't a solution.
Updated by Matt Johnson about 1 year ago
EDIT: thanks for the update Steve
I noticed the fix was implemented at the dhclient level which is good but the original request was under the att bypass context.
And I understand you all are at the mercy of FreeBSD devs but it would be nice to have real VLAN0 support where we could actually create a VLAN0 interface like with other operating systems.
I guess it's just frustrating to get your hopes up on a solution only to find out it wasn't a solution.
Updated by Steve Wheeler about 1 year ago
This specific feature request was opened to handle vlan0 for ISPs other than AT&T.
It is marked resolved because that is now possible without any sort of script.
AT&T is a special case but this is not the place to discuss it.
Updated by Matt Johnson about 1 year ago
Steve Wheeler wrote in #note-15:
This specific feature request was opened to handle vlan0 for ISPs other than AT&T.
It is marked resolved because that is now possible without any sort of script.
AT&T is a special case but this is not the place to discuss it.
Understood, my apologies