pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue
-
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Just a question, what we except to happen if set some priority to VLANS form pfSense?
Applying it on the VLAN should show in the VLAN tag outbound as expected like:
19:16:32.694149 00:90:7f:b4:38:fa (oui Unknown) > 90:ec:77:1f:8a:5f (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 1001, p 4, ethertype IPv4, AP300.stevew.lan > 10.101.0.1: ICMP echo request, id 10347, seq 1, length 64 19:16:32.694172 90:ec:77:1f:8a:5f (oui Unknown) > 00:90:7f:b4:38:fa (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 1001, p 3, ethertype IPv4, 10.101.0.1 > AP300.stevew.lan: ICMP echo reply, id 10347, seq 1, length 64pfSense sets prio 3 and the AP replies prio 4.
Try using port mode on your switch then. If you can set anything that appears in the pcap it might be useful.
Steve
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
ng that appears in the pcap it might be useful.
SteveFirst I selected Normal priority on the switch for the pfSense port and the AP port. The switch don't have numbers. Also I select 3 for VLAN 20 on pfSense.
I got this:
tcp_dump_vlan_prioriry_pfsense_and_switch.txtI lost connection after doing this, I could only connect to devices via their IPs
Then i reset the priority from VLAN 20 from pfSense to zero(0) and I got this:
tcp_dump_vlan_prioriry_on_switch.txt -
Those pcaps were on the mirror port again?
In both those pcaps there are no packets from pfSense at all....
Do you still see outbound packets if you tcpdump on ix2 on pfSense in either of those setups?
Steve
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Those pcaps were on the mirror port again?
In both those pcaps there are no packets from pfSense at all....
Do you still see outbound packets if you tcpdump on ix2 on pfSense in either of those setups?
Steve
Ok I redone the tests:
First test:
Steps:- Set priority to 3 in pfSense to VLAN 20
- Set Normal Priority in the switch to the port where the AP is connected
- Set High priority in the switch to the port where pfSense LAN side is connected.
- Done a tcpdump from pfSense.
Results:
tcpdump_priority_set_to pfsense_and_switch.txt
As you can see, only the priority (3) set in pfSense is intercepted.
Second test:
- Removed priority 3 set in pfSense to VLAN 20
- Left the Normal Priority in the switch to the port where the AP is connected
- Left the High priority in the switch to the port where pfSense LAN side is connected.
- Done a tcpdump from pfSense.
Results:
tcpdump_priority_set_to_switch.txtI don't see anu priorities besides (p0) when done from the switch.
I hope the steps are ok, now.
-
Hmm, OK.
Can I assume traffic was failing during those tests?
We see no ARP replies to pfSense's queries and it looks like one way traffic from the clients. -
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Hmm, OK.
Can I assume traffic was failing during those tests?
We see no ARP replies to pfSense's queries and it looks like one way traffic from the clients.Correct, I could communicate only via IP with pfSense. Only that worked.
-
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Correct, I could communicate only via IP with pfSense. Only that worked.
If you were not getting arp replies then wouldn't work even with IP..
-
@johnpoz said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Correct, I could communicate only via IP with pfSense. Only that worked.
If you were not getting arp replies then wouldn't work even with IP..
If you say so
-
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
If you say so
Not something making up dude - if you can not arp for the mac of something, it is impossible to talk to it even with an IP.
Mac is what is used to talk to something on a network.. Just not possible if you do not have the mac to talk to.
As Steve mentioned
We see no ARP replies to pfSense's queries and it looks like one way traffic from the clients.
Look at your arp table on your client, arp -a will show you the full table.. If there is no mac for an IP then your not going to talk to it.
-
@johnpoz said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
If you say so
Not something making up dude - if you can not arp for the mac of something, it is impossible to talk to it even with an IP.
Mac is what is used to talk to something on a network.. Just not possible if you do not have the mac to talk to.
As Steve mentioned
We see no ARP replies to pfSense's queries and it looks like one way traffic from the clients.
Look at your arp table on your client, arp -a will show you the full table.. If there is no mac for an IP then your not going to talk to it.
The host, the switch and pfSense have static IP. If it did not work, how I could provide the tcpdump?
As you can see the tcpdump is from ix2 interface,from pfSense, you can see that priority 3 set from pfSense.
Is this discussion productive, in any way ? Do you think I'm lying ? -
@nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
The host, the switch and pfSense have static IP. If it did not work
Then there must be an mac listed in the arp table.. Keep in mind that connecting to pfsense on its lan interface, and then sniffing on a different interface has little to do with if the clients on that other interface or vlan can arp for stuff..
You might see the arp request go out, or come in, but if you do not see replies then those devices that are arping for each other are not going to be able to talk to each other - period.
Don't think anyone is lying - just trying to understand all the pieces to the puzzle. I do recall looking at some of the sniffs and while I saw arp request, I don't recall ever seeing any answers.
-
So I did like that:
- I was connected via ssh to pfSense
- Set the priority to 3 from pfSense from GUI
- Set the priority from the switch
- After that all the hosts lost communication besides pfSense and the host I was running the test
- I performed a tcpdump on pfsense LAN interface ix2
- I could also connect to pfSense GUI via it's LAN IP, but not with it's domain name.
Other technicalities I don't know how to explain. If the test wasn't good, then this is how I understood to reproduce it, following what Steve has told me.
-
Right but the LAN interface here is ix2 unatgged, no VLAN right?
The pcap only captured VLAN tagged traffic, the GUEST interface, and it looked like that was failing?
It appeared as though the priority setting in the switch was in fact filtering the traffic in some way rather than applying tags. Which might well be what it's supposed to be doing in that mode.
Are you able to test that on your switch @johnpoz? -
@stephenw10 yeah my switch is still up, I could setup some vlans to go through it.
What exactly would you like me to test, doing port based qos? vs the 802.1p
Let me add the vlans to the switch, so I can just connect my AP to it, it has 1 untagged vlan and 3 other tagged vlans. 2 of which are tagged all the way to pfsense, and another that has its own uplink to pfsense that is untagged.
-
Yeah any test you can do there to see what those QoS settings it has do.
I expected it to apply tags but I have no idea if that's inbound or outbound on the ports.
However it looks more like it's filtering based on the tags from those last pcaps. No ARP replies to queries sent as
p 3. -
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
Right but the LAN interface here is ix2 unatgged, no VLAN right?
On the switch it looks like this, port 15, is ix2 and it is a member of all 3:
01 is VLAN1 which is untagged
20 is VLAN 20 tagged
30 is VLAN 30 taggedThe pcap only captured VLAN tagged traffic, the GUEST interface, and it looked like that was failing?
It appeared as though the priority setting in the switch was in fact filtering the traffic in some way rather than applying tags. Which might well be what it's supposed to be doing in that mode.
Are you able to test that on your switch @johnpoz?I run it like this:
tcpdump -e -i ix2 vlanMaybe that's why it captured only VLANs traffic. Should I redo the tests ?
-
No, that's fine we only want to see the VLAN tagged traffic there since that's what is failing.
The traffic on LAN (untagged in pfSense) still worked fine in 22.05.
-
@stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:
No, that's fine we only want to see the VLAN tagged traffic there since that's what is failing.
The traffic on LAN (untagged in pfSense) still worked fine in 22.05.
Yes it worked fine, only VLANs traffic are the problem on 22.05.
-
@stephenw10 let me find that flexHD ap I have laying around... I can then setup its own ssids so sure connected to it on different vlans.. So I don't have to disrupt my current network at all.
Been meaning to fire it up for updating its firmware and testing it anyway - use to be over at my sons house.. Think its in the garage ;)
-
I suspect the high priority setting you applied to port 15 in the switch filtered the
p 3tagged traffic coming into it so the clients never saw the ARP requests.You could repeat it with port 15 set to low and see if ARP replies then come back.
