What is the best way to prevent internal traffic from leaving?

kevinds · Mon Mar 28, 2022 9:42 am

Not sure the best way to phrase my question..

I want to prevent packets with RFC1918 source IPs from leaving to the internet while still allowed inside my network...

My first thought was

/ip firewall filter add action=drop chain=forward comment="Drop Leaving RFC1918" disabled=yes out-interface-list=Wild src-address-list=RFC1918

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.

mkx · Mon Mar 28, 2022 9:57 am

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.

[edit]: added paragraph about WAN bridge

kevinds · Mon Mar 28, 2022 10:02 am

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 don't figure that they are.. Trying to make sure that they don't and hopefully a 'log' rule that will alert me if it does happen..

'Most of the time' I agree.. But 'most' isn't all..

kevinds · Mon Mar 28, 2022 10:56 am

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.

Interesting idea..

Have three interfaces in my Wild list now.. I wonder how much of a performance hit it would be.. Humm..

mkx · Mon Mar 28, 2022 12:29 pm

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).

anav · Mon Mar 28, 2022 2:41 pm

/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.)

kevinds · Tue Mar 29, 2022 2:41 am

/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.)

Unless I'm missing something, this will blackhole all internal traffic..

kevinds · Tue Mar 29, 2022 2:51 am

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).

My peak/burst is around ~500 mbps both directions for the Wild list.

Jotne · Tue Mar 29, 2022 8:37 am

Unless I'm missing something, this will blackhole all internal traffic..

No, it will only block traffic that has destination IP in the blackhole route.

kevinds · Tue Mar 29, 2022 8:43 am

Unless I'm missing something, this will blackhole all internal traffic..
No, it will only block traffic that has destination IP in the blackhole route.

So
a) wouldn't acomplish the intended goal
and
b) will block all internal traffic

Internal traffic being traffic not going to the internet..

joegoldman · Tue Mar 29, 2022 8:56 am

No, it will only block traffic that has destination IP in the blackhole route.
So
a) wouldn't acomplish the intended goal
and
b) will block all internal traffic

Internal traffic being traffic not going to the internet..

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.

kevinds · Tue Mar 29, 2022 9:06 am

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.

Needs a distance/priority too then? 254 perhaps? Otherwise the blackhole could still be used instead of routing to another router?

mkx · Tue Mar 29, 2022 10:24 am

Needs a distance/priority too then? 254 perhaps? Otherwise the blackhole could still be used instead of routing to another router?

No, selecting routes is done in this order:

select route with longest subnet mask
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 <gateway IP address>", 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.

kevinds · Tue Mar 29, 2022 2:54 pm

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.

anav · Tue Mar 29, 2022 3:10 pm

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.

kevinds · Tue Mar 29, 2022 3:52 pm

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..

R1CH · Tue Mar 29, 2022 4:07 pm

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.

kevinds · Tue Mar 29, 2022 4:14 pm

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'.

R1CH · Tue Mar 29, 2022 4:56 pm

Then add a blackhole route for 192.168.0.0/16

anav · Tue Mar 29, 2022 5:36 pm

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.

kevinds · Tue Mar 29, 2022 6:00 pm

Then add a blackhole route for 192.168.0.0/16

This doesn't accomplish the goal.

Sob · Tue Mar 29, 2022 8:05 pm

Your problem is that you want to block something (which is done in forward chain) depending on what will or will not happen after that (in srcnat chain). Until someone invents some "time machine module" (read time travel) that could be installed in router, it can't be done. You need to decide. Either 192.168.0.3 is not allowed to access 8.8.8.8 via interfaces listed in Wild list at all, then you can simply block it in forward chain. Or it's allowed to do that, and you just need to be sure that srcnat won't miss it, then make sure that you have correct srcnat rules. If you're doing something complicated with many srcnat rules, you can add unconditional one at the end, which may help a bit:

/ip firewall nat
add chain=srcnat out-interface-list=Wild action=masquerade

It's not foolproof, some action=accept rule before that can still ruin it. You have to be careful, I don't see any other way.

R1CH · Tue Mar 29, 2022 8:26 pm

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.

