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

    LAN without subnet access only on WiFi

    Scheduled Pinned Locked Moved General pfSense Questions
    20 Posts 4 Posters 508 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.
    • S
      ShiShiyoPomPom
      last edited by ShiShiyoPomPom

      Hi !!! ^^

      I've deployed a pfsense to separate my networks.

      LAN (lan) -> igc1 -> v4: 192.168.101.1/24
DMZ (opt1) -> igc2 -> v4: 10.101.0.1/24
ETH_IOT (opt2) -> igc3 ->
VLAN_IOT (opt3) -> igc1. 10 ->
IOT (opt4) -> bridge0 -> v4: 10.10.0.1/24
VPN_WIREGUARD (opt5) -> tun_wg0 -> v4: 192.168.102.1/24
GUEST (opt7) -> igc1.170 -> v4: 172.16.10.1/2

bridge0 = opt2 + opt3

      WiFi is managed by a TEW-923DAP :

      • it is connected to port 1 (igc1) of the pfsense.
      • it broadcasts 3 SSIDs: 1 for the LAN (my PCs, smartphone, etc) (without VLAN tag), 1 for the home automation (Shelly) (with VLAN tag), 1 for the Guest (with VLAN tag).

      Problem:
      I can't reach the web page of a Shelly modules from a laptop or smartphone connected to the WiFi SSID "LAN".

      However, I see the request "to port 80" in "Status/System Logs/Firewall" and in "Diagnostics/States" ...

      for example :

      LAN tcp 192.168.101.121:42028 > 10.10.0.121:80 ESTABLISHED:ESTABLISHED 23/3
IoT tcp 192.168.101.121:42028 > 10.10.0.121:80 ESTABLISHED:ESTABLISHED 12/3

      If I use the VPN (WireGuard), it works perfectly: My Shellys' web pages are displayed correctly.....

      I've tried putting a (non-manageable) switch between the pfSense and the TEW-923DAP to connect a wired PC: this also works, the PC accesses and displays the pages.

      In “System/Advanced/System Tunables” I've added :

      net.link.bridge.pfil_bridge > Value : 1
