Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue

    Scheduled Pinned Locked Moved L2/Switching/VLANs
    247 Posts 7 Posters 85.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      NRgia @stephenw10
      last edited by

      @stephenw10
      how, if nothing works ?

      johnpozJ 1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Try to ping something in the VLAN20 subnet and it will ARP for it.

        N 1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator @NRgia
          last edited by johnpoz

          @nrgia trying pinging some IP from pfsense, it would for sure atleast send arps that would be tagged or should be.

          edit: haha jinx :) great minds think a like it seems ;)

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Yeah so try running: tcpdump -e -i ix2 vlan

            Then try to ping anything in the vlan 20 or 30 subnets from pfSense. You should see at least the ARP traffic and how it's tagged.

            N 1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Are you running any version of the netgraph vlan0 tagging scripts for your WAN?

              N 2 Replies Last reply Reply Quote 0
              • N
                NRgia @stephenw10
                last edited by NRgia

                @stephenw10
                So I pinged 192.168.10.56 which is that Smart hub. From pfsense on the native LAN ->VLAN 20

                16:22:15.815491 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28
16:22:15.829472 d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, RRCP-0x25 query
16:22:16.063582 90:e6:ba:31:03:2f (oui Unknown) > 01:00:5e:7f:ff:fa (oui Unknown), ethertype IPv4 (0x0800), length 143: Sperry.Blueshift.63312 > 239.255.255.250.ssdp: UDP, length 101
16:22:16.066237 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.129.102, length 46
16:22:16.336837 08:36:c9:2a:16:e7 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: 08:36:c9:2a:16:e7 (oui Unknown) > Broadcast, RRCP-0x23 reply
16:22:16.507280 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 598: 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 28:6d:97:7f:bb:0c (oui Unknown), length 548
16:22:16.529972 cc:40:d0:52:32:7d (oui Unknown) > 01:80:c2:00:00:40 (oui Unknown), ethertype Slow Protocols (0x8809), length 60: unknown (136), length 46
        0x0000:  880f 0000 0000 0000 0000 0000 0000 0000
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000
16:22:16.823906 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28
16:22:16.830303 d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, RRCP-0x25 query
16:22:17.105431 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.129.102, length 46
16:22:17.213672 80:ee:73:bb:0e:55 (oui Unknown) > ac:1f:6b:45:fa:8a (oui Unknown), ethertype IPv4 (0x0800), length 92: 172.18.0.5.37282 > Entaro.Blueshift.nut: Flags [P.], seq 503429173:503429199, ack 3130284466, win 1027,
options [nop,nop,TS val 1992520480 ecr 754440160], length 26
16:22:17.213730 ac:1f:6b:45:fa:8a (oui Unknown) > 80:ee:73:bb:0e:55 (oui Unknown), ethertype IPv4 (0x0800), length 66: Entaro.Blueshift.nut > 172.18.0.5.37282: Flags [.], ack 26, win 514, options [nop,nop,TS val 754445177
ecr 1992520480], length 0
16:22:17.213804 ac:1f:6b:45:fa:8a (oui Unknown) > 80:ee:73:bb:0e:55 (oui Unknown), ethertype IPv4 (0x0800), length 93: Entaro.Blueshift.nut > 172.18.0.5.37282: Flags [P.], seq 1:28, ack 26, win 514, options [nop,nop,TS val 754445177
ecr 1992520480], length 27
16:22:17.256772 80:ee:73:bb:0e:55 (oui Unknown) > ac:1f:6b:45:fa:8a (oui Unknown), ethertype IPv4 (0x0800), length 66: 172.18.0.5.37282 > Entaro.Blueshift.nut: Flags [.], ack 28, win 1027, options [nop,nop,TS val 1992520523
ecr 754445177], length 0
16:22:17.829565 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28
16:22:17.831107 d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, RRCP-0x25 query
16:22:18.145452 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.129.102, length 46
16:22:18.164338 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
16:22:18.336871 08:36:c9:2a:16:e7 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: 08:36:c9:2a:16:e7 (oui Unknown) > Broadcast, RRCP-0x23 reply
16:22:18.532211 cc:40:d0:52:32:7d (oui Unknown) > 01:80:c2:00:00:40 (oui Unknown), ethertype Slow Protocols (0x8809), length 60: unknown (136), length 46
        0x0000:  880f 0000 0000 0000 0000 0000 0000 0000
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000
16:22:18.831961 d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, RRCP-0x25 query
16:22:18.832041 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28
16:22:18.832237 ac:1f:6b:45:fa:8a (oui Unknown) > 90:e6:ba:31:03:2f (oui Unknown), ethertype IPv4 (0x0800), length 134: Entaro.Blueshift.6675 > Sperry.Blueshift.2463: Flags [P.], seq 177:257, ack 64, win 65535, length 80
16:22:18.873300 90:e6:ba:31:03:2f (oui Unknown) > ac:1f:6b:45:fa:8a (oui Unknown), ethertype IPv4 (0x0800), length 60: Sperry.Blueshift.2463 > Entaro.Blueshift.6675: Flags [.], ack 257, win 63536, length 0
16:22:19.832759 d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, ethertype RRCP (0x8899), length 60: d8:0d:17:4e:7a:13 (oui Unknown) > Broadcast, RRCP-0x25 query
16:22:19.844918 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28
16:22:19.845097 ac:1f:6b:45:fa:8a (oui Unknown) > 90:e6:ba:31:03:2f (oui Unknown), ethertype IPv4 (0x0800), length 134: Entaro.Blueshift.6675 > Sperry.Blueshift.2463: Flags [P.], seq 257:337, ack 64, win 65535, length 80
16:22:19.885283 90:e6:ba:31:03:2f (oui Unknown) > ac:1f:6b:45:fa:8a (oui Unknown), ethertype IPv4 (0x0800), length 60: Sperry.Blueshift.2463 > Entaro.Blueshift.6675: Flags [.], ack 337, win 63456, length 0
16:22:20.106267 90:e6:ba:31:03:2f (oui Unknown) > 01:00:5e:7f:ff:fa (oui Unknown), ethertype IPv4 (0x0800), length 143: Sperry.Blueshift.63312 > 239.255.255.250.ssdp: UDP, length 101
16:22:20.108822 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.129.102, length 46
16:22:20.161707 80:ee:73:bb:0e:55 (oui Unknown) > ac:1f:6b:45:fa:8a (oui Unknown), ethertype IPv4 (0x0800), length 82: 172.18.0.5.51157 > Entaro.Blueshift.nut: Flags [P.], seq 3582196994:3582197010, ack 3023361596, win 1027,
options [nop,nop,TS val 3498492293 ecr 4079702838], length 16
16:22:20.161765 ac:1f:6b:45:fa:8a (oui Unknown) > 80:ee:73:bb:0e:55 (oui Unknown), ethertype IPv4 (0x0800), length 66: Entaro.Blueshift.nut > 172.18.0.5.51157: Flags [.], ack 16, win 514, options [nop,nop,TS val 4079712813
ecr 3498492293], length 0

                172.18.0.0 is the native LAN

                the dump is on ix2

                1 Reply Last reply Reply Quote 0
                • N
                  NRgia @stephenw10
                  last edited by

                  @stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:

                  netgraph

                  I saw "netgraph"in that defect. So If I don't know what it means, I think I don't use it.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    @nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:

                    16:22:16.823906 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.56 tell 192.168.10.1, length 28

                    Ok, so we see pfSense sending traffic as expected. But no response. Presumably because that device is behind some sort of odd double tagging somehow.

                    Can you try pinging something else in that subnet?

                    N 1 Reply Last reply Reply Quote 0
                    • N
                      NRgia @stephenw10
                      last edited by

                      @stephenw10 how do you want the dump to be, on ix2(Native) or ix2.20(VLAN)?

                      1 Reply Last reply Reply Quote 0
                      • N
                        NRgia @stephenw10
                        last edited by

                        @stephenw10 No VLANS on WAN, just on LAN ix2 interface

                        1 Reply Last reply Reply Quote 0
                        • N
                          NRgia @stephenw10
                          last edited by

                          @stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:

                          Yeah so try running: tcpdump -e -i ix2 vlan

                          Then try to ping anything in the vlan 20 or 30 subnets from pfSense. You should see at least the ARP traffic and how it's tagged.

                          Ok did what you asked:

                          pinged another 192.168.10.58

                           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
