OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: IsaacFL on June 06, 2023, 10:21:43 pm
-
When I moved from the other "sense", I used to block bogons with no impact, but always seem to have problems with opnsense. I kind of gave up blocking bogons, but was debugging today, and I see in the log:
50IOT 2023-06-06T12:55:41-07:00 0.0.0.0:68 255.255.255.255:67 udp Block bogon IPv4 networks from 50IOT
50IOT 2023-06-06T12:55:40-07:00 0.0.0.0:68 255.255.255.255:67 udp Block bogon IPv4 networks from 50IOT
When I look in the auto rules I see that indeed the DHCP rules fall after the block private and block bogon rules. Interestingly on the WAN, the DHCP rules are before all of the other interfaces have the block bogons before the allow DHCP rule.
I think that block bogons and block private should be the last of the automatically generated rules.
I also note that the bogonsv6 does not exclude the private ULA addresses, whereas the bogonsv4 does. So they are not consistant. Bogonsv6 alias has an entry for 8000::/1 which is inclusive of the fc00::/7 ULA subnet. It would be nice if blocking bogons does not preclude using ULAs.
-
Which version are you using? The priority was changed for the DHCPv4 rules in 23.1.6 and my ruleset here looks correct (DHCP in Prio 1 and Bogons in Prio 5)
Cheers,
Franco
-
It is latest version. I was release notes and testing.
OPNsense 23.1.9-amd64
FreeBSD 13.1-RELEASE-p7
OpenSSL 1.1.1t 7 Feb 2023
It is easy to see if you look at the \tmp\rules.debug file.
The DHCP for WAN was moved up. But all of the other vlans dhcp is still after.
Here are snippets of mine.
block in quick proto tcp from {<sshlockout>} to {(self)} port {22} label "a13bd48dc2f2885e10a66983a2b4d19d" # sshlockout
block in quick proto tcp from {<sshlockout>} to {(self)} port {443} label "fc2d22120a5d07f6ffc1df176ba5fdd8" # sshlockout
block in quick from {<virusprot>} to {any} label "74301983dfeb857eca47f255983e768a" # virusprot overload table
pass in quick on ix0 proto udp from {fe80::/10} port {546} to {fe80::/10} port {546} label "8cd6199018ef9eb8a56a803f76d043ba" # allow dhcpv6 client in 0WAN
pass in quick on ix0 proto udp from {any} port {547} to {any} port {546} label "223a20aafe5da09a3dd93ec49dd4a20b" # allow dhcpv6 client in 0WAN
pass out quick on ix0 proto udp from {any} port {546} to {any} port {547} label "a9b9f166e202739c50d110f23a967b30" # allow dhcpv6 client in 0WAN
pass in quick on ix0 proto udp from {any} port {67} to {any} port {68} label "11e1835f5f8e7ae3832c087ccb3ed724" # allow DHCP client on 0WAN
pass out quick on ix0 proto udp from {any} port {68} to {any} port {67} label "5751b57c4f1822948ab5a9f3e22bd8ad" # allow DHCP client on 0WAN
pass in quick on em0 inet6 proto udp from {fe80::/10} to {fe80::/10,ff02::/16} port {546} label "e8739697dc6c79ab7fd306255d59389a" # allow access to DHCPv6 server on 10LAN
pass in quick on em0 inet6 proto udp from {fe80::/10} to {ff02::/16} port {547} label "5c917d580d40669defaf32fc03bfa6a8" # allow access to DHCPv6 server on 10LAN
pass in quick on em0 inet6 proto udp from {ff02::/16} to {fe80::/10} port {547} label "255d1ec72e46d222388fc2200373cdc6" # allow access to DHCPv6 server on 10LAN
pass in quick on em0 inet6 proto udp from {fe80::/10} to {(self)} port {546} label "ace4bc578b264bf701f9fa342defb098" # allow access to DHCPv6 server on 10LAN
pass out quick on em0 inet6 proto udp from {(self)} port {547} to {fe80::/10} label "9327f8564428628b4ab621fed67850dc" # allow access to DHCPv6 server on 10LAN
pass in quick on vlan01 inet6 proto udp from {fe80::/10} to {fe80::/10,ff02::/16} port {546} label "2fb22015862be95d6539658e0916bc5f" # allow access to DHCPv6 server on 20WKS
pass in quick on vlan01 inet6 proto udp from {fe80::/10} to {ff02::/16} port {547} label "f9a56755581d6f7d390147c00c140efb" # allow access to DHCPv6 server on 20WKS
pass in quick on vlan01 inet6 proto udp from {ff02::/16} to {fe80::/10} port {547} label "6b90c7032193d3e57463a2347ac3ff8f" # allow access to DHCPv6 server on 20WKS
pass in quick on vlan01 inet6 proto udp from {fe80::/10} to {(self)} port {546} label "3842aa87d5e954a3b458e62f5c67bfeb" # allow access to DHCPv6 server on 20WKS
pass out quick on vlan01 inet6 proto udp from {(self)} port {547} to {fe80::/10} label "f467dcffa5e62a1556860f203c13ef28" # allow access to DHCPv6 server on 20WKS
See the rule for allow DHCP client on 0WAN. This continues with all of the DHCPv6
Then the section where all of the private and bogons get blocked (I had to revert to not blocking):
# [prio: 5]
block in log quick on ix0 inet from {<bogons>} to {any} label "9feb1ff22602ce7fa249ca38a748a8d6" # Block bogon IPv4 networks from 0WAN
block in log quick on ix0 inet6 from {<bogonsv6>} to {any} label "730b04035be750d29de5c32523480cf5" # Block bogon IPv6 networks from 0WAN
block in log quick on ix0 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "ef5f5d3adad0ef34d40d4a7e2bcf7555" # Block private networks from 0WAN
block in log quick on ix0 inet6 from {fc00::/7} to {any} label "bf7cbeeb098c49140d6b541473452bef" # Block private networks from 0WAN
# block in log quick on em0 inet from {<bogons>} to {any} label "bd499fb1bef5e57ad46cef500e94f021" # Block bogon IPv4 networks from 10LAN
# block in log quick on em0 inet6 from {<bogonsv6>} to {any} label "d37827d6f035d3698f37dd6aabb75137" # Block bogon IPv6 networks from 10LAN
# block in log quick on em0 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "79727f2e242690dfb030f966ae503cca" # Block private networks from 10LAN
# block in log quick on em0 inet6 from {fc00::/7} to {any} label "0852c8b1d565cbd23ec0572d6604c756" # Block private networks from 10LAN
# block in log quick on vlan01 inet from {<bogons>} to {any} label "d9ef560ede9c083edc377939b63fafa5" # Block bogon IPv4 networks from 20WKS
# block in log quick on vlan01 inet6 from {<bogonsv6>} to {any} label "9d511ebb2fa6e6833371d6da3ad5c1c7" # Block bogon IPv6 networks from 20WKS
# block in log quick on vlan01 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "a2908bb216855e9bd0984811c8cb5c4e" # Block private networks from 20WKS
# block in log quick on vlan01 inet6 from {fc00::/7} to {any} label "aadbaed51857e9273da06101321d119e" # Block private networks from 20WKS
.........
Then after all of that then DHCP for all other vlans start: em0 is lan
# block in log quick on ix1 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "1dcbcdddb381d47a0c2269720b841b81" # Block private networks from OPT1
# block in log quick on ix1 inet6 from {fc00::/7} to {any} label "4478089a2788fb64acf553b5efb6131b" # Block private networks from OPT1
# block in log quick on openvpn inet from {<bogons>} to {any} label "5b27aa5e5d332d9e350ac2b095eb0104" # Block bogon IPv4 networks from OpenVPN
# block in log quick on openvpn inet6 from {<bogonsv6>} to {any} label "ea177ebe00d466ee5c232dab70749518" # Block bogon IPv6 networks from OpenVPN
# block in log quick on openvpn inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "3a9b23e39e6df8b8359d9e47fe8daec1" # Block private networks from OpenVPN
# block in log quick on openvpn inet6 from {fc00::/7} to {any} label "4d468be62333d1d91b2413697bbce660" # Block private networks from OpenVPN
pass in quick on em0 proto udp from {any} port {68} to {255.255.255.255} port {67} label "90054c3d7cca21cfec8ee12c1b0c74d1" # allow access to DHCP server
pass in quick on em0 proto udp from {any} port {68} to {(self)} port {67} label "5fcc539c669a0e0a476e19bcde5b03fd" # allow access to DHCP server
pass out quick on em0 proto udp from {(self)} port {67} to {any} port {68} label "cfe897788580cd054702c483bb47890f" # allow access to DHCP server
pass in quick on vlan01 proto udp from {any} port {68} to {255.255.255.255} port {67} label "fdd28dc9305e362e4512c0f1e1715746" # allow access to DHCP server
pass in quick on vlan01 proto udp from {any} port {68} to {(self)} port {67} label "4917b3d5427938f2b292c527ad5b6dfa" # allow access to DHCP server
pass out quick on vlan01 proto udp from {(self)} port {67} to {any} port {68} label "f8f4a8819bd03fde293b00c80319644e" # allow access to DHCP server
pass in quick on vlan02 proto udp from {any} port {68} to {255.255.255.255} port {67} label "7a4bc76014310d96b161abe7b1672f4c" # allow access to DHCP server
pass in quick on vlan02 proto udp from {any} port {68} to {(self)} port {67} label "c843c49db83786e6e5a7f7a404a42b96" # allow access to DHCP server
pass out quick on vlan02 proto udp from {(self)} port {67} to {any} port {68} label "e1d80d9bcab29cae8a1a7c5081e89887" # allow access to DHCP server
-
So it looks like that DHCP for WAN was moved to prio:1 But all of the other vlans DHCP is still in prio:5
This is for regular ipv4 DHCP.
The DHCPv6 are all vlans are in prio:1
-
Ok we talk about blocking bogons on LAN interfaces... I'm not sure, how many people are using it? Does it make sense? I think we never had that in our defaults.
Cheers,
Franco
-
Ok we talk about blocking bogons on LAN interfaces... I'm not sure, how many people are using it? Does it make sense? I think we never had that in our defaults.
Cheers,
Franco
...and most likely never will, for good reasons?
-
It is a valid question.
You can achieve the same results by always making sure to use pass rules with only "LAN net" as the source. Then default deny will catch most of the bogons. However, the default rule, is "any" as source, and many people still use "any" as source address.
The whole purpose of the bogons list is to not route packets with these source addresses out the WAN interface and the easiest way to achieve that is to block them at the LAN before they routed out.
Regardless if you choose not to use it, I think for consistancy, all of the DCHP rules should be grouped together in prio 1, and the block private and block bogons should be the last group.
I can say that with "sense that shall not be named" you can block bogons on all interfaces and it does not break services. And if you turn on logging you will see some get blocked occasionally. So these packets could get routed out the default route. Mostly it is "0.0.0.0" , "::" , and "169.254.x.x" addresses as source that I have seen.
Now another issue is that opnsense includes the ipv6 private address in the bogonsv6 list. You should have the option to not block private, but block bogons on ipv6 too, just like you can on ipv4.
So if blocking bogons was properly implemented in opnsense, then it is definitely considered to be best practice. But is broke, so :(
-
Ok we talk about blocking bogons on LAN interfaces... I'm not sure, how many people are using it? Does it make sense? I think we never had that in our defaults.
Cheers,
Franco
...and most likely never will, for good reasons?
If it was implemented correctly, what good reason would you pass them?
-
My concern is that I don't want anything leaving my WAN interface to the internet with a bogon address as a source address. So I was thinking I would try to block them as a source address at the LAN interfaces. But that breaks too many things.
A better choice would be that I have a rule on my WAN interface to block bogons as source address, both in and out of the WAN interface. But you want to make sure that firewall itself was not blocked because at least for ipv6 things like fe80:: subnet and :: needs to be allowed onto the WAN interface from the router as source for interface negotiation.
I think the bogons list really is intended to be used as a null route on the routers, but that would be pretty big.
-
@IsaacFL: maybe this blackhole idea is something you can use? see:
https://forum.opnsense.org/index.php?topic=34190.msg166114 (https://forum.opnsense.org/index.php?topic=34190.msg166114)
-
Yeah, that takes care of the case for the destination address shenanigans and I have done what that thread does.
I guess there are DDOS type shenanigans where a device will use create a source address from bogon list and send it out the default gateway. Supposedly if your router lets it out of your network, and your upstream router doesn't block it, then it is untraceable to where it comes from. So best practice is to prevent bogons as a source address both in or out of your WAN interface. I think I am ok, since I only pass rules with "LAN net" as a source address in each interface. So it should get caught by default deny.
But that is the reason why some people would want to use "Block Bogons" on LAN interfaces. Where I used to work, we also blocked bogons and private addresses at the layer 3 switches, since we only used public IPs (I had 8 /24 subnets just for my lab, lol).
I am retired now, so this all for homelab trying to implement what I used to do.
-
Automatically generated necessary allow rules should go first regardless of the interface.
@IsaacFL would you please open an issue on Github?
-
Automatically generated necessary allow rules should go first regardless of the interface.
@IsaacFL would you please open an issue on Github?
I agree about that. I can open a Github issue. Probably tomorrow, as I'm running around today.
-
Automatically generated necessary allow rules should go first regardless of the interface.
@IsaacFL would you please open an issue on Github?
I actually reported this back in 2020 with Issue #4158, but it was closed because I found a work around.
-
I reopened https://github.com/opnsense/core/issues/4158 for internal discussion. We can shift some priorities around. I guess that pass rules should be before (quick) block rules in any case.
I expect some of this to stem all the way back to 2014 and not much was changed in ordering since...
Cheers,
Franco
-
Got a chance to agree on this internally and here is the fix: https://github.com/opnsense/core/commit/24dd5c3a9e
Cheers,
Franco
-
I did the patch this morning and it does seem to work.