CGNAT, 100.64/10 separate from "Block private networks" option

[ZZzzzzz]

Hy all!

As the COVID-19 spread across our country our students ordered to stay home and continue through online learning.

We have a server within school network which stores large media files (learning materials), I published it as FTP server, (not so) few user had trouble to reach this server then I realized our ISP using heavily CGNAT and these users are from same ISP.

So if the user (who is at the same ISP) wants to connect our server (it has fixed public IP) ISP just routing the traffic  towards to our server through the ISP's CGNAT "private" network (100.64.0.0/10)

TL;DR:
- ISP change not an option currently
- We have fixed public IPv4 address for this FTP server.
- We use OPNsense 20.1.3 ( OPNsense 20.1.3-amd64 / FreeBSD 11.2-RELEASE-p17-HBSD / OpenSSL 1.1.1d 10 Sep 2019)
- Our ISP "advice" was not to block 100.64.0.0/10 (CGNAT) address range. This is blocked because I checked "WAN" interface / "Generic configuration" / "Block private networks" option.

How can I allow 100.64/10 perfectly on WAN interface?

Is there a plugin which allows to separate CGNAT from "private networks" block?

I think about an "allow" rule for 100.64.0.0/10 but I can't move this rule above the "Automatically generated rules"

If I disable "Block private networks" could I perfectly replace with custom "block" rule (10/8, 172.16/12, 192.168/16 + 127/8) ?

Is "Block bogon networks" option will affect on custom 100.64.0.0/10 "allow" rule?

Thanks in advance!

[fabian]

First of all, 100.64.0.0/10 is definitly not private. Maybe you have an C&P issue. I guess you ment 10.64.0.0/10.

I don't know if this was changed but in the interface configuration were two checkboxes: Block bogon networks and block private networks. In your case you have to disable both since they create firewall rules which are executed before yours. An easier fix BTW is called IPv6. No NAT anymore at any place

BTW: I would recommend to get rid of this server for security reasons and network problems (firewall and NAT issues). Replace it by something more modern like a Nextcloud if you want a collaboration plattform (it supports WEBDAV to mount it as a network share) or use an elearing solution (the common solution I know for example is moodle, where you can put courses together with files).

[chemlud]

eeehm...

https://en.wikipedia.org/wiki/IPv4_shared_address_space

[ZZzzzzz]

First of all, 100.64.0.0/10 is definitly not private. Maybe you have an C&P issue. I guess you ment 10.64.0.0/10.

Check the attached pictures I'am talking about them.

If you state that 100.64/10 is not "private" (which is basicly other type of "private" a.k.a. CGNAT) why is listed in under "Block private networks" list?

[johnsmi]

100.64.0.0/10 is not defined private. The "checkbox" considers it to be blocked, too. Whatever.


Disable the checkbox and create a Firewall-Rule blocking the "real" private Networks. (i.e. 10/8,192.168.0.0/16, 172.16.0.0/12, fd00/8 )

[ZZzzzzz]

Johnsmi, thank you for your confirmatory response.

I created blocking rules for "real" private networks, so this is solved.

But I left "Block bogon networks" option turned on.

"bogus" option has any side effect which will drop traffic from 100.64/10 range?

[johnsmi]

Bogon networks are not defined, thus you can safely block those.

e.g.
fc00::/8 is not defined/invalid ULA,
fd00::/8 are valid ULA
blocking fc00::/7 doesn't harm.

You can create a single firewall-alias with the networks to block and keep the rules tidy. Also nested aliases with rfc1918, other "private", ULA and so on.

[fabian]

This is fetched from an external source and can be viewed here:

https://github.com/opnsense/core/blob/c28fb86f3764c83b14a910cda863ef6962268131/src/opnsense/scripts/filter/update_bogons.sh#L13

Since it is an alias, you should be able to view the current list in your firewall diagnostics.

[fabian]

Bogon networks are not defined, thus you can safely block those.

e.g.
fc00::/8 is not defined/invalid ULA,
fd00::/8 are valid ULA
blocking fc00::/7 doesn't harm.

You can create a single firewall-alias with the networks to block and keep the rules tidy. Also nested aliases with rfc1918, other "private", ULA and so on.

This is the private IP space in IPv6 fc00::/7. Packets from there should never arrive at the WAN interface. Maybe your provider is doing strange things with IPv6, then it may still happen.

[johnsmi]

This is the private IP space in IPv6 fc00::/7. Packets from there should never arrive at the WAN interface. Maybe your provider is doing strange things with IPv6, then it may still happen.

Neither from RFC1918 ranges if the ISP uses CGNAT.

I've never seen those in any logs. My point was just defining bogon fc00::/8 vs. private fd00::/8. I just chose IPv6, because fc00::/7 combines both easily.