But this prevents NAT rules from changing RFC1918 into normal IPs.. It allowed interface-to-interface and VPN traffic to work, but nothing from the LAN to the internet.. The rule was being applied in the wrong spot..
What is the best way to accomplish this? Best meaning least overhead on the router and simplest to enter/understand/follow.
Indeed firewall filter rule is not the right place. If you study packet flow, part describing “Flow of Routed Packet” you’ll see that firewall filter ruels come as part of “Forward” box while src-nat only comes as part of “Postrouting” box. I don’t know if it’s actually possible to block packets with RFC1918 src-addresses from egressing router in case NAT misses them.
Perhaps an idea (very resource in-effective): create an extra bridge (named e.g. bridge-WAN), add WAN port to it, use that bridge as WAN interface and use bridge filter on bridge-WAN to block any packets still having src-address or dst-address from RFC1918 ranges.
But: how do you figure that RFC1918 addresses are actually leaving to internet? I’m not saying MT doesn’t leak them some times, but with proper SRC-NAT rule it should be fine most of time.
I guess that it doesn’t matter how many interfaces you’d like to “protect” this way … it’s the packet rate leaving via all those interfaces combined as every single packet to and from those interfaces will be subject to bridge filter(s).
/ip route
add blackhole disabled=no dst-address=10.0.0.0/8
add blackhole disabled=no dst-address=172.16.0.0/12
add blackhole disabled=no dst-address=192.168.0.0/16
(NOTE1: add more or remove bogon addresses as you see fit.)
(NOTE2: If you need to reach your ISP/MODEM, and it conflicts with bogon addresses, ensure there is a path for that traffic depending upon individual requirements and potentially could be solved by approaches such as IP route or IP address.)
Because the routes are the supernets - what will actually happen is if there’s no local path for traffic within those routes, then it will blackhole rather than use 0.0.0.0/0 which is of course hitting your NAT rule.
So for basic example you have
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
You have internal traffic in and out between those subnets, those subnets can NAT to the world and possibly talk internally - point is they have a /24 route in the routing table on your router.
someone tries to go 192.168.4.0/24 - it tries to route via internet, this is what you want to block
with 192.168.0.0/16 blackhole route, if you have no local networks using it, it won’t try go out via your internet connections. But active routes internally still will work, as if it tries 192.168.3.x, it sees the 3.0/24 as the active route, but 4.0 would see .0.0/16 is active route which says to blackhole it.
Its not as clean as a firewall rule would be but should have the same outcome.
if step #1 produces more than single route, select the one with lowest distance
The step #1 is vital. And works in vast majority of cases.
Just an example: typical SOHO router will have one or two implicit routes to connected networks: one towards LAN (because router’s got LAN IP address together with subnet mask) and one towards ISP (if ISP provides internet via IP … either static or DHCP IP address, again with subnet mask). And then there will be one route: default. Many devices and OSes will display something like “default via ”, ROS will display “0.0.0.0/0” as dst-address (which is default property and will be thus omitted from export). Which means that packets will be routed towards LAN if destination IP address belongs to that subnet because network mask of route towards connected network (24) is longer than network mask of default route (0). And blackhole route is not different, only destination makes it somehow special (but that comes after route selection).
There’s complication: multiple routing tables … but then some magic needs to tell router which routing table needs to be used for a particular packet, the rest is done according to the list above.
Thinking about this further, I like it as a general rule.
Thank you.
However, it is ‘standard’ to have a rule not to allow bogon source IPs from entering from the internet.. I am trying to prevent my router from being “part of the problem” so creating a filter to prevent such traffic.
You can use an axe (filter) or you can use a sharp japanese fillet knife (route).
To put it in words that my followers (to clean up my messes!!) Sob and Mkx expect, I dont give dos mierdas about what is ‘standard’ especially if it is one that is possibly perceived vice real, I care about simple, clean, efficient and elegant.
So be careful with src-nat, after that, don’t worry about it? Fair enough..
When not using VPN providers, I rarely see it (bogon sourced IPs), I suspected it was being filtered, so wanted to do the same.. Again, part of the problem or part of the solution..
Blackhole route is indeed the correct way to do this. Your more specific local prefixes will take precedence over blackhole.
If you are concerned with private IPs entering your WAN interface, use strict reverse path filtering instead of a firewall rule, it will be more efficient.
I’m concerned with the opposite, private IPs leaving.
To be clear, with an example, I’m trying to prevent traffic to 8.8.8.8 from 192.168.0.3, from leaving my ‘Wild’ list of interfaces, as a last-line-of-defense. Right now, the best I’ve got is be careful with src-nat.
My inital though was a simple ‘filter’ but the ‘filter’ drops it before it gets to ‘NAT’.
Hi Rich, restrictive filtering vice the current setting of loose.
What penalties does on pay for that approach as there must be a reason mine is on loose, other than I like to match my skin turgor, which at my age is loose.
