Dropping packets from IP's vs Black-holing routes for IP's?

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 119

PostPosted: Sat Sep 25, 2021 13:39    Post subject: Dropping packets from IP's vs Black-holing routes for IP's? Reply with quote
There are 2 ways I can block Google DNS IP's and ISP DNS IP's on my router:
- Using NAT firewall to drop packets of mentioned IP's
- Using NAT static route black-hole feature that increases metric value for mentioned IP's to prevent router from using routes with mentioned IP's and resolving them to a "black hole" (0.0.0.0 Null IP), similar to how DNS blocking works.

Some articles online say that "black-holing" via static route metric values should not be used to block whichever IP's, unless it is the last resort to block those IP's.

Other articles say that "black-holing" is easier on router hardware and does not decrease throughput as much as NAT firewall rules do.

Border Gateway Protocol (BGP) also plays a role. It can be used to create an attack by re-routing traffic, but it can also reduce tracking because your connections are not routed the same every time. "Black-holing" increases chances of your connections using the same route each time, making it easier to track you and to attack you, but the same "black-holing" can be used to prevent routing through malicious IP's or IP's used for tracking (Google DNS, ISP DNS).

What do you say? Block IP's via firewall or block IP's via static routing?
Sponsor
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 119

PostPosted: Sun Sep 26, 2021 23:02    Post subject: Reply with quote
If blackholing routes is less stressful on routers, then routing is processed before IPTables/NAT Firewall. Does that mean that blackholed route IP's aren't going to show up as dropped packets when I view my IPTables?

For example, if I blackhole Google DNS 8.8.8.8 and also create IPTables rules that drops all packets to-and-from 8.8.8.8, then will IPTables record dropped packets when I try to connect to 8.8.8.8? It shouldn't or else it defeats the idea of route blackholing being performance-friendly compared to Netfilter dropping packets.

How can I view me data about how many times whichever route was blackholed?
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 6410
Location: UK, London, just across the river..

PostPosted: Mon Sep 27, 2021 6:43    Post subject: Reply with quote
what router / witch build number ?
it matters as on some routers you can use ipset to block it,
other ways are via dnsmasq or iptables where you can only see iptables statistics

_________________
Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 119

PostPosted: Mon Sep 27, 2021 14:21    Post subject: Reply with quote
UniFi Dream Machine. I know it isn't DD-WRT, but its an overall question about static blackhole routing as a way to optimize network performance.

I want to optimize performance and so far there are 4 ways to block a known public IP using my router + Raspberry Pi running Ad-Guard Home local DNS server (similar to Pi-Hole):
1. Domain Resolution via AdGuard Home
2. Static Routes in router
3. IPTables in router
4. IPTables in Raspberry Pi

What is the correct order of processing? I assume DNS resolution must happen before router takes static routes into consideration and static routes are taken into consideration before IPTables filtering takes place.

Let's use Google DNS 8.8.8.8 (dns.google) as an example. I THINK this is the order of processing:
- If client tries to connect to 8.8.8.8 (dns.google), then AdGuard Home DNS server blackholes dns.google.
- If AdGuard Home DNS server fails to blackhole dns.google, then Raspberry Pi IPTables drops packets to 8.8.8.8.
- If Raspberry Pi IPTables fails to drop packets to 8.8.8.8, then router blackholes 8.8.8.8 via static route.
- If router static route blackhole for 8.8.8.8 fails,
then router IPTables drops packets to/from 8.8.8.8.

Is is also more performance-friendly to create blackhole static routes to filter out Multicast and private IP addresses that are not used in my LAN than to create IPTables for Multicast and private IP addresses that are not used in my LAN?
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 6410
Location: UK, London, just across the river..

