OPNsense Forum
English Forums => 23.7 Legacy Series => Topic started by: jahlives on January 04, 2024, 04:49:01 pm
-
Hello and happy new year
I have a weird issue with opnsense 23.7.11 after upgrading from 23.7.7. Although the issue was already present in my new installation of 23.7.7
The issue is: that ALL traffic to the firewall is cut off as soon as the rules are active. Only doing pfctl -d get's me access again. I have an allow any on my LAN interface but it seems that the traffic is shutdown earlier by an auto-generated rule. Namely the one that triggers on port 0 access. Checking the firewall log on local console shows me
(https://i.postimg.cc/ry5FJSV3/IMG-20240104-162742-HDR.jpg) (https://postimg.cc/nMcJV9QG)
that rule 8 seems to have hit "rule 8/0(match)" and if I check the autogenerated rules number 8 is the port 0 rule
(https://i.postimg.cc/s1yNskbF/Screenshot-20240104-162152.png) (https://postimg.cc/s1yNskbF)
is there any way how I can disable this particular rule? Did not find an option in GUI. Furthermore the question is this a bug or an issue on my side? Although I could not imagine a widespread bug as then the forum would be full of such issues ;)
Any hint is highly appreciated
Have a good one
tobi
p.s. seems the embedded screenshots do somehow not work. Need to click on the pic and then after getting to postimg.cc click again to get the pictures in readable :)
-
On the CLI:
pfctl -s rules -vv | more
Will show you the rule numbers.
Hunch is, that you've got a weird setup - in most cases, the firewall probably shouldn't be seeing:
192.168.0.12 -> 192.168.0.242
... as it should route at layer 2, i.e not to the firewall. Assuming that .242 is NOT the firewall itself? Obviously not impossible, but it would just be a weird gateway choice if so. :)
For me, using the pfctl command above, rule 8 is an 'antispoof' rule:
@8 block drop in log on ! ixl1 inet from 10.x.x.0/24 to any
[ Evaluations: 656632 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 33106 State Creations: 0 ]
"Block, drop, log 10.x.x.0/24 traffic, that is NOT on interface ixl1 (which is where it should be)"
Your netmasks are probably wrong, or you've got the same subnet on multiple interfaces, etc... something like that, at a guess.
Would need to see more information such as interface lists, IPs assigned, netmasks, routes, etc.
-
Hi
> Assuming that .242 is NOT the firewall itself?
wrong ;) That is my firewall's ip on LAN interface and the .12 is my client from which I try to access
Thanks for your hint with the pfctl -s that shows me that my assumption was wrong. It seems to be this rule
root@home-opnsense:~ # pfctl -s rules -vv | grep -A 2 ^@8\ block
No ALTQ support in kernel
ALTQ related functions disabled
@8 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
[ Evaluations: 160 Packets: 24 Bytes: 1872 States: 0 ]
[ Inserted: uid 0 pid 55655 State Creations: 0 ]
no idea what this rules does it's not one of mines :-)
My list of interfaces is quite long. As I plan to use this opnsense box as replacment for my pfsense Router at home. So I prepared all the necessary interfaces already (vlan and bridges). But the interface that I use to configure the box atm is the LAN which looks as follows (no vlan or bridge on that)
igb1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN (opt17)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
ether 20:7c:14:f0:8b:68
inet 192.168.0.242 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
it's about 29 interfaces we're talking about. I can send you the whole ifconfig output if you like but as said currently only LAN interface is in use.
Routing table is quite small
root@home-opnsense:~ # netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.0.1 UGS igb1
10.66.100.0/25 link#28 U bridge3
10.66.100.1 link#28 UHS lo0
127.0.0.1 link#10 UH lo0
172.20.66.0/24 link#26 U bridge1
172.20.66.1 link#26 UHS lo0
172.31.254.0/29 link#29 U bridge0
172.31.254.1 link#29 UHS lo0
192.168.0.0/24 link#2 U igb1
192.168.0.242 link#2 UHS lo0
Internet6:
Destination Gateway Flags Netif Expire
::1 link#10 UHS lo0
fe80::%lo0/64 link#10 U lo0
fe80::1%lo0 link#10 UHS lo0
Thanks a lot for you help and let me know if you need further details
Now out for dogwalk
Cheers
tobi
-
> no idea what this rules does it's not one of mines :-)
Default drop rule, for traffic not explicitly permitted elsewhere in the ruleset.
On your LAN rules, under Automatically Generated, there should be an anti-lockout rule that permits access from LAN -> firewall over 22/443. For example, my LAN is ixl1:
pass in log quick on ixl1 proto tcp from any to (self) port = ssh flags S/SA keep state label "8fca0220658675898f50f640b033aa0e"
pass in log quick on ixl1 proto tcp from any to (self) port = https flags S/SA keep state label "8fca0220658675898f50f640b033aa0e"
If it's not present:
Firewall -> Settings -> Advanced, did you enable (i.e tick in the box) "Disable administration anti-lockout rule"?
...if so, the above rules won't be present.
Or, maybe, the pf macro for (self) is not matching your 192.168.0.242 if the anti-lockout rules are present.
.. either way, it seems to be getting caught by the default drop rule. So something isn't matching an allow rule.
-
Good Morning
Or, maybe, the pf macro for (self) is not matching your 192.168.0.242 if the anti-lockout rules are present.
.. either way, it seems to be getting caught by the default drop rule. So something isn't matching an allow rule.
actually I disabled it as I added two rules on LAN as the following (allow IPv4 any/any)
(https://i.postimg.cc/FYrmwpJy/Screenshot-20240105-080042.png) (https://postimg.cc/FYrmwpJy)
but I still get blocked by the default rule. How comes that such a any/any rule does not match??
One thing I changed in settings is that I enabled filtering on bridges and disabled it on bridge members
net.link.bridge.pfil_bridge 1
net.link.bridge.pfil_member 0
but as said LAN (igb1) is not member of any bridge. Is it possible that these settings disable filtering on ANY interface? Regardless if it's a member of a bridge or not?
-
just out of curiosity I added the allow any/any IPv4 rule to floating. And tada I can still access if pfctl -e
So for whatever reason the rules on LAN are not evaluated/applied. Any idea what could be the reason for ignoring the rules on LAN. LAN interface is definitely the right one: the one that the traffic comes in (igb1). Can I somehow check with pfctl that the rules shown under LAN in GUI are really bound to the right interface? Even if I configure that floating rule explicitly to LAN interface the access still works
-
Sure... read the ruleset with pfctl :)
Chances are, there is a mistake in the rule(s) you added - wrong direction, something, that is not shown in your screenshots but IS in the editing/applying of the rule.
... or did you disable Quick, i.e ' Apply the action immediately on match.' on your LAN allow rule?
Given that you intend to have an allow rule, I'm not really sure why you disabled the anti-lockout rules? Seems a lot of effort, for something that probably wouldn't exist otherwise?
-
direction seem to be correct and also quick is set according to pfctl
pass in quick on igb1 reply-to (igb1 192.168.0.1) inet all flags S/SA keep state label "d038f19d181257facbfb9dfd06f5ba32"
pass out quick on igb1 reply-to (igb1 192.168.0.1) inet all flags S/SA keep state label "c38c9c05eb93a192eb2580dde7a38c15"
-
Please provide a full ifconfig and full ruleset dump.
This doesn't look right:
reply-to (igb1 192.168.0.1)
-
On your LAN allow rule:
- Advanced Features
- reply-to
.. has seemingly been set.
A 'default' allow rule:
@217 pass in quick on ixl3 inet all flags S/SA keep state label "b7207e5ecd2fac4209c4554aeaea5e21"
EDIT: And unless you've done something funky, generally, you don't need the out rule - traffic is filtered inbound to an interface, i.e this is where the state entry is created, and then is allowed out by default.
-
This doesn't look right:
stumpled also over it after sending my previous post. That reply-to target is my current router and not the opnsense. So I set "Disable reply-to on WAN rules" and tada the access works. Just wonder why the default (did not change that setting before) sets a "wrong" reply-to address. Also why this WAN setting is applied to LAN rules?
But anyway it works now and I can go on with the config migration from pfsense to opnsense.
Thanks a lot for your help and have a good one
tobi
-
> So I set "Disable reply-to on WAN rules"
But igb1 isn't/wasn't your WAN interface?
... something isn't right.
My 2 cents: I think there has been too much fiddling of the defaults, before getting a basic setup right :)
EDIT: Wait, so you have 192.168.0.0/24 on igb1 (192.168.0.242), then also 192.168.0.1 on another box (your current router, pfsense?) potentially on another interface? Or is that LAN side on igb1 as well?
-
But igb1 isn't/wasn't your WAN interface?
true but I believe ;) that disable that WAN setting also unset the "default" macro that the LAN rule used under advanced/reply-to. I enabled the WAN reply-to setting again and explicitly set the reply-to in the LAN rule to "disabled". Still works :-)
My guess is that this default setting works fine if opnsense really is the default gateway for the subnet. But as currently my opnsense is not the gateway and uses a default route to reach the outside it sets the default GW address to the IP of the default and uses that in reply-to. So I bet I can change back the LAN rules to reply-to default as soon as my opnsese replaced the pfsense and acts as default gateway
Again thank you a lot
Cheers
tobi
-
No worries :)
That would make sense if the default gateway points out of the igb1/LAN-but-is-actually-WAN-from-the-routing-table …. Which I missed in the original netstat :)