Loose mode allows asymmetric routing and only drops packets with no valid route. Strict mode requires that the interface the packet came in on is also the best route for a response, e.g. if you have 192.168.3.0/24 as LAN and a packet arrives on WAN with source IP 192.168.3.5, it would be dropped since LAN is the best interface for a packet destined to 192.168.3.5. Unless you have complex asymmetric routing scenarios, strict mode should generally be used.

Doing this on the firewall (e.g. blocking private IP space on raw or input) has a penalty for every valid packet, allowing it to be handled at the routing level is basically free since the packet would have to be processed there anyway.

Jotne · Tue Mar 29, 2022 8:33 pm

@kevinds
Why block 8.8.8.8 for some hosts?

I have seen that Chromecast has fixed 8.8.8.8 and fails if you try to grab traffic to udp 53 and send it to another DNS.
Also if some block my DNS that I like to use, I just change to DoH or DoT.

kevinds · Tue Mar 29, 2022 9:02 pm

@kevinds
Why block 8.8.8.8 for some hosts?

I have seen that Chromecast has fixed 8.8.8.8 and fails if you try to grab traffic to udp 53 and send it to another DNS.
Also if some block my DNS that I like to use, I just change to DoH or DoT.

Just an example.

Because if the source IP is 192.168.0.3, Google should just drop the packet , it can't send traffic back to it.

rextended · Tue Mar 29, 2022 9:09 pm

@kevinds some traffic like TCP Reset packet, and other, are NOT NATted because is useless NAT the last (expected) "end packet" of the connection.
You do more damage than the cure, if you blindly block all internal natted IP on out...

kevinds · Tue Mar 29, 2022 9:18 pm

if you blindly block all internal natted IP on out...

I'm trying to block the not-natted traffic with internal IPs from leaving the Wild list of interfaces.

mkx · Tue Mar 29, 2022 9:29 pm

TCP Reset packet, and other, are NOT NATted because is useless NAT the last (expected) "end packet" of the connection.

No, TCP RST packet is not useless at all.

But I guess you're talking about TCP FIN packet. Many TCP stack implementations send TCP FIN packet to the other end twice ... exactly because informing remote end that TCP connection is ended is important. However, MT's connection tracking removes connection from the list when seeing first TCP FIN packet. When another one arrives, the connection to which it actually belongs, is not tracked by ROS any more. If connection is NAT-ed (either SRC-NAT or DST-NAT), the packet is not NATed any more (since NAT heavily relies on connection tracking).

Back to concerns of @kevinds: it is a bit unpleasant if internal IP addresses leak out of border router, might give some potential attacker some idea (and idea by @R1CH about setting rp-filter to strict should reduce attack surface a lot). But apart from that, even if e.g. non-NATed packet would eventually arrive at google, they would probably deal with it (as a part of self-defence). Just like you really have to care about packet arriving at your border router from WAN interface(s). Personaly I wouldn't care too much of some leaked lone packets ... if NAT rules were not doing their job, you would notice that because some connections simply wouldn't establish (because many routers out there do drop packets RFC1918 destination addresses ).

Jotne · Tue Mar 29, 2022 10:18 pm

Because if the source IP is 192.168.0.3, Google should just drop the packet , it can't send traffic back to it.

Then you should remove 8.8.8.8 DNS settings from 192.168.0.3

kevinds · Tue Mar 29, 2022 10:26 pm

Because if the source IP is 192.168.0.3, Google should just drop the packet , it can't send traffic back to it.
Then you should remove 8.8.8.8 DNS settings from 192.168.0.3

This discussion has nothing, absolutely nothing to do with DNS.

kevinds · Tue Mar 29, 2022 10:30 pm

Back to concerns of @kevinds: it is a bit unpleasant if internal IP addresses leak out of border router, might give some potential attacker some idea (and idea by @R1CH about setting rp-filter to strict should reduce attack surface a lot). But apart from that, even if e.g. non-NATed packet would eventually arrive at google, they would probably deal with it (as a part of self-defence). Just like you really have to care about packet arriving at your border router from WAN interface(s). Personaly I wouldn't care too much of some leaked lone packets ... if NAT rules were not doing their job, you would notice that because some connections simply wouldn't establish (because many routers out there do drop packets RFC1918 destination addresses ).

