OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: Nico on August 21, 2018, 09:45:32 am
-
Hello everybody,
my issue is not specific to 18.7 since we were on the previous major release until a maintenance upgrade tonight and the behaviour did not change. Here is a quick overview of the setup:
- 3 Vlans: 200, 300 and 400
- each with it's distinct /24 IP network: 10.0.102.0/24, 10.0.103.0/24, 10.0.104.0/24 with the .1 as the gateway and CARP for HA
- each vlan interface has a rule that permits IPv4 CARP
- each vlan interface has a rule that permits it's own source (had this set to automatically generated vlan200 net and address first which did not work either; btw: what is the difference between net and address? Didn't find any doc about that)
This should result in dropping all traffic from different sources but it's not but a test rule containing a specific pair we used to test did actually work. Instead the logging shows messages such as "icmp let out anything from firewall host itself" which seems to be an implicit rule I cannot find anywhere.
Questions are now:
- why isn't it working?
- where can I set / see the direction of rules generally? The rules page shows the direction arrows but I've literally never seen an arrow displayed there for the rules and cannot seem to find the option in the "edit rule" to limit it to either in our out
Please let me know if further input is required.
Thanks!
-
Without seeing the rules you've configured, it's pretty tough.
Each fire rules tab should have the rules for the traffic and the subnets you want. If you turn on logging for the rules, you can see them in the logs.
Let's say my interface for my LAN is 192.168.1.1 and the network is 192.168.1.0/24
The LAN Net is 192.168.1.0/24
The LAN Address is 192.168.1.1
-
Hi,
thanks for the reply. The rules are actually very basic. A screenshot from Vlan200 is here but vlan 300 and 400 are identically with their individual source subnets.
(https://img2.picload.org/image/dllplcoa/screenshot_1.png)
It is my understanding, that this should block all traffic originating from other subnets. I did actually add a logging but even as the first rule, I only see matches with the previously mentioned let out anything from firewall host itself comment.
-
Depending on how you have you logging setup, you'll see traffic go out via the first rule logged and also the " let out anything from firewall host itself" as the firewall is going to nat or port forward or pass the traffic through.
What's the goal for the 3 VLANs ? Are you trying to have them talk to each other or keep them separate?
What's the goal of that first rule?
What are you trying to do actually do that's not working?
-
Hi,
we have an outbound NAT configured as follows:
(https://img3.picload.org/image/dllplwii/nat.png)
But since the destination is reachable via internal routing it shouldn't be used, right?
These 3 Vlans are different internal services that must not communicate with each other. All 3 Vlans have outbound NAT for access to the internet and unless specifically configured otherwise, there is no communication between vlans desired.
The first rule makes sure (but it might not be required) both firewalls can talk to each other. It was actually initially configured by a colleague so I am not sure if the OPNsense did that by itself after configuring CARP or he did it manually by himself. But since it is set to match the CARP protocol only, it shouldn't affect the regular client traffic in my eyes.
What actually is not working is that the Vlans can communicate with each other although there should by - at least it is my understanding - a default deny policy in place and since we never specifically allow the source address from any of the other vlans, it shouldn't pass the firewall.
-
Yeah, I think the CARP item would correct. I would just turn on logging to make sure nothing else is hitting it as you expect.
Outbound NAT would not factor as you are going outbound and it's all internal traffic.
Are you sure it's going through the firewall at all? Is something else passing the traffic perhaps if you aren't seeing it? Is all the VLAN configuration just on the router?
I would turn on logging on all the rules so you can figure out what's capturing it and passing it through.
-
OK I enabled logging for all those rules and we will test again. It might be worth a try to disable outbound NAT completely since you mentioned this "anything from the firewall host itself" message was originating from NAT.
-
So in my example, my HomeVPN is on my OPNSense box so the firewall itself will log a rule as well as my HomeVPN interface if I ping from my HomeVPN to my LAN:
(https://i.imgur.com/uI2EHNdh.png)
If I block that rule it never makes it out:
(https://i.imgur.com/LEB1RyBh.png)
Rules:
(https://i.imgur.com/ZEQDn6jh.png)
-
Hi,
you have a specific discard rule installed but it is my understanding, that the default policy is a reject and therefore unless specifically allowed, this should be blocked without this specific reject rule anyways. It seems that - at least for traffic routed between interface (so hopefully no WAN) - a permit on egress is sufficient and another permit on ingress of the destination interface is not required. If that's the case it's at least odd behaviour and makes configuring rules a bit more complex. Maybe someone can confirm or correct me at this point?
Thanks!
-
To be more specific: "first match wins" seems to work globally and not on a per-interface basis. Can anybody confirm this?
-
The issue was meanwhile solved and some misunderstandings (as it seems) could be cleared.
- A specific "permit" rule on egress is not required so this is a useless match
- Floating rules are always considered first. Reading the documentation I thought it would be "Floating first match > Interface > Floating last match" but it is actually "Floating first match > Floating last match > Interface" which makes the first/last match feature kind of useless in my eyes.
- We removed the specific permit on egress rule and afterwards the ingress rules were processed correctly. I guess there is some implicit "permit" for connected interface IPs that may or may not be disabled somewhere in the settings but it doesn't disturb so we won't touch this.
To sum it up: we learned some important details for the future.
-
So I'm following, you had a floating rule that was allowing the traffic and you removed that floating rule?
-
No, not at all. I had a "permit anything from the vlan egress" rule which matched of course for any traffic between the vlans and I was unable to deny that. Also an additional "deny from source != vlan net" rule doesn't work either.
-
Ah ok. Thanks. That is clear now.
-
I wanted to provide an update to this since the behaviour seems not to be well-documented. Apparently the device takes connection tracking into account which means, that if a connection matches an outbound rule (so egress for a vlan for example) and the reply matches the same connection, the ingress rule will not be taken into account. This makes creating rules for solely firewall local traffic a bit more complex since you cannot rely on a simply deny rule on ingress anymore.