OPNsense Forum
English Forums => General Discussion => Topic started by: Ricardo on October 26, 2018, 12:21:10 pm
-
Hello all,
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.
Actually, 10/8 in its entirety is not considered to be private anymore, as according to RFC6598 CGN has been officially allocated to 100.64.0.0/10 (reference: https://tools.ietf.org/html/rfc6598)
So while it is still advisable to block non-routable private address space on a public-IP WAN connection, CGN peers should be allowed to come through. Disabling the block of Private networks opens a possible security hole for spoofed IP attacks, while Blocking private networks blocks many hosts that are located behind the same ISP as my router.
I think it would make sense to either exclude the CGNAT range from 10/8, or create a new third category: "Block CGNAT networks". What do you think?
-
Actually, 10/8 in its entirety is not considered to be private anymore, as according to RFC6598 CGN has been officially allocated to 100.64.0.0/10 (reference: https://tools.ietf.org/html/rfc6598)
The mentioned RFC does not touch the already as private registered networks. Regarding the similar looking networks the private one begins with 10 (10.0.0.0/8) whereas the shared address space begins with 100 (100.64.0.0/10). So there is no overlapping.
[...]CGN peers should be allowed to come through. Disabling the block of Private networks opens a possible security hole for spoofed IP attacks, while Blocking private networks blocks many hosts that are located behind the same ISP as my router.
By the way CGN does not always use this kind of addresses, it is only used in double NAT scenarios (e.g. Dual-Stack with non-public ip). Idea of the shared address space is to avoid conflicts with private networks at CPE. But if your sevice provider communicates with you via shared address space both addresses (CPE and AFTR) don't have to be blocked. But I think, there is no need to unblock the whole shared address space.
-
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.
-
In fact, the log message is confusing. Under which configuration (blocking bogon or private addresses) does this log message occur?
In general the address block is dedicated to ISPs, but in log files it should be described as "CGN shared address space (RFC 6598)" or similar.
-
My suggestion would be to edit the help text to say that CGN networks are considered private for the purpose of the feature if it's a real world problem. At least in any case it has a quick fix...
Bogon networks provided by http://www.team-cymru.com/bogon-reference.html still list 10.0.0/8 so I'd hope that is of some authority to rely upon.
That being said, unblocking 100.64.0.0/10 is a bit difficult since bogons are "block in quick" meaning we'd have to engineer breaking up 10.0.0/8 into all the pieces that leave out 100.64.0.0/10. PRs welcome, but prepare for in-depth review of loosely related components to be able to integrate this properly. Maybe some folks would still be able to block 10/8 including CGN. I don't know, but retaining defaults is usually the safest route.
Cheers,
Franco
-
Sorry, I misread the whole thing too (10 vs. 100). Please ignore.
Block private networks <- remove from here?
Block bogon networks <- also keep away from here?
Cheers,
Franco
-
Patch for discussion: https://github.com/opnsense/core/commit/fba9b8ab2
# opnsense-patch fba9b8ab2
-
And for historic reference: https://github.com/pfsense/pfsense/commit/8b1a702394f
-
After more thought adding 100.64.0.0/10 to "private" blocking is the lesser of two evils: if we don't block it in private, we need to put it into the bogons because it's being listed here! So instead of disabling private blocking to allow CGN you'd have to lose all the bogon protection instead.
Is that what you would want? The patch works, but only because 100.64.0.0/10 is then being treated as a non-bogon network, but the bogons file says it is...
... long story short it would be saner to mention it in the help text as initially suggested. ;)
Cheers,
Franco
-
I think, the shared address space (100.64.0.0./10) does not belong to the private ones, so it should not be included there. My question is, what is the criteria for treating addresses as bogons?
-
See http://www.team-cymru.com/bogon-reference.html
For CGNAT chapter 3,4 and 6 of RFC6598 should be considered (these are the consideration for ISPs but there are also references what CPEs should do.)
https://tools.ietf.org/html/rfc6598
CGNAT and Bogons should be filtered by your RIR.
I think 100.64.0.0/10 should be allowed on the WAN Interface but should not be forwarded when source or destination on the LAN side.
-
Hello,
Woah, let's be realistic for a second. :)
What is the minimum viable change that:
1. Doesn't just assume 100.64.0.0/10 is not a bogon.
2. Ideally doesn't add another checkbox.
3. Adds security instead of taking it away.
4. Can be done with under 10 lines of code changes?
Cheers,
Franco
-
was this ever resolved??
I'm now using an install with an ISP that has CGNAT using below:Internal range – 100.68.0.0/17
External ranges: 121.200.4.0/22 (121.200.4.0 – 121.200.7.255)
The problem is the default (auto generated rules) blocks incoming traffic so it never had a chance to hit any of my own rule.