Fair enough...

Trying to be a good net-citizen.. I'll leave it be.

Wanted to make sure I wasn't missing something.

Jotne · Tue Mar 29, 2022 10:47 pm

This discussion has nothing, absolutely nothing to do with DNS.

I'm trying to prevent traffic to 8.8.8.8

Is not 8.8.8.8 a DNS IP.
What else is 8.8.8.8 used for?

I just try to figure out why you request what you do to see if there is an other approach to the problem

PS you do not need to Quote the whole post above you. Use the green Post Reply under the post to replay to a post.
Quote part of post to point out stuff, or quote when other post between, but only include what you quote to and not the other quote in same post.

Sob · Tue Mar 29, 2022 11:35 pm

What else is 8.8.8.8 used for?

Example public address. It's much easier to remember than dedicated 192.0.2.x, 198.51.100.x, 203.0.113.x.

mkx · Tue Mar 29, 2022 11:50 pm

Because if the source IP is 192.168.0.3, Google should just drop the packet , it can't send traffic back to it.
Then you should remove 8.8.8.8 DNS settings from 192.168.0.3

You're missing the point. @kevinds is fine if 192.168.0.3 can connect to 8.8.8.8 ... what he's not fine with is possibility that packet leaving his border gateway is still having src-address set to 192.168.0.3 while it should be some public address.

Sob · Wed Mar 30, 2022 12:01 am

But that shouldn't really happen. Srcnat/masquerade on outgoing interface takes care of valid connections. And if there are some packets that conntrack doesn't see as part of valid connection, and as such wouldn't apply srcnat to them, they can be identified using connection-state=invalid and dropped.

kevinds · Wed Mar 30, 2022 1:53 am

Srcnat/masquerade on outgoing interface takes care of valid connections.

You assume all traffic gets srcnat treatment?

For my networks, this isn't the case. Some traffic is NAT'd, some isn't. RFC1918 between locations isn't NAT'd as well as some routed public IP traffic.

Sob · Wed Mar 30, 2022 3:22 am

It's possible that you have something more complex. But VPN traffic has either own interfaces or IPSec policies, so it shouldn't go to WAN interface, and even if it somehow would, you can match it using dst-address(-list)=remote_subnet(s) and block it, or stop it with unreachable routes. And public source addresses are not a problem either, because now you're trying to stop private source addresses.

You can always share more details, describe what exactly you have, what you think could be a problem, how it could happen, etc. And then it's possible to have discussion about that, if there's really such danger, and what can be done about that.

kevinds · Wed Mar 30, 2022 3:43 am

Really, I'm trying to prevent 'bad' source IP packets, specifically bogons, from going to the internet. Preferably with a way to alert someone about (log that triggers an alarm as an example), but this is optional.

This particular router has one transit interface, two (different) exchange interfaces, local public IPs, NAT interfaces, plus VPN traffic on RFC1918 IPs that doesn't get NAT'd unless it goes to the internet. Also routes some public IPs to the other sites over the VPNs.

This router may have a src-nat rule for 192.168.0.0/23, but it won't for 192.168.2.0/23 and 192.168.4.0/23 in use other places.

192.168.0.0/23, 192.168.2.0/23 and 192.168.4.0/23 all communicate without NAT.

My concern example is traffic from 192.168.2.0/23 ending up on the 'main' router, sending traffic out to the internet with the 192.168.2.0/23 source IPs. Various sites could have this main router as the 0.0.0.0/0 route.

This is why I started with the filter rule, to drop src-ip bogons from leaving the Wild interface list.. But I need it applied after NAT, so this rule failed successfully.

rextended · Wed Mar 30, 2022 4:16 am

Are you sure you are doing all for nothing?
Probably your ISP already block all packet with one bogon IP as destination or source...
Like do I for all my clients....

kevinds · Wed Mar 30, 2022 4:31 am

Like do I for all my clients....

How?

When connected to an IX, who is the ISP?

Why do you do it, if it doesn't matter?

Sob · Wed Mar 30, 2022 4:58 am

What I meant is, for example:

