SORRY , nie sprawdziłem na openwrt
Iptables w openwrt nie obsługuje modułu string

Co do samej zasady działania to nie istnieje w tym przypadku problem nadmiernego obciążenia opisywany przez Cezarego.
A to dlatego, ze nie blokujemy adresów IP a słowo kluczowe w zapytaniu DNS
Z blokowaniem youtube według sposobu Cezarego byłby problem, ponieważ na tych samych adresach IP co youtube pracują też inne googlowe usługi.
Dlatego sposób z wykorzystaniem modułu string jest optymalny.
Niestety przynajmniej na razie niedostępny w openwrt

A ja użyłem takiej reguły:

dla całego zakresu sieci wewnętrznej:
/sbin/iptables -A FORWARD -s 192.168.1.0/24 -m string --string "facebook" --algo bm --to 65535 -j DROP

lub dla wybranego zakresu sieci wewnętrznej:
/sbin/iptables -A FORWARD -m iprange --src-range 192.168.1.40-192.168.1.125 -m string --string "facebook" --algo bm --to 65535 -j DROP

Nie trzeba wymuszać DNS-ów routera
Działa dla http i https

Mam /etc/config/openvpn_recipes

Jeszcze jedna ciekawostka tak OT
Odinstalowałem transmission i obsługę drukarki a pliki transmission i p910nd w /etc/config pozostały

Znany problem.
Rozwiązanie:
opkg remove luci-app-mwan3
opkg remove mwan3
reboot

OK, doczytałem:
"usunięcie z obrazów luci dla lantiq pakietów mwan3/luci-app-mwan3"

Czy według Ciebie nie jest zasadne usunięcie tych pakietów z pozostałych dystrybucji?

Ja problem rozwiązałem instalując BB z ze strony openwrt.
Oznacza to, że w obrazach Cezarego jest coś nie tak, chociaż nie udało się ustalić co.
Swoją walkę prowadziłem w tym temacie:
http://eko.one.pl/forum/viewtopic.php?id=10997

Posadziłem wersję z tej lokalizacji:
https://downloads.openwrt.org/barrier_b … x/generic/

Problemy ustąpiły.

Jutro doinstaluję vpn-a, stworzę konfigurację identyczną z tą która sprawiała problemy i przedstawię ostateczne wnioski.

Gumis84 w tym temacie staramy się rozwikłać zagadkę dotyczącą BB
Dla problemów z Gargoyle twórz nowy temat lub przeszukaj już istniejące.

Problem jak widać znany:
https://dev.openwrt.org/ticket/16754#no1

Niestety u mnie nie rozwiązało to problemu, ale może komuś pomoże.

Oprócz liczby pakietów i bajtów różnic brak

Sytuacja wygląda następująco.
- Swój adres wan pinguje
- jakiś adres z tej samej klasy pinguje
- bramę pinguję
- 8.8.8.8 nie pinguję

Więc raczej nie jest to problem z przydziałem adresu na wanie.
Po za tym problem rozwiązuje restart firewalla, co też wyklucza nieprawidłowy przydział na wanie.

root@OpenWrt:~# ping 89.69.174.96
PING 89.69.174.96 (89.69.174.96): 56 data bytes
64 bytes from 89.69.174.96: seq=0 ttl=63 time=55.153 ms
64 bytes from 89.69.174.96: seq=1 ttl=63 time=19.114 ms
^C
--- 89.69.174.96 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 19.114/37.133/55.153 ms
root@OpenWrt:~# ping 89.69.174.93
PING 89.69.174.93 (89.69.174.93): 56 data bytes
64 bytes from 89.69.174.93: seq=0 ttl=64 time=0.337 ms
64 bytes from 89.69.174.93: seq=1 ttl=64 time=0.264 ms
^C
--- 89.69.174.93 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.264/0.300/0.337 ms
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~# ping 89.69.172.1
PING 89.69.172.1 (89.69.172.1): 56 data bytes
64 bytes from 89.69.172.1: seq=0 ttl=255 time=10.397 ms
64 bytes from 89.69.172.1: seq=1 ttl=255 time=16.289 ms
64 bytes from 89.69.172.1: seq=2 ttl=255 time=7.752 ms
^C
--- 89.69.172.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.752/11.479/16.289 ms
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

Pingi wyglądają następująco:

root@OpenWrt:~# ping google.com
ping: bad address 'google.com'

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable

root@OpenWrt:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.346 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.293 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.293/0.319/0.346 ms
root@OpenWrt:~#

Więc nie jest to problem dns-ów

Jedna różnica jaką widzę to tablica routingu.

Tak wygląda jak net działa:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89-69-172-1.dyn 0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

A tak jak nie działa:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

Widać, że format zapisu bramy jest różny.

Kolejny pad za 24 godziny, więc podpowiadajcie co jeszcze sprawdzić.