pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
I'm suggesting that this was working in 22.01 at earlier because the driver was incorrectly stripping the tags and now after the fix it is not. FreeBSD now drops the traffic because that's what it's supposed top do with VLAN0.
The last snapshot that worked was built just before that fix was added. On the same day.At least I'm not crazy. :)
-
Ok, no difference.
Ok let's try to verify it is the switch doing this. Can you connect one of the access points to ix2 directly?
Otherwise lets get a laptop on one of the ports and see what's arriving at the other end.It looks very likely to be the switch. There's probably some combination of QoS settings that will allow it to work. Enabling it on an unused port. Enabling it on the ports we need (pfSense doesn't care about the priority tag).
Steve
-
@stephenw10
Yes I can, and I can validate by having Internet on My phone.
For example both WLANS are having the same tags as our VLANS. -
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Ok, no difference.
Ok let's try to verify it is the switch doing this. Can you connect one of the access points to ix2 directly?
Otherwise lets get a laptop on one of the ports and see what's arriving at the other end.It looks very likely to be the switch. There's probably some combination of QoS settings that will allow it to work. Enabling it on an unused port. Enabling it on the ports we need (pfSense doesn't care about the priority tag).
Steve
I did like you suggested:
pfSense->Unifi AP->Mobile Device
The only SSID that gets internet is the one without VLANS same with the switch.So it's not the switch. I excluded all the switches.
-
Ok, did you get a pcap from it?
You might have to run it without 'vlan' in case traffic is arriving untagged entirely.
-
Another test you could do would be to add a port on the switch as untagged in VLAN 20 with the pvid set to 20 and connect a host to it. Does it pull a lease from VLAN 20.
Steve
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Ok, did you get a pcap from it?
You might have to run it without 'vlan' in case traffic is arriving untagged entirely.
No I was connected only on my mobile device, but I can do the following:
- Connect with a laptop via Wi-fi
- Or directly to pfsense via cable
How do you prefer?
-
A pcap on ix2 in pfSense as before would show if it's still seeing the off double tagged traffic arrive. If it is that implies the AP is tagging it and the switch is just passing that.
Testing the switch without the AP would also confirm that.
-
@stephenw10 Yes but I want the same port to have both 20 and 30. Can I do that as you instructed? I mean let's take an AP, you will have multiple SSIDs but connected to different VLANs
-
@stephenw10
The tests done previously were done via wire, not wireless, the last test was done after you suggested to change the QOS setting.I'm not sure I follow what you suggest to do now.
-
Suggestion
Do you know how to make a "Monitor/Span Port" on the Switch ?
If yes ... You said you had a Manjaro Linux where you could run WireShark.Make a Monitor port on the switch , that monitors the port connected to pfSense , both RX & TX.
Connect wireshark to the Monitor port , and make a packet trace that way.
/Bingo
-
If you can make one VLAN work 100 will also work, that's not the issue.
There are two tests you can do.
Connect one of the APs directly to ix2. Run a pcap in pfSense on ix2 as you did before. Try to connect to the SSID using the VLAN and see what appears.
If you see nothing try running it without the 'vlan' option in case the traffic is arriving untagged.With the switch comnected to ix2 add a port as untagged in VLAN 20 with the pvid set to 20 and connect a host to it. Does it pull a lease from VLAN 20.
If not run a pcap in pfSense again to see what's happening.
You can also pcap on the wired host to see what that sees.Steve
-
@bingo600 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Suggestion
Do you know how to make a "Monitor/Span Port" on the Switch ?
If yes ... You said you had a Manjaro Linux where you could run WireShark.Make a Monitor port on the switch , that monitors the port connected to pfSense , both RX & TX.
Connect wireshark to the Monitor port , and make a packet trace that way.
/Bingo
I think you are referring to port mirroring, too many wires. But good idea :)
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
If you can make one VLAN work 100 will also work, that's not the issue.
There are two tests you can do.
Connect one of the APs directly to ix2. Run a pcap in pfSense on ix2 as you did before. Try to connect to the SSID using the VLAN and see what appears.
If you see nothing try running it without the 'vlan' option in case the traffic is arriving untagged.With the switch comnected to ix2 add a port as untagged in VLAN 20 with the pvid set to 20 and connect a host to it. Does it pull a lease from VLAN 20.
If not run a pcap in pfSense again to see what's happening.
You can also pcap on the wired host to see what that sees.Steve
Ok I'll start with the first one...
-
This test is like this:
- Connect AP directly to pfsense LAN port
- Connect a laptop wireless to Native LAN(via non tagged SSID) in order to access pfSense
- Start tcpdump on ix2
- Try to connect a mobile phone to VLAN 20 SSID
tcpdump -e -i ix2 vlan tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ix2, link-type EN10MB (Ethernet), capture size 262144 bytes 22:07:10.378711 cc:f4:11:c5:bc:81 (oui Unknown) > 33:33:00:0c:00:0c (oui Unknown), ethertype 802.1Q (0x8100), length 108: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::cef4:11ff:fec5:bc81.10101 > ff02::c:c.10101: UDP, length 38 22:07:10.378716 cc:f4:11:c5:bc:81 (oui Unknown) > 33:33:00:00:0c:0c (oui Unknown), ethertype 802.1Q (0x8100), length 108: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::cef4:11ff:fec5:bc81.10101 > ff05::c0c.10101: UDP, length 38 22:07:12.677777 dc:f5:05:4d:ec:1a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 358: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from dc:f5:05:4d:ec:1a (oui Unknown), length 308 22:07:14.649775 dc:f5:05:70:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 358: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from dc:f5:05:70:fa:8a (oui Unknown), length 308 22:07:14.678753 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 46: 01 02 22:07:14.830058 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:ff:47:dd:e1 (oui Unknown), ethertype 802.1Q (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, :: > ff02::1:ff47:dde1: ICMP6, neighbor solicitation, who has fe80::a715:fd20:be47:dde1, length 24 22:07:14.840986 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:16 (oui Unknown), ethertype 802.1Q (0x8100), length 98: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:07:14.997613 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 348: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:c5:e1:97:fa:ab (oui Unknown), length 298 22:07:15.393940 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:16 (oui Unknown), ethertype 802.1Q (0x8100), length 98: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:07:15.585986 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:02 (oui Unknown), ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::a715:fd20:be47:dde1 > ff02::2: ICMP6, router solicitation, length 16 22:07:15.585989 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:16 (oui Unknown), ethertype 802.1Q (0x8100), length 98: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::a715:fd20:be47:dde1 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:07:15.717065 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:16 (oui Unknown), ethertype 802.1Q (0x8100), length 98: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::a715:fd20:be47:dde1 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:07:16.145724 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 348: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:c5:e1:97:fa:ab (oui Unknown), length 298 22:07:18.122369 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 348: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:c5:e1:97:fa:ab (oui Unknown), length 298 22:07:19.424819 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:02 (oui Unknown), ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::a715:fd20:be47:dde1 > ff02::2: ICMP6, router solicitation, length 16 22:07:22.104277 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 348: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:c5:e1:97:fa:ab (oui Unknown), length 298 22:07:26.599913 08:c5:e1:97:fa:ab (oui Unknown) > 33:33:00:00:00:02 (oui Unknown), ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv6, fe80::a715:fd20:be47:dde1 > ff02::2: ICMP6, router solicitation, length 16 22:07:30.353091 08:c5:e1:97:fa:ab (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 348: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:c5:e1:97:fa:ab (oui Unknown), length 298 22:07:32.190446 dc:f5:05:3d:18:2d (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 358: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from dc:f5:05:3d:18:2d (oui Unknown), length 308
-
Ok, interesting. No outbound traffic there but there's no reason that should be any different.
We still see all the VLAN0 tagged traffic arriving which implies the APs are tagging it.I would bet if you run the second test with only the switch it will work fine.
What sort of QoS settings do you have on the APs?
Steve
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
would bet if you run the second test with only the switch it will work fine.
In a moment, I had to do some tricks for the tests :). Don't worry I cooperate :) Thank you for staying this long with me.
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Ok, interesting. No outbound traffic there but there's no reason that should be any different.
We still see all the VLAN0 tagged traffic arriving which implies the APs are tagging it.I would bet if you run the second test with only the switch it will work fine.
What sort of QoS settings do you have on the APs?
Steve
I don't think Ubiquity does that on AP. AFAIK you must purchase a router or a switch to achieve that, but I can look in the Unifi Network Controller .
I don't see nothing that I can turn on the AP regarding QoS. -
Last test as you instructed:
- Added port 7 to VLAN 20 group and marked the port Untagged
- Set PVID 20 to port 7
- Started tcpdump on pfsense for ix2
- Connected the cable to a desktop and to port 7
The desktop MAC is b4:2e:99:c7:b4:26
tcpdump.txt - sorry was too big
No lease, no internet
Maybe I should've removed port 7 from VLAN1 group also?
https://imgur.com/c5wOVI1 -
Hmm, well that's weird!
As long as you changed the PVID on port 7 to 20 then it would only be one way traffic anyway. I shouldn't prevent traffic VLAN20 working.
Were you able to take a pcap on the connected desktop?
It's hard to imagine what could be tagging that. It seems very unlikely the AP and switch would be doing so independently.
Steve