If you have LAN with 10.0.1.0/24 and remote 10.0.2.0/24 accessible using VPN, then either you have plain IPSec without own interface, or any other kind of VPN with interface. If it's IPSec, then to firewall it seems that it uses WAN as outgoing interface. But policies will block sending of unencrypted packets. And if you want extra insurance, you can allow only encrypted ones using (and block the rest):

/ip firewall filter
add chain=forward src-address=10.0.1.0/24 dst-address=10.0.2.0/24 ipsec-policy=out,ipsec action=accept

If it's VPN with interface, then (and block the rest):

/ip firewall filter
add chain=forward src-address=10.0.1.0/24 dst-address=10.0.2.0/24 out-interface=VPN action=accept

Or if you have default-allow firewall, it could be e.g. one of:

/ip firewall filter
add chain=forward src-address=10.0.1.0/24 dst-address=10.0.2.0/24 out-interface=WAN action=drop
add chain=forward src-address=10.0.1.0/24 dst-address=10.0.2.0/24 out-interface=!VPN action=drop

And even if you use WAN interface for both encrypted and unecrypted traffic, you can selectively allow what you need:

/ip firewall filter
add chain=forward src-address=10.0.1.0/24 dst-address=10.0.3.0/24 out-interface=WAN action=accept
add chain=forward src-address=10.0.1.0/24 dst-address-list=rfc1918 out-interface=WAN action=drop
/ip firewall nat
add chain=srcnat src-address=10.0.1.0/24 dst-address=!10.0.3.0/24 out-interface=WAN action=src-nat to-addreses=1.2.3.4

It can get more complicated, but you should be able to define what exactly can go out in a way that either it's fine without NAT, or if it isn't, then it will always apply.

kevinds · Wed Mar 30, 2022 5:15 am

Thank you.

I'm going to digest these rules at least overnight, likely into tomorrow. At first look they again seem to be focused on the destination network, so I am going to look closely and carefully work through them.

After starting with bogons, I can then move to prevent random source IPs (used as DDoS targets).

Sob · Wed Mar 30, 2022 5:24 am

Yes, there's destination, because you wrote that some need to be with NAT and some without, so you need to cover what's allowed and under what conditions.

Handling random sources is easy for static config. E.g. if you know that LAN has only 10.0.0.0/24, then you can do:

/ip firewall raw
add chain=prerouting in-interface=LAN src-address=!10.0.0.0/24 action=drop

And there won't be any spoofing from there.

kevinds · Wed Mar 30, 2022 5:33 am

Cool

Should be able to make a combonation of them work.

Unless @rextended does it better or more elegantly?

Sob · Wed Mar 30, 2022 5:52 am

If I'm not mistaken, he should be able to add some more dynamic enterprisy stuff, if that would help.

rextended · Wed Mar 30, 2022 2:12 pm

Why do you do it, if it doesn't matter?

Is clear you do not understand... my english is not well..
From my ISP point of view, I fight IP Spoofing blocking ALL not on my IP pools (obviously bogons included) than try to go out of my network, and prevent all with my IP pools (or bogons) as source to reach my network.
The clients no matter if are blocking bogon or not, because I do that for all...
Understand now?

anav · Wed Mar 30, 2022 2:57 pm

Why do you do it, if it doesn't matter?
Is clear you do not understand... my english is not well..
From my ISP point of view, I fight IP Spoofing blocking ALL not on my IP pools (obviously bogons included) than try to go out of my network, and prevent all with my IP pools (or bogons) as source to reach my network.
The clients no matter if are blocking bogon or not, because I do that for all...
Understand now?

Yeah it would be better to write what you meant in Italian and use google translate to post........... I didnt understand it.

rextended · Wed Mar 30, 2022 6:22 pm

What parts you not understand?
I try to retranslate

From my point of view as an ISP,
I combat IP spoofing by blocking EVERYTHING outbound that does not come from my IP pools (including also bogons)
and blocking all packets, incoming from internet, that have as source one IP from my pools (or bogons)

At that point it doesn't matter if the customers are blocking the bogons or not, because I do it first for everyone ...

kevinds · Wed Mar 30, 2022 6:27 pm

rextended · Wed Mar 30, 2022 6:49 pm

/ip settings
set rp-filter=strict

