Project

General

Profile

Actions
Copy link

Feature #12070

closed

Support for VLAN ``0``

Added by Michael LaCroix over 3 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Category:
Interfaces
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default

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

dhcp_vlan0_pcap.png (18 KB) dhcp_vlan0_pcap.png Marcos M, 07/13/2021 12:40 PM
Actions
Copy link
 #1

Updated by Marcos M over 3 years ago

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

Actions
Copy link
 #2

Updated by Jim Pingle about 3 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:

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.

Actions
Copy link
 #3

Updated by C HL almost 3 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:

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?

Actions
Copy link
 #5

Updated by Steve Wheeler about 2 years 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.

See: https://redmine.pfsense.org/issues/12821

Actions
Copy link
 #6

Updated by Jim Pingle about 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions
Copy link
 #7

Updated by Christopher Cope about 2 years 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.

Actions
Copy link
 #8

Updated by Jim Pingle almost 2 years 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.

Actions
Copy link
 #9

Updated by Jim Pingle almost 2 years 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)
Actions
Copy link
 #10

Updated by Matt Johnson almost 2 years 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.

Actions
Copy link
 #11

Updated by Matt Johnson almost 2 years 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.

Actions
Copy link
 #12

Updated by Steve Wheeler over 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.

Actions
Copy link
 #13

Updated by Matt Johnson over 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.

Actions
Copy link
 #14

Updated by Matt Johnson over 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.

Actions
Copy link
 #15

Updated by Steve Wheeler over 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.

Actions
Copy link
 #16

Updated by Matt Johnson over 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

Actions
Copy link

Also available in: Atom PDF