Going to need more details to help out with this but just a couple of comments so far. Your specific rules will be easier to manage if you create them for each interface rather than as floating rules. Also, there is no need to mention "ping self" because traffic that stays on the same subnet will always be allowed because it doesn't even pass through the firewall for evaluation. Here are my general suggestions:I see that you have an alias for RFC1918 ranges. On each VLAN that needs internet access, create a rule that allows all access the the inverse (NOT) RFC1918. That will provide internet (WAN) access but no inter-VLAN communication. Next, on any VLAN that needs to access another VLAN, create specific allow rules that go before the internet rule.That should pretty much get you started. Remember, any traffic not explicitly allowed will be blocked by default. Therefore, try to think in terms of creating allow rules that are only as permissive as necessary rather than trying to put block rules everywhere. Hope that helps.
I allrady creat it, in screenshot first post. and thid rulse dont work.
Quote from: deathnote on March 11, 2022, 07:40:55 amI allrady creat it, in screenshot first post. and thid rulse dont work.I saw your screenshot but my comment still stands. Do away with the floating rules and create rules on each interface for your VLANs as I suggested and you'll have better success in managing your traffic.
Not sure I understand why you are "turning off the interface" or what that even means. Also, if you are enabling and disabling rules, are you clearing the firewall states between testing? It's still not very clear what you are trying to achieve for each of your VLANs. If you create a list of your VLANs and guidelines for each, we can easily come up with working rules for each interface. For example, something like:VLAN1: Internet access but no access to other VLANsVLAN2: Internet access and access to VLAN1 but not VLAN2VLAN3: No internet access, access to server on VLAN1 only
OPNsense is a stateful firewall. A TCP connection but also a continuous stream of UDP or ICMP packets establish a flow. If the initiation of the flow is permitted, the flow continues to be permitted. For UDP and ICMP this is implemented via timeouts, since there is no proper tear down of the connection or other means (SYN cookie, sequence number) to properly identify a connection.
In the UI navigate to Firewall > States > Actions and click on "Reset state table".Caveat: in a live production environment this will kill all active connections, e.g. long running downloads.