and a mix of bgp filter rules, unreachable rules on routing and some on firewall / raw / prerouting
why so much vague?
I do not reveal all secrets of my system.....

anav · Wed Mar 30, 2022 7:16 pm

/ip settings
set rp-filter=strict

This is, as what rextended is saying, should be done at the ISP level not the homeowner level, necessarily and how does rp-filter=strict deal with dual wans...........??
Wishful thinking that all our ISP providers are as considerate as rextended.

The two following rules offered up, take care of the outgoing traffic from the homeowner (seems reasonably easy and not cpu intensive) and should help rextended reduce his overall burden.

/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 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.)

And the second rule from SOB, for which I have to ask ---> What if any is the difference functionally speaking? and then practically speaking???
Both seem to block all outgoing stuff not from an IP on the router (assuming one makes allowances when necessary such as for incoming wireguard addresses)??

/ip firewall raw
add chain=prerouting in-interface=LAN src-address=!10.0.0.0/24 action=drop

NOTE: Where I suppose if you had multiple vlans then one would simply use a source-address-list=!VLAN-subnets

+++++++++++++++++++++++++++++++++++

As for the incoming, if my ISP does not block such nefarious inbound traffic, AND If for some strange reason there is a subnet address that matches one on my LAN subnet, that is coming in on the WAN side, from the internet hitting the router interface, what then??. In other words, I don't rally care about private IP traffic that has nowhere to go on my router anyway, but something sneaky that may mess with my routers brain

!

A. there is no input rule allowing that unless its aiming for a port thats open such as wireguard.
B. there is no forward chain rule allowing that unless its aimed for port forwarding....

Thus in situations A or B, how is that traffic next handled........... if not safely or securely then............
Do we need another firewall raw rule, except one that is 180 degrees different, that specifically blocks my LAN SUBNET addresses inbound???

/ip firewall raw
add chain=prerouting in-interface=WAN LAN src-address=10.0.0.0/24 action=drop

rextended · Wed Mar 30, 2022 7:24 pm

/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

On CPE is better:

/ip route
add distance=1 dst-address=10.0.0.0/8 type=unreachable
add distance=1 dst-address=169.254.0.0/16 type=unreachable
add distance=1 dst-address=172.16.0.0/12 type=unreachable
add distance=1 dst-address=192.168.0.0/16 type=unreachable

Notice: Do not use unreachable on border routers.... better blackhole....

On CPE is useless any other rule or command.
For example, if LAN is 192.168.88.0/24, because on one interface 192.168.88.1/24 is present,
that assigned IP create a route with distance=0 than take precedence for all traffic directed to 192.168.88.0/24 and all the remaining 192.168.x.x/16 give unreachable reply....

anav · Wed Mar 30, 2022 7:36 pm

I am not IT savvy to understand the difference between my home router, an edge router, or a CPE,
Lets just say I have a home router.

Your CPE example will shortly be like bad traffic INVALID ;-P
Version 7 has no option for unreachable!!!

Remember keep the config simple and the explanation simple for the simpletons like me, we are the audience, not the all knowing Sobs and MKXs, who already know this stuff.

kevinds · Wed Mar 30, 2022 10:07 pm

At that point it doesn't matter if the customers are blocking the bogons or not, because I do it first for everyone ...

I could ask someone else to tie my shoes everytime I put them on because they could.. Wouldn't it be better if I tied my own?

anav · Wed Mar 30, 2022 11:26 pm

You can peel an orange only once.....
If its peeled for you why complain?

Sob · Wed Mar 30, 2022 11:56 pm

@anav: The raw rule I posted says that if there's 10.0.0.0/24 on LAN and any other source address comes from there, it should be dropped, because it's not allowed to be there. Using src-address-list=!VLAN-subnets would be compromise. Because if VLAN 1 has 10.0.1.0/24 and VLAN 2 has 10.0.2.0/24, this would allow them to spoof packets from each other VLAN.

As for incoming traffic, you could use raw rules too, to block traffic from private subnets on WAN, because it's not supposed to be there. Slight problem is that it often is there, because some ISPs use private subnets in their networks.

kevinds · Thu Mar 31, 2022 12:38 am

You can peel an orange only once.....
If its peeled for you why complain?

Packets are endless, not just once.

Who is online