Carrier Grade NAT (CGN) range to be separated from "Block private network" group

[soder10]

Hello dev team,

as per this thread: https://forum.opnsense.org/index.php?topic=10059.0

If I check the Interface \ WAN settings, I have the following choices: to selectively block Private networks AND/OR Bogus networks from connecting to my router.

Block Private network has the following help text:

Block private networks
When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8). This option should only be set for WAN type interfaces that use public IP address space.

--- Pls disregard my opening post about 10/8, as this topic is really about 100.64.0.0/10 (reference: https://tools.ietf.org/html/rfc6598) ---

Yes, I know it may be confusing that I mentioned the 10/8 range in this topic for the CGNAT discussion, sorry for that.

But what I can clearly see in the firewall log is the following and similar entries:

100.73.8.126:33827 84.xx.yy.zz:9000 udp Block private networks from WAN

100.73.8.126 is not private network. At least not in the similar way as 10/8 or 192.168/16 is.

So in short, can there be a way to handle ISP-based (CG)NAT addresses separately from truly private addresses at the WAN leg?

[AdSchellevis]

You can always disable block private networks and apply your own rules, there's no need to use the integrated block list.

[soder10]

Thanks @AdSchellevis for the clarification, yes I know that those default block rules are there to switch them on/off easily as per requirement. My main goal with this thread is to make anyone aware that using the default block private networks rule applied on the WAN interface may also block some legitime traffic.

[fichtner]

@soder10 as a base for discussion: fba9b8a

# opnsense-patch fba9b8a

[soder10]

"opnsense-patch fba9b8a"

is that cmd safe to run on a live system / what would be the result of it?

[fichtner]

it applies the patch you linked yourself in your message loading it directly from github over HTTPS. The patch is harmless to production systems, but I'm no longer convinced that patch is needed...

[soder10]

Anyway, I run the command, it seemed it has done something, but I still see the same "Block private network from WAN" rule match for these 100.64 source adresses.

[fichtner]

You need to reload the packet filter for the patch to be of effect. :)

[soder10]

I did restart pf. But seems no difference.

I am curious if the patch applied successfully:

diff --git a/src/opnsense/scripts/filter/update_bogons.sh b/src/opnsense/scripts/filter/update_bogons.sh |index fe8c3daa2..336eb534e 100755 |--- a/src/opnsense/scripts/filter/update_bogons.sh |+++ b/src/opnsense/scripts/filter/update_bogons.sh -------------------------- No file to patch. Skipping... Hunk #1 ignored at 56. 1 out of 1 hunks ignored--saving rejects to opnsense/scripts/filter/update_bogons.sh.rej done

[soder10]

Or did you mean there is a scheduled bogon network definition update setting under firewall, and it is actually set as "MONTHLY" for my system, so would need to wait 1 month until this patch is applied?

[fichtner]

update_bogons.sh chunk is irrelevant. the patch excludes the CGN from private blocking and bogons blocking as well. the problem is that now that it's not dropped by these rules it's probably not logged and dropped by the default rule instead if it's not explicitly passed on...

[soder10]

Thanks for the explanation, the output what the patch made to the CLI was chinese to me. Actually I noticed something was going on, as I no longer see in the pf log those CGN inbound attempts blocked anymore. But I dont see them allowed either. Note: I dont have any explicit rule matching them.

[fichtner]

Yes. So the real question is: what do you want to do with CGN? We've talked quite a bit and it seems like a theoretical issue, not a real world issue?

[soder10]

No issue here! Just wanted to allow/pass traffic FROM CGN to LAN. But after I applied the patch you sent above, it didnt do that. I have restarted pf service couple of times, and it didnt help. I thought the update_bogon.sh must be scheduled to actually remove the 100.64/10 from the current bogon-list (as it seemed to me they are still there, and the patch didnt remove them). But now, I no longer see blocked traffic in pf log from CGN range, so I can assume that this type of traffic is allowed now, as a result of removed from the bogon list.

Sorry guys, but without detailed instructions (or a detailed guide) its only you the devs who understand what you are doing, we (the externals) are in some kind of darkness :)

[fichtner]

I've added a note to the private blocking that it includes CGN. In general it seems the help text is clear that private blocking is only recommended when WAN has an IP address in the public space.

As for opnsense-patch it's not more complicated than running the command once for patching and once for removing. While it patches the source code, it does just this. Operating the code is still done via GUI or can be forced by a clean reboot. Sometimes patches fail because of constraints of the tools used like patch(1), fetch(1) or git(1). opnsense-patch is just over 100 lines of code to install development patches easier, not fail-safe or self-contained.

Cheers, Franco