How to get pfSense WAN to accept VLAN 0
-
In my testing here neither igb or em appear to pass vlan0 tagged traffic. It doesn't appear in a pcap.
But other drivers do and pfSense will accept and respond to that without netgraph.So as I understand it the script does work in Opnsense / FreeBSD 13.1?
Can someone confirm that?If so it's either a regression in 14 or they have patched it themselves. Or they are using the kmod non-iflib driver.
Steve
-
@stephenw10 Opnsense works with em and vlan0.
-
@jarhead Hasn't Opnsense not had this problem at all (natively working with VLAN0)?
-
@schwiing Just since moving to FreeBSD 13. Had the same issue before 13 though, ie not accepting vlan0.
-
@jarhead Sounds right. I'd assume then with PFsense going to FreeBSD 14, this should be solved...maybe i wont need a switch between the ONT and Router.
-
@jarhead said in How to get pfSense WAN to accept VLAN 0:
Opnsense works with em and vlan0
And also without requiring a netgraph script?
@schwiing said in How to get pfSense WAN to accept VLAN 0:
I'd assume then with PFsense going to FreeBSD 14, this should be solved...
You would think but it doesn't appear to be the case so there must be more involved here.
-
@stephenw10 said in How to get pfSense WAN to accept VLAN 0:
@jarhead said in How to get pfSense WAN to accept VLAN 0:
Opnsense works with em and vlan0
And also without requiring a netgraph script?
Correct.
-
Hmm, looks like they are using identical drivers.
Did you test with em or igb specifically? Though they are the same driver.... except if they're not!
-
@stephenw10 would anyone be able to test with ix?
-
It works with ix with the netgraph script in 2.6 and I expect it to work with ix without a script in 2.7 because main has the vlan0 dhclient patch.
It's worth trying that on em/igb too since I can't see any different there. Though I can't see how it could work given it doesn't even appear in a pcap. I could be missing something....
-
I loaded opnsense onto that same backup router and I can’t get it to work on em0. I even went into the attic, got the ISP router to formally release the IP and still no go. So not sure how people are getting it to work on opnsense. I’m on Frontier fiber College Station, Texas.
-
Ah, well that would make more sense. Still seem to be conflicting reports.
I suspect there are other issues at work and people have just assumed it was the e1000 driver problem because that's known to exist.
As far as I can see the new CE snapshots should respond exactly like the current OPNSense does. Still running some tests though.
Steve
-
@stephenw10 said in How to get pfSense WAN to accept VLAN 0:
Hmm, looks like they are using identical drivers.
Did you test with em or igb specifically? Though they are the same driver.... except if they're not!
I use a Protectli Vault with em interfaces.
Plug it right into the ONT and it works. -
@c45p32 said in How to get pfSense WAN to accept VLAN 0:
I loaded opnsense onto that same backup router and I can’t get it to work on em0. I even went into the attic, got the ISP router to formally release the IP and still no go. So not sure how people are getting it to work on opnsense. I’m on Frontier fiber College Station, Texas.
What version of Opnsense?
I see the latest has all kinds of problems.
Try 22.7. Works with em drivers. Plug drirectly into the ONT. -
If you run a pcap can you see the vlan0 tagged dhcp responses?
-
I just tested the latest pfsense dev image using em0 as my wan interface and it was able to pickup an IP address. I'm using frontier fiber and was directly connected to the ONT.
This is hopeful... -
Yes that is useful.
It would be very interesting to see if those DHCP replies appear in a pcap. I wasn't able to see vlan0 tagged pings but perhaps some off-loading allows the udp dhcp packets....
-
Ok, after a bunch of testing it appears the difference here is in OPN pretty much all hardware offloading is disabled by default and we have most things enabled. Including VLAN Hardware Filtering which appears to be broken for VLAN0 in the iflib e1000 driver.
Manually disabling it allowed my test boxes to pull a dhcp lease from a server that is priority tagging replies:
ifconfig em2 -vlanhwfilter01:04:04.652627 00:90:7f:87:dc:77 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:90:7f:87:dc:77, length 300, xid 0x7b209734, Flags [none] (0x0000) 01:04:04.654209 90:ec:77:1f:8a:62 > 00:90:7f:87:dc:77, ethertype 802.1Q (0x8100), length 346: vlan 0, p 4, ethertype IPv4, (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.14.0.1.67 > 10.14.0.12.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x7b209734, Flags [none] (0x0000)None of my tests allowed any client to see the servers replies with vlan hardware filtering still enabled. However I could imagine there might be em or igb NICs that don't support VLAN hardware filtering that would not be affected. That could explain the conflicting results we see here.
Anyway if you're seeing this issue try disabling VLAN_HWFILTER.Steve
-
@stephenw10 Well holy crap batman, that worked. With all default settings:
Hardware Checksum Offloading: enable
Disable hardware TCP segmentation offload: disabled
Disable hardware large receive offload: disabled
and just setting ifconfig em0 -vlanhwfilter I was able to pull an IP address and surf the internet. -
@c45p32
Are you saying this works on 2.6?
