LAN without subnet access only on WiFi
-
@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.
-
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?
-
@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.
-
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:
Bridge = PLC on port 3 + data with VLAN10 tag (tagged by TEW-923DAP) arriving on port 1
-
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.
-
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...
-
Try setting a low mss value on the bridge and see if it makes any difference. Something that will definitely pass like 1300.
-
OK thanks
I'm trying this weekend
Currently, the MSS is 1380 (according to the MTU - 40 recommendation displayed in pfSense).
-
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
-
Then I would still be looking at the actual packet captures in Wireshark to see what's not passing (or being sent).