16:44:07.012079 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, et                                                                                                                           hertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:07.089429 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, e                                                                                                                           thertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:07.531974 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 598: vlan 0, p 0, e                                                                                                                           thertype 802.1Q, vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 2                                                                                                                           8:6d:97:7f:bb:0c (oui Unknown), length 548
16:44:07.751772 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, e                                                                                                                           thertype ARP, Request who-has 192.168.10.60 tell 192.168.10.1, length 28
16:44:08.090969 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, et                                                                                                                           hertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:08.116574 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, e                                                                                                                           thertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:09.121573 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:09.131032 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:09.191236 cc:f4:11:c5:bc:81 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 350: 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 cc:f4:11:c5:bc:81 (oui Unknown), length 300
16:44:10.048919 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
16:44:10.048986 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
16:44:10.166995 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:10.532377 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 598: 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 28:6d:97:7f:bb:0c (oui Unknown), length 548
16:44:11.180544 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:12.204575 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:13.037319 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:13.194665 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
16:44:13.220498 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:14.091153 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:14.222187 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:14.532642 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 598: 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 28:6d:97:7f:bb:0c (oui Unknown), length 548
16:44:15.131325 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:15.229386 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:16.253933 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:17.074123 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:17.285564 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:17.872307 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
16:44:18.091162 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:18.288921 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:18.532216 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 598: 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 28:6d:97:7f:bb:0c (oui Unknown), length 548
16:44:19.131218 28:6d:97:7f:bb:0c (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has Sperry.Blueshift tell 169.254.231.56, length 46
16:44:19.290397 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:20.314943 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
16:44:20.723599 ac:1f:6b:45:fa:8a (oui Unknown) > 01:00:5e:00:00:fb (oui Unknown), ethertype 802.1Q (0x8100), length 140: vlan 20, p 0, ethertype IPv4, 192.168.10.1.mdns > 224.0.0.251.mdns: 0 [2q] PTR (QM)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QM)? _googlecast._tcp.local. (94)
16:44:20.724545 ac:1f:6b:45:fa:8a (oui Unknown) > 01:00:5e:00:00:fb (oui Unknown), ethertype 802.1Q (0x8100), length 402: vlan 20, p 0, ethertype IPv4, 192.168.10.1.mdns > 224.0.0.251.mdns: 0*- [0q] 4/0/0 PTR SHIELD-Android-TV-ee41442d2c14cc09fde82be16f84be32._googlecast._tcp.local., (Cache flush) A 172.18.0.14, (Cache flush) SRV ee41442d-2c14-cc09-fde8-2be16f84be32.local.:8009 0 0, (Cache flush) TXT "id=ee41442d2c14cc09fde82be16f84be32" "cd=3CABD325728E72997BA6735F95651E36" "rm=" "ve=05" "md=SHIELD Android TV" "ic=/setup/icon.png" "fn=SHIELD" "ca=463365" "st=0" "bs=FA8F14F198FB" "nf=1" "rs=" (356)
16:44:20.744088 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.60 tell 192.168.10.1, length 28
16:44:21.378435 ac:1f:6b:45:fa:8a (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 192.168.10.58 tell 192.168.10.1, length 28
^C
37 packets captured
6046 packets received by filter
0 packets dropped by kernel
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            The native (parent) NIC. We need to see the tagged traffic in the pcap and capturing on the VLAN removes that.

                            Using tcpdump -e -i ix2 vlan will show only VLAN tagged traffic which will make things easier to read.

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Hmm, so that clarifies what we saw before. The only incoming traffic is strangely double tagged.

                              But that does prove we can see incoming tagged traffic. Which implies nothing else is sending VLAN 20 tagged replies.

                              Do devices at .58 and .60 actually exist? Can you check for the incoming ARP requests there?

                              There has been some driver changes in ix including that specific fix for VLAN0 traffic but that was before 22.01 not between that and 22.05....

                              N 2 Replies Last reply Reply Quote 0
                              • N
                                NRgia @stephenw10
                                last edited by NRgia

                                @stephenw10 said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:

                                Hmm, so that clarifies what we saw before. The only incoming traffic is strangely double tagged.

                                But that does prove we can see incoming tagged traffic. Which implies nothing else is sending VLAN 20 tagged replies.

                                Do devices at .58 and .60 actually exist? Can you check for the incoming ARP requests there?

                                There has been some driver changes in ix including that specific fix for VLAN0 traffic but that was before 22.01 not between that and 22.05....

                                This is what I have on DHCP leases screen:

                                https://imgur.com/a/FOgNOyU

                                They exist but they are offline

                                Only IOT devices are on these VLANS, most of them are Wireless, the only one wired is 192.168.10.58 and connected to a specific port.

                                The last pfSense that worked(besides 22.01), to have timeline, was pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916. After that all snapshots behaved like it is now.

                                1 Reply Last reply Reply Quote 0
                                • N
                                  NRgia @stephenw10
                                  last edited by

                                  @stephenw10 Can we try something else...I don't try to be smart or anything, but how do I set those 2 VLANS to have PROMISC tag? I know it works for you. But maybe we can try

                                  johnpozJ 1 Reply Last reply Reply Quote 0
                                  • johnpozJ
                                    johnpoz LAYER 8 Global Moderator @NRgia
                                    last edited by

                                    @nrgia said in pfSense 22.05 breaks VLANS, restoring pfSense 22.01 fixes the issue:

                                    VLANS to have PROMISC tag?

                                    just set it with ifconfig

                                    here
                                    goforit.jpg

                                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                                    If you get confused: Listen to the Music Play
                                    Please don't Chat/PM me for help, unless mod related
                                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                                    N 1 Reply Last reply Reply Quote 0
                                    • N
                                      NRgia @johnpoz
                                      last edited by NRgia

                                      @johnpoz
                                      Yep figured it out from here https://www.freebsd.org/cgi/man.cgi?ifconfig

                                      As you said, it does not work but I had to try. Don't get my wrong, thank you both for what you did until now. I'm just desperate. :)

                                      I'm open to ideas, if you still have any.

                                      Would it be useful to compare with a dump from 22.01, to see how vlans are handled there in my case? Should I revert back for now? Or should we try something else?

                                      johnpozJ 1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        I would get a laptop on an access port on one of those VLANs so you can see what's happening at that end.

                                        It's possible something got fixed and that has broken your setup because the double tagged traffic is now dropped as expected.
                                        We don't see double tagged ARP replies from those devices though so it's unclear if they ever see the requests.

                                        What is handling the VLANs in between? How is it configured?

                                        Steve

                                        N 1 Reply Last reply Reply Quote 0
                                        • johnpozJ
                                          johnpoz LAYER 8 Global Moderator @NRgia
                                          last edited by

                                          @nrgia if I had to "guess" something changed in the driver with that 0 tag.. that is a "guess".. @stephenw10 might have some other stuff to try/look at.

                                          An intelligent man is sometimes forced to be drunk to spend time with his fools
                                          If you get confused: Listen to the Music Play
                                          Please don't Chat/PM me for help, unless mod related
                                          SG-4860 24.11 | Lab VMs 2.8, 24.11

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by stephenw10

                                            We know that something did change: https://github.com/pfsense/FreeBSD-src/commit/9c762cc125c0c2dae9fbf49cc526bb97c14b54a4

                                            Hence my suggestion that it could be the VLAN0 tags were being incorrectly passed in 22.01 and before that 'fix'.

                                            There shouldn't be any VLAN0 tagging happening here though.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.