Posted: Sat Sep 25, 2021 13:39 Post subject: Dropping packets from IP's vs Black-holing routes for IP's?
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?
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?
Joined: 16 Nov 2015 Posts: 6445 Location: UK, London, just across the river..
Posted: Mon Sep 27, 2021 6:43 Post subject:
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 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 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 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 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
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?
Joined: 16 Nov 2015 Posts: 6445 Location: UK, London, just across the river..
Posted: Mon Sep 27, 2021 15:48 Post subject:
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 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 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 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 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
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...
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.
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.
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:
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.
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.
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.
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: