OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: green1 on June 26, 2020, 04:56:46 am
-
I have a new opnsense (20.1.7) setup, and am having some odd issues with the firewall default deny rules.
I have a LAN 10.42.0.1/22 an OpenVPN client 10.42.42.2/24
I am connected to the router using OpenVPN coming from 10.42.42.18 going to the router address of 10.42.0.1
In the firewall rules for the LAN and OpenVPN interfaces I have inbound rules for both IPv4 and IPv6 set to allow everything from anywhere to anywhere.
I'm able to access the router's web interface just fine, but I see the firewall log shows all sorts of lines like this:
VPN Jun 25 20:51:48 10.42.42.18:42062 10.42.0.1:443 tcp Default deny rule
So a few questions here: first, if it's denying it, why can I still access the interface? second, if I have the rules set to allow, why am I seeing the deny rule in the logs? and does this have anything to do with the somewhat inconsistent performance of the web ui in that it seems to freeze regularly for short intervals?
-
I took another look, and the mystery deepens. See this snippet from the firewall logs:
VPN Jun 26 11:05:26 10.42.42.18:45050 10.42.0.1:443 tcp Default deny rule
VPN Jun 26 11:05:24 10.42.42.18:45216 10.42.0.1:443 tcp Line one is red and was blocked, Line 2 is green and was passed. What's the difference?
-
Maybe this thread will answer your question:
https://forum.opnsense.org/index.php?topic=17481.msg79642#msg79642
-
Apologies for being frank: this question is raised every week and the forum and Twitter are full of the same answer.
When your state tracking fails, the pass rule will drop your connection and the default deny rule will take over. There are many reasons for this. The quickest fix is to disable state tracking in the advanced settings of the pass rule that is supposed to carry the traffic over the edge. :)
Cheers,
Franco
-
Maybe this thread will answer your question:
https://forum.opnsense.org/index.php?topic=17481.msg79642#msg79642
That thread appears to have the same problem as I do, however no solutions are mentioned anywhere in it. There is a reference to a "why you might see harmless entries like this", however there's no indication of how to tell if they are harmless vs a real problem (and as I stated in my initial post, I appear to be having real problems as the interface frequently lags/locks up when connected through this connection, I don't know if it's related to those log entries, but it's the best guess I have to go on)
Apologies for being frank: this question is raised every week and the forum and Twitter are full of the same answer.
No offence, but I agree the question is raised frequently as I found MANY people having the same issue. I however disagree that the forum or twitter are full of any answers as I spent a lot of time searching and reading before posting here. There are lots of people telling others to search for the answer. There are lots of people pointing at threads that don't contain answers, but there don't seem to be a lot of answers.
When your state tracking fails, the pass rule will drop your connection and the default deny rule will take over. There are many reasons for this. The quickest fix is to disable state tracking in the advanced settings of the pass rule that is supposed to carry the traffic over the edge. :)
This is at least part of an answer, but it leaves a lot more questions: If state tracking is failing in a way that impacts valid traffic (e.g. causing me to have to reload the webpage, experiencing lags and lockups when browsing, etc) shouldn't I be doing more than just ignoring it, or disabling state tracking? surely state tracking is there for a reason, and we shouldn't have to disable it.
-
When capturing traffic in these case you will often see tcp retransmissions and/or excessive resets , pointing to other issues in your network (like mtu sizing issues).
From the firewalls perspective it's indeed as simple as Franco commented, if the return packet has no matching state, it will be dropped, in all cases I've witnessed so far, it did so for very valid reasons (broken switches, devices ignoring pmtu, network congestion, etc, etc).
When you need to find out the reasons, you have to start digging into the details by capturing traffic (and compare the results with how the tcp flow should react). This, unfortunately, can be time consuming.
Best regards,
Ad