I had an idea tonight. Let’s just say I’m not a networking expert by any stretch of the imagination, so even though I’ve set up some fairly advanced configurations, I do at times struggle with the basic concepts.
Anyway, say I have a LAN subnet, 192.168.90.0/24 for example. But it’s getting a bit congested, not because there are 250+ hosts on the subnet, but for structuring reasons. So I played around with an online IP calculator and figured why not make it a /23 network instead, then I would have twice the space. Let’s then say I configure the DHCP server to hand out new addresses from 192.168.91.1 - 192.168.91.250 for example so if I connect a new device or spin up a new VM, it would get an address in this space, while the trusted devices would have reservations in the 192.168.90.10 - 192.168.90.200 space for example. Would I then, in the firewall, be able to use a 192.168.90.0/24 rule to make the first half of the /23 network have access to more stuff (like for example other subnets or VPN tunnels) and use a 192.168.91.0/24 rule to have the new/temporary/not-as-trusted devices on the second half of the /23 network have less access? Or would this be unorthodox/inappropriate/have security implications or maybe not even work or would this be a rather common configuration?
(I am aware that host 192.168.90.50 would always have access to 192.168.91.149 for example, since they would be on the same subnet, that’s not what I’m asking here.)
Why not?
what you cannot do is block users in the same subnet with each other as this connection is L2 not L3.
It is no different then allowing one user in a subnet more or less restrictions to devices in another subnet…
You’ll need two pools, as some devices won’t like the two “border” addresses (that are correct in theory), the last .255 of the first /24 and the first .0 of the second /24, or you will need to assign them statically to dummy MAC’s, see: http://forum.mikrotik.com/t/ip-range-extend/158231/1
Some devices/OS might interpreter the 10.0.0.255 and the 10.0.1.0 as non-valid addresses (believing that a .0 is always network address a and .255 is always broadcast, which they are not in a /23).
Of course - given that the Mikrotik DHCP server tends to assign addresses “downward” (i..e. in a 10.0.0.1-10.0.1.254 range 10.0.1.254 will be first leased address) you would need to have many IP’s assigned before “reaching” those two addresses, but it can happen.
It is a “better be safe than sorry” kind of warning.
Let me get this straight,
If my pool includes the entire 23 network, 10.0.0.0/23 are you saying that the router attempt to assign devices to Ip addresses to 10.0.0.255 and 10.0.1.0 ???
If so, maybe the router should be smarter…
easily worked around assign 10.0.1.0 and 10.0.0.255 to fictitious mac addresses as static assignments and then the router will never attempt to assign them.
As for as firewall rules and address lists, the single pool is NOT an issue, it seems to be solely the above?
Just trying to get to some truth here… and to see what the OPs options can be!!
The issue is that some devices/systems may WRONGLY believe that addresses ending with 0 are “network” and/or addresses ending with 255 are “broadcast” and fail to work as expected.
Interesting responses! Thank you all:) I’ve never thought about that a host/device could be assigned an address ending with a 0 or 255 in larger nets. Seems logical when you think about it, but at the same time it also feels totally wrong. But as pointed out, that is fairly easily mitigated and in my case, the plan is to only have a pool somewhere in the second half of the subnet and then have static leases for anything I want in the first half, so this will not be an issue for me. This is uncharted territory for me, as I’ve (much like @anav) basically only dealt /24 subnets before.
As for the core question about using a /24 rule do deal with different parts of the /23 subnet, no one has indicated that it would be a problem. @anav’s example doesn’t specifically use a /24 rule, but an address list instead.
Example of what I mean:
add chain=forward action=accept comment="grant first half or the /23 subnet access to some other resource" src-address=192.168.90.0/24 dst-address=192.168.70.5
(I do have a block everything rule at the end, but just for a clear example:)
add chain=forward action=drop comment="block second half or the /23 subnet access to some other resource" src-address=192.168.91.0/24 dst-address=192.168.70.5
That is because we are bamboozled by dotted quad notation. The dots are only there for human consumption. You would not be bothered by a binary address 10101010101010101010101000000000 or 01010101010101010101010111111111. But as soon as they are written 10101010.10101010.10101010.00000000 or 01010101.01010101.01010101.11111111 they become problematic.
Extra fake leases inside the leases table are more annoying when working with them than setting up the pools correctly once and for all.
And then I think that taking unnecessary steps later is worse than immediately fixing things as they should be.
Then often some IPs are reserved for static assignments, so it is quite rare to find a /24 completely assigned,
at least 1 IP is often used for the gateway, so the form .2-.254 is more common and logical.
One line without DHCP leases frills
/ip pool
add name=SuperPool ranges=192.168.88.2-192.168.88.254,192.168.89.1-192.168.89.254,192.168.90.1-192.168.90.254,192.168.91.1-192.168.91.254
is better than 10 lines than polluting leases...
/ip pool
add name=SuperPool ranges=192.168.88.0/22
/ip dhcp-server lease
add address=192.168.88.0 mac-address=FE:FF:C0:A8:58:00
add address=192.168.88.1 mac-address=FE:FF:C0:A8:58:01
add address=192.168.88.255 mac-address=FE:FF:C0:A8:58:FF
add address=192.168.89.0 mac-address=FE:FF:C0:A8:59:00
add address=192.168.89.255 mac-address=FE:FF:C0:A8:59:FF
add address=192.168.90.0 mac-address=FE:FF:C0:A8:5A:00
add address=192.168.90.255 mac-address=FE:FF:C0:A8:5A:FF
add address=192.168.91.0 mac-address=FE:FF:C0:A8:5B:00
add address=192.168.91.255 mac-address=FE:FF:C0:A8:5B:FF
bravo