PostPosted: Mon Sep 27, 2021 15:48    Post subject: Reply with quote
i dont clearly know your set up but, i would ve use router iptables ...and consider there is no chance to fail...if the rule matches it will be executed....you could do DNS too but DNS is different animal, bear in mind blocking 8.8.8.8 interferes with those devices that have a baked 8.8.8.8 DNS in their firmware...luckily i don't have any of those
_________________
Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 119

PostPosted: Mon Sep 27, 2021 21:58    Post subject: Reply with quote
I called my ISP and asked about blackholing via static routes. They advised against it because they used OSPF protocol and blackholing with OSPF resulted in having static routes advertised. That explained why I kept having connections with 0 packet exchange to some of the blackhole static routes I set for reserved IP ranges that don't exist on WAN and are not part of my ISP's 172.16.X.X and 10.X.X.X hops.

You're right about devices being hard-coded to use 8.8.8.8. Most Android devices that don't use sane ROM's, such as GrapheneOS, CalyxOS, and LineageOS (or use any ROM's with Google Play Services) end up trying really hard to use 8.8.8.8 after initial WLAN connection. I use custom TLS DNS address in Wireless Options + VPN-set DNS addresses + AdGuard Proxy Auto-Mode + Magisk module that loads custom IPTables on boot (on my Android device). Even with all that, both router and Android device IPTables show dropped packets destined to 8.8.8.8. Its insidious...
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Mon Oct 04, 2021 14:43    Post subject: Reply with quote
I have a router in front of my asus aps(dd-wrt). Once I did this the black holes cleared up but you gotta make sure your net performs properly first. I chose a gateway box that will make permanent the avoidance of black holes. If this doesn't correct like you think, you better choose another gateway/router.

echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing
echo 1464 > /proc/sys/net/ipv4/tcp_base_mss

More so the 1464 thing.
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Mon Oct 04, 2021 14:48    Post subject: Reply with quote
Dd-wrt likes port tagging, and not vlan tagging which are both preferable. I stress the importance of this because mtu is important. You gotta get tag traffic working.
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Sun Oct 10, 2021 8:50    Post subject: Reply with quote
NEITHER of these is wise or good if your goal is decreasing router load.

The way to do it to decrease router load is to install a route pointing to a dead IP.

So if you want to kill traffic to 8.8.8.8 and your inside network is 192.168.1.x you install a route on the gateway router pointing 8.8.8.8 to 192.168.1.254 (assuming you have nothing at .254 of course)

When the gateway router gets a packet from a host at, say, 192.168.1.50 destinated to 8.8.8.8 it will issue an ICMP redirect route for 8.8.8.8 which the host at 192.168.1.50 will install. Subsequent packets from the host will then be sent to 192.168.1.254 and not to the router thus the router does not have to deal with them.

In addition the process attempting to open the connection to 8.8.8.8 will then hang, thus reducing it's packet-generating capabilities while it waits around for a response.

There's a discussion on this here specific to Linux:

https://serverfault.com/questions/901251/how-long-is-an-accepted-icmp-redirect-observed-for-and-how-can-i-shorten-that

for Windows they learn and keep them for 10 minutes:

https://social.technet.microsoft.com/Forums/windows/en-US/43e77e75-6bbf-45df-a723-d53add59aa47/how-is-icmp-redirect-enabled?forum=winserver8gen#:~:text=Windows%20NT%20Specifics%3A,relearned%20through%20another%20ICMP%20Redirect.
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Thu Oct 14, 2021 21:06    Post subject: Reply with quote
When enabled, causes TCP to try to detect "Black Hole" routers while doing Path MTU Discovery. A "Black Hole" router does not return ICMP Destination Unreachable messages when it needs to fragment an IP datagram with the Don't Fragment bit set. TCP depends on receiving these messages to perform Path MTU Discovery. With this feature enabled, TCP will try to send segments without the Don't Fragment bit set if several retransmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS will be decreased and the Don't Fragment bit will be set in future packets on the connection. Enabling black hole detection increases the maximum number of retransmissions performed for a given segment.