net.link.bridge.pfil_member > Value : 0
net.inet.ip.portrange.reservedhigh > Value : 0

      I don't understand my error... T_T
      A setting in pfSense? A setting in TEW-923DAP?

      Have I missed the basics of configuring my pfSense?

      Thanks !!! x)

      V stephenw10S 2 Replies Last reply Reply Quote 0
      • V
        viragomann @ShiShiyoPomPom
        last edited by

        @ShiShiyoPomPom said in LAN without subnet access only on WiFi:

        However, I see the request "to port 80" in "Status/System Logs/Firewall" and in "Diagnostics/States" ...

        for example :

        LAN tcp 192.168.101.121:42028 > 10.10.0.121:80 ESTABLISHED:ESTABLISHED 23/3
        IoT tcp 192.168.101.121:42028 > 10.10.0.121:80 ESTABLISHED:ESTABLISHED 12/3

        This seems like the HA is not responding. Some devices block access from outside, but

        If I use the VPN (WireGuard), it works perfectly: My Shellys' web pages are displayed correctly.....

        if this was the reason WireGuard wouldn't work as well.

        So there might be something going wrong in the AP. Maybe it cannot handle well with tagged and untagged networks on the interface. So you can try to tag the LAN as well.

        Also ensure that the AP has no router configuration and that it doesn't run a DHCP server.

        1 Reply Last reply Reply Quote 0
        • S
          ShiShiyoPomPom
          last edited by

          Thank you for your reply.

          The paradox is as follows:

          • When testing with the PC wired (by adding a switch) (So on the same subnet as the TEW-923DAP and “LAN” SSID clients - 192.168.101.1/24 without VLAN tag) I have no problem displaying the web page.

          Diagramme sans nom-Page-5.drawio.png

          • If I ping PfSense > Module Shelly (WiFi IoT) : The ping works and responds

          • If I ping the laptop WiFi (LAN) > Module Shelly (WiFi IoT): The ping also works and responds......

          As if only port 80 or TCP had a problem....

          the Wireguard and LAN interfaces have the same firewall rules / access rights to the IoT subnet

          (And I tested allowing everything on LAN and IoT, it didn't solve anything)

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @ShiShiyoPomPom
            last edited by

            @ShiShiyoPomPom said in LAN without subnet access only on WiFi:

            As if only port 80 or TCP had a problem....

            Yeah, TCP is a stateful protocol, ICMP isn't.

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

              @ShiShiyoPomPom said in LAN without subnet access only on WiFi:

              In “System/Advanced/System Tunables” I've added :

              net.link.bridge.pfil_bridge > Value : 1
              net.link.bridge.pfil_member > Value : 0

              You have filtering on the bridge but you don't have the bridge assigned so you can't add a pass rule on it. I'd expect to see firewall blocks logged though. But I'd still try assigning bridge0 and adding a pass rule on it.

              Then I'd try grabbing a pcap on either of those interfaces to see what's actually happening. The packet counts should be the same on both.

              1 Reply Last reply Reply Quote 0
              • S
                ShiShiyoPomPom
                last edited by

                I had understood in the doc ( https://docs.netgate.com/pfsense/en/latest/bridges/firewall.html) that “net.link.bridge.pfil_bridge/member” is used to define “Where are the rules for ‘bridged’ interfaces, and has no impact on ”non-bridged" interfaces. My bad ?

                And I have a bridge: bridge0 = opt2 + opt3

                On “ETH_IOT (opt2) -> igc3” I have a PowerLine for Shelly in my garage (by the way, their web page display works from a WiFi SSID client LAN...... )

                So it seems that only the TCP “WiFi LAN > WiFi IoT” is a problem...

                However, it changes subnet (192.168.101.1/24 >> 10.10.0.1/24), so it has to go through the pfSense to be routed, so why are only WiFi client requests not working....

                Knowing that there's no problem for the Internet (websites being in TCP 443 most of the time) :

                • My LAN SSID clients: OK for browsing
                • My IoT SSID clients : OK for checking and downloading updates.
                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  I agree I'd expect that to work. So move on to grabbing pcaps on both and see what's happening. I expect to see the server sending rejections.

                  1 Reply Last reply Reply Quote 0
                  • S
                    ShiShiyoPomPom
                    last edited by

                    OK OK...

                    Sorry about my level, but concretely, how do I set up this pcaps “monitoring”?

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

                      I would do it from the GUI in Diag > Packet Capture. Just capture on each interface and filter by the server IP. Then try to connect and see what's happening. The fact there are more packets on the LAN makes me suspect the client is sending repeated requests.

                      1 Reply Last reply Reply Quote 0
                      • S
                        ShiShiyoPomPom
                        last edited by

                        Top ! thanks
                        I didn't know (I had never tried) this tool... I'm making life difficult for myself by quickly looking in the “States”.

                        So :

                        With wired client :
- @LAN :
17:03:07.003275 IP 192.168.101.131.50533 > 10.10.0.87.80: tcp 6
17:03:07.026635 IP 192.168.101.131.50629 > 10.10.0.87.80: tcp 0
17:03:07.097739 IP 10.10.0.87.80 > 192.168.101.131.50629: tcp 0
17:03:07.097964 IP 10.10.0.87.80 > 192.168.101.131.50533: tcp 0
17:03:07.098375 IP 192.168.101.131.50629 > 10.10.0.87.80: tcp 0
17:03:07.098617 IP 192.168.101.131.50629 > 10.10.0.87.80: tcp 494
17:03:07.098960 IP 10.10.0.87.80 > 192.168.101.131.50533: tcp 0
17:03:07.107643 IP 10.10.0.87.80 > 192.168.101.131.50629: tcp 0
17:03:07.110377 IP 10.10.0.87.80 > 192.168.101.131.50629: tcp 168
17:03:07.111027 IP 192.168.101.131.50629 > 10.10.0.87.80: tcp 0
17:03:07.115042 IP 10.10.0.87.80 > 192.168.101.131.50629: tcp 0
17:03:07.116044 IP 192.168.101.131.50629 > 10.10.0.87.80: tcp 0
17:03:07.791264 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:07.813307 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:03:07.825608 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:07.825817 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 521
17:03:07.830736 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:03:07.834558 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 155
17:03:07.844621 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 115
17:03:07.869488 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 668
17:03:07.876153 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 113
17:03:07.911890 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 1340
17:03:07.966882 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:08.018336 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 841
17:03:08.045509 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 113
17:03:08.070721 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 772
17:03:08.090945 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 84
17:03:08.091037 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 89
17:03:08.091661 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 83
17:03:08.091755 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 92
17:03:08.092763 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 104
17:03:08.108541 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 84
17:03:08.116477 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:03:08.117393 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:03:08.118042 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:03:08.119049 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 120
17:03:08.169383 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:08.493248 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 1340
17:03:08.494623 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 1340
17:03:08.494831 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:08.495695 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 200
17:03:08.547563 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:08.550751 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 265
17:03:08.610492 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 0
17:03:38.420998 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 2
17:03:38.421486 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 6
17:03:38.521392 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0

- @IoT
17:12:05.509360 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 6
17:12:05.534699 IP 192.168.101.131.50721 > 10.10.0.87.80: tcp 0
17:12:05.621841 IP 10.10.0.87.80 > 192.168.101.131.50721: tcp 0
17:12:05.622130 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:12:05.622931 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:12:05.630138 IP 192.168.101.131.50721 > 10.10.0.87.80: tcp 0
17:12:05.630461 IP 192.168.101.131.50721 > 10.10.0.87.80: tcp 494
17:12:05.634962 IP 10.10.0.87.80 > 192.168.101.131.50721: tcp 0
17:12:05.637546 IP 10.10.0.87.80 > 192.168.101.131.50721: tcp 168
17:12:05.667636 IP 192.168.101.131.50721 > 10.10.0.87.80: tcp 0
17:12:05.671626 IP 10.10.0.87.80 > 192.168.101.131.50721: tcp 0
17:12:05.674091 IP 192.168.101.131.50721 > 10.10.0.87.80: tcp 0
17:12:05.894555 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:05.927416 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 0
17:12:05.927579 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:05.927781 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 521
17:12:05.935388 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 155
17:12:05.996858 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:06.171617 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 115
17:12:06.254573 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 668
17:12:06.255772 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 113
17:12:06.293079 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 1340
17:12:06.342640 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:06.440079 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 841
17:12:06.440802 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 113
17:12:06.464473 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 772
17:12:06.469518 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 84
17:12:06.469602 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 89
17:12:06.469915 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 83
17:12:06.469962 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 92
17:12:06.470635 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 104
17:12:06.475532 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 84
17:12:06.497745 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 0
17:12:06.498153 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 0
17:12:06.498169 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 0
17:12:06.498194 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 120
17:12:06.548138 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:06.874953 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 1340
17:12:06.877901 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 1340
17:12:06.878218 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:06.878964 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 200
17:12:06.927022 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:06.929776 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 265
17:12:06.972890 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:09.003235 IP 10.10.0.87.59334 > 10.10.0.1.123: UDP, length 48
17:12:09.003425 IP 10.10.0.1.123 > 10.10.0.87.59334: UDP, length 48
17:12:09.040396 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 173
17:12:09.041774 IP 10.10.0.87.80 > 192.168.200.11.32908: tcp 157
17:12:09.041874 IP 192.168.200.11.32908 > 10.10.0.87.80: tcp 0
17:12:09.044743 IP 10.10.0.87.80 > 192.168.200.11.32908: tcp 168
17:12:09.044816 IP 192.168.200.11.32908 > 10.10.0.87.80: tcp 0
17:12:09.084102 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:12:09.086769 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 184
17:12:09.131042 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0


With WiFi Client
- @LAN
17:06:05.019226 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:05.068561 IP 10.10.0.87.80 > 192.168.101.132.38952: tcp 0
17:06:05.135382 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:05.135487 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:05.135955 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:05.136251 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:05.555316 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:05.555559 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:06.317906 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:06.318074 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:07.859536 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:07.859775 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:07.986736 IP 10.10.0.87.80 > 192.168.101.132.38952: tcp 0
17:06:08.104595 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:08.104837 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:11.060213 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:11.060353 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:11.352857 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 2
17:06:11.353343 IP 192.168.101.131.50630 > 10.10.0.87.80: tcp 6
17:06:11.413318 IP 10.10.0.87.80 > 192.168.101.131.50630: tcp 0
17:06:13.851219 IP 10.10.0.87.80 > 192.168.101.132.38952: tcp 0
17:06:13.943878 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:13.943989 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 0
17:06:17.199915 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435
17:06:17.200207 IP 192.168.101.132.38952 > 10.10.0.87.80: tcp 435

- @IoT :
17:15:31.580004 IP 192.168.101.132.42312 > 10.10.0.87.80: tcp 488
17:15:32.993001 IP 192.168.101.132.42312 > 10.10.0.87.80: tcp 488
17:15:33.261252 IP 10.10.0.87.80 > 192.168.101.132.42312: tcp 0
17:15:33.356714 IP 192.168.101.132.42312 > 10.10.0.87.80: tcp 0
17:15:33.375548 IP 192.168.101.132.42312 > 10.10.0.87.80: tcp 0
17:15:33.391697 IP 10.10.0.87.80 > 192.168.101.132.42312: tcp 0
17:15:33.889982 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 0
17:15:34.014755 IP 10.10.0.87.80 > 192.168.101.132.42326: tcp 0
17:15:34.072952 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:34.072971 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 0
17:15:34.671461 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:35.863174 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:36.696556 IP 10.10.0.87.80 > 192.168.101.132.42326: tcp 0
17:15:36.734112 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 0
17:15:37.266891 IP 10.10.0.87.80 > 192.168.101.132.40406: tcp 2
17:15:38.330585 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:38.390673 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 0
17:15:38.417997 IP 10.10.0.87.80 > 192.168.101.132.37160: tcp 0
17:15:38.423325 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 0
17:15:38.424124 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 488
17:15:38.652953 IP 10.10.0.87.80 > 192.168.101.132.40406: tcp 2
17:15:38.673930 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 488
17:15:39.195351 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 488
17:15:40.064342 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 2
17:15:40.064933 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 6
17:15:40.106145 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 0
17:15:40.182798 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 488
17:15:41.087019 IP 10.10.0.87.80 > 192.168.101.132.37160: tcp 0
17:15:41.139807 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 0
17:15:41.393311 IP 192.168.101.132.37160 > 10.10.0.87.80: tcp 0
17:15:41.481432 IP 10.10.0.87.80 > 192.168.101.132.37160: tcp 0
17:15:41.568243 IP 10.10.0.87.80 > 192.168.101.132.40406: tcp 2
17:15:42.568646 IP 10.10.0.87.80 > 192.168.101.132.42326: tcp 0
17:15:42.678680 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 0
17:15:43.190077 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:46.410128 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 0
17:15:46.498533 IP 10.10.0.87.80 > 192.168.101.132.37168: tcp 0
17:15:46.565732 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 0
17:15:46.566646 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 488
17:15:47.097014 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 488
17:15:47.138820 IP 10.10.0.87.80 > 10.10.00.11.32908: tcp 2
17:15:47.139311 IP 10.10.00.11.32908 > 10.10.0.87.80: tcp 6
17:15:47.192318 IP 10.10.0.87.80 > 10.10.00.11.32908: tcp 0
17:15:47.433805 IP 10.10.0.87.80 > 192.168.101.132.40406: tcp 2
17:15:48.121450 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 488
17:15:49.389670 IP 10.10.0.87.80 > 192.168.101.132.37168: tcp 0
17:15:49.399639 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 0
17:15:49.403986 IP 10.10.0.87.80 > 192.168.101.132.37168: tcp 0
17:15:49.405762 IP 192.168.101.132.37168 > 10.10.0.87.80: tcp 0
17:15:52.665532 IP 192.168.101.132.42326 > 10.10.0.87.80: tcp 494
17:15:54.411069 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 0
17:15:54.491877 IP 10.10.0.87.80 > 192.168.101.132.42662: tcp 0
17:15:54.559082 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 0
17:15:54.559168 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 488
17:15:55.059586 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 488
17:15:56.023723 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 488
17:15:57.207811 IP 10.10.0.87.80 > 192.168.101.132.42662: tcp 0
17:15:57.324641 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 0
17:15:57.399948 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 0
17:15:57.456107 IP 10.10.0.87.80 > 192.168.101.132.42662: tcp 0
17:15:57.946311 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 488
17:15:57.968260 IP 10.10.0.87.80 > 192.168.101.132.42662: tcp 0
17:15:57.968827 IP 10.10.0.87.80 > 192.168.101.132.42662: tcp 0
17:15:57.976672 IP 192.168.101.132.42662 > 10.10.0.87.80: tcp 0
17:15:58.082488 IP 10.10.0.87.80 > 192.168.101.131.50724: tcp 280
17:15:58.083596 IP 10.10.0.87.80 > 10.10.00.11.32908: tcp 264
17:15:58.123582 IP 10.10.00.11.32908 > 10.10.0.87.80: tcp 0
17:15:58.128625 IP 192.168.101.131.50724 > 10.10.0.87.80: tcp 0
17:15:59.165492 IP 10.10.0.87.80 > 192.168.101.132.40406: tcp 2

                        But! A new twist!

                        After many tests; NAT /Outbound :

                        * Interface : LAN 
* Source : LAN subnets
* Source Port : tcp/ *
* Destination : IOT subnets
* Destination Port : tcp/ 80 (HTTP)
* NAT Address : LAN address
* NAT Port : *
* Description : LAN to Port 80

                        => not OK

                        * Interface : IOT 
* Source : LAN subnets
* Source Port : tcp/ *
* Destination : IOT subnets
* Destination Port : tcp/ 80 (HTTP)
* NAT Address : IOT address
* NAT Port : *
* Description : LAN to Port 80

                        It works................ why? A mystery! (that I'd like to understand)

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

                          @ShiShiyoPomPom if you have a state already open.. The state is what allows traffic - they are evaluated first. If you then create a block rule for that take effect the state has to have timed out, or you have have deleted it. Once there is no state to all the traffic, rules will be evaluated if there is no rule to allow the state - then the traffic is never allowed.

                          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
                          • S
                            ShiShiyoPomPom
                            last edited by

                            Hum...
                            I'm not sure I've understood everything...

                            The rules are OK (wired PC > OK to reach WIFI IoT clients), WiFi PC > OK to reach IoT clients in the garage...)

                            On reboot or reset of “States”, the result is identical.

                            The more I look, the more I wonder (but I don't know enough about it) if the TEW-923DAP AP doesn't create SSID isolation by adding a "tag" or something, so my request gets tagged on leaving the AP, goes into the PFsense which authorizes it to go back to the AP (but on the other subnet), the AP sees the tag again and therefore blocks the request (hence only TCP is impacted and not ICMP).

                            By adding NAT, the request is relayed, which removes this “tag” and so it goes through.

                            Does this sound like a possible theory?

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

                              @ShiShiyoPomPom ok I miss read your issue..

                              But this doesn't seem correct

                              And I have a bridge: bridge0 = opt2 + opt3

                              ETH_IOT (opt2) -> igc3 ->
                              VLAN_IOT (opt3) -> igc1. 10 ->

                              Your bridging 2 different networks. One with a tag and one without?

                              From your drawing makes no sense that you would have a bridge.

                              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
                              • S
                                ShiShiyoPomPom
                                last edited by

                                You're right, the second interface of the bridge is not shown on the drawing

                                It's the igc3 (ethernet port n°4 of the pfSense) on which is connected a PowerLine that leads to another PA (PowerLine with WiFi) in the garage.

                                @ShiShiyoPomPom said in LAN without subnet access only on WiFi:

                                And I have a bridge: bridge0 = opt2 + opt3

                                On “ETH_IOT (opt2) -> igc3” I have a PowerLine for Shelly in my garage (by the way, their web page display works from a WiFi SSID client LAN...... )

                                So it seems that only the TCP “WiFi LAN > WiFi IoT” is a problem...

                                Here's the updated drawing:
                                Diagramme sans nom-Page-5.drawio.png

                                Bridge = PLC on port 3 + data with VLAN10 tag (tagged by TEW-923DAP) arriving on port 1

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

                                  Hmm, hard to see why that outbound NAT rule would do anything given that the subnets in play are the same in both cases.

                                  I would download those pcaps and look at them in wireshark to see what happening. I note in the failing case there are no large packets sent so you could have some MTU issue. And that might line up with the fact you can access things on the wired side on the bridge but not the wifi side? And the wifi side is using the VLAN.

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    ShiShiyoPomPom
                                    last edited by

                                    I was thinking of the MTU, too

                                    WireGuard is more stable/reliable with an MTU of 1420, so it's configured that way. And to have "everywhere the same" (I don't know if it's useful, but at least "it's everywhere the same") all my interfaces are configured with this same MTU value.

                                    I tried configuring the LAN with the default MTU, then the IoT... Then both, same result.

                                    I opened a ticket with Trendnet to get their opinion on my isolation hypothesis...

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

                                      Try setting a low mss value on the bridge and see if it makes any difference. Something that will definitely pass like 1300.

                                      1 Reply Last reply Reply Quote 0
                                      • S
                                        ShiShiyoPomPom
                                        last edited by

                                        OK thanks

                                        I'm trying this weekend

                                        Currently, the MSS is 1380 (according to the MTU - 40 recommendation displayed in pfSense).

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          ShiShiyoPomPom
                                          last edited by

                                          Hi !!!

                                          Bad news;
                                          I've tried many MTUs and MSSs (1342, 1280, 1500, etc.): not OK.... 😭

                                          I liked the idea because while searching I found problems accessing some sites with too high MTU (8 bits story, MTU to 1508 not accepted on some cards etc...)...

                                          Reduce the MTU to skip the TEW-923DAP "trace"...

                                          But it doesn't work.... T_T

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

                                            Then I would still be looking at the actual packet captures in Wireshark to see what's not passing (or being sent).

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