Under Windows 9x, the Registry setting is PMTUBlackHoleDetect, under Windows NT 4 it is EnablePMTUBHDetect.


I really question dd-wrts default ipv6 mtu.
i.e. setup->IPV6

IPV6 is lazy to begin with if you dont use nat
correctly. PMTU with
echo 1464 > /proc/sys/net/ipv4/tcp_base_mss

helped me. dns is important.


I use 1500 for the ipv6 mtu, its the standard, sure pmtu is important but its important down the road. It can be easily misdirected unless you use nat and dns properly.

with dd-wrt dnsmasq will dig you out.

windows is still susceptible to black holes and
the feel of this registry setting(EnablePMTUBHDetect)
is not all that great. It needs to be fixed at the network level or the BH will traverse your network.
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Thu Oct 14, 2021 21:22    Post subject: Reply with quote
Pointing to a dead ip can only be used to offload traffic, and this is improper.
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Thu Oct 14, 2021 21:34    Post subject: Reply with quote
I dont know if anyone has rated this but this might help get you there. Again look and feel might be squirrely.

iptables -t nat -A INPUT -j SNAT --to-source 0.0.0.0-255.255.255.255
iptables -t nat -A OUTPUT -j DNAT --to-destination 0.0.0.0-255.255.255.255
eugene1973
DD-WRT User


Joined: 21 May 2017
Posts: 186

PostPosted: Thu Oct 14, 2021 22:06    Post subject: Reply with quote
You might get slighly better results if you make those commands static. But really PMTU is supposed to be more dynamic. I dont know if these will be permanent after this but making them more static might help.

sysctl -w net.ipv4.tcp_mtu_probing=1
sysctl -w net.ipv4.tcp_base_mss=1464
tedm
DD-WRT Guru


Joined: 13 Mar 2009
Posts: 554

PostPosted: Sun Oct 17, 2021 9:16    Post subject: Reply with quote
eugene1973 wrote:
When enabled, causes TCP to try to detect "Black Hole" routers while doing Path MTU Discovery.


He's not using proper terminology, Eugene. He means null routing when he says blackhole routing he doesen't have enough experience to know that professional admins avoid using the term blackhole with routing issues because it's also used with MTU black holes and it's easy to confuse the two. Maybe he just likes the word black hole, it sounds more cool than null I guess. All that MTU stuff you posted regarding network black holes likely went completely by him. What he's asking has nothing to do with MTU.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 119

PostPosted: Sun Oct 17, 2021 10:51    Post subject: Reply with quote
tedm wrote:
NEITHER of these is wise or good if your goal is decreasing router load.

The way to do it to decrease router load is to install a route pointing to a dead IP.

So if you want to kill traffic to 8.8.8.8 and your inside network is 192.168.1.x you install a route on the gateway router pointing 8.8.8.8 to 192.168.1.254 (assuming you have nothing at .254 of course)

When the gateway router gets a packet from a host at, say, 192.168.1.50 destinated to 8.8.8.8 it will issue an ICMP redirect route for 8.8.8.8 which the host at 192.168.1.50 will install. Subsequent packets from the host will then be sent to 192.168.1.254 and not to the router thus the router does not have to deal with them.

In addition the process attempting to open the connection to 8.8.8.8 will then hang, thus reducing it's packet-generating capabilities while it waits around for a response.

There's a discussion on this here specific to Linux:

https://serverfault.com/questions/901251/how-long-is-an-accepted-icmp-redirect-observed-for-and-how-can-i-shorten-that

for Windows they learn and keep them for 10 minutes:

https://social.technet.microsoft.com/Forums/windows/en-US/43e77e75-6bbf-45df-a723-d53add59aa47/how-is-icmp-redirect-enabled?forum=winserver8gen#:~:text=Windows%20NT%20Specifics%3A,relearned%20through%20another%20ICMP%20Redirect.


Thanks!
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum