Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.


  • Hallo liebe Forumsmitglieder,

    nach meiner erfolglosen Suche im Forum möchte ich mein Problem schildern, in der Hoffnung, dass der eine oder andere doch einen Tipp hat.

    In unserem Netzwerk sind wir auf Fehlersuche, was die Google-Suchen betrifft.

    Das Problem:

    • Google-Suchergebnisseiten können nicht aufgerufen werden. Es wird immer eine 403 Fehlerseite abgeworfen, die aussieht wie im Anhang
    • Das Problem ist eines Nachmittags aufgetreten (keine Änderungen zu dem Zeitpunkt im Netzwerksetup) und existiert seit nun 10 Tagen)
    • Die Fehlerseite kommt von Google, somit vermute ich den Fehler nicht im DNS
    • Das Phänomen tritt bei allen Rechnern im Netzwerk auf, egal ob Windows, MacOS oder mobiles Endgerät.
    • Es betrifft alle Geräte im LAN und im Wlan-
    • Es betrifft nur die Google-Suchergebnisseite. Sonstige Dienste von Google funktionieren. Auch die Suchseite kann aufgerufen werden und die Suchleiste im Browser und auf der Google-Suchseite liefern Autokorrekturvorschläge. Nach dem Absenden kommt 403.
    • Irgendwelche Tipps mit Cache-leeren etc. bringt nicht viel, da das Problem auch verteilt auftritt.

    Gemacht um das Problem einzugrenzen:

    • DSL-Provder Plusnet hat aus unserem Subnetz einen Aufruftest gemacht und gemeldet, dass sie auf die Suchergebnisse zugreifen können und somit eine IP-Sperre seitens Google ausgeschlossen ist.
    • Endgeräte können die Suche ausführen, wenn diese z.B. mit einen Smartphone-Hotspot über ein anderes Netz gehen.
    • PFSense auf ein Backup zurückgesetzt, welches vom Datum her funktionierte.
    • Alle Gatewayeinstellungen durchgeprüft, ggf. MTU angepasst.
    • pfBlockerNG deinstalliert... (nun wieder installiert)
    • sekundäre Gateways daktiviert um irgendwelche routing-Themen auszuschließen.
    • Natürlich Modem und Router neugestartet.

    Diese Maßnahmen brachten bisher nicht ausser das Thema

    Hinweise zum Setup

    • PFSene wurde eine Woche zuvor auf die aktuellste Version geupgradet. Aber eine Woche lang gab es keine Auffälligkeiten.
    • Provider ist die PlusNet, eigentlich auch im Support bisher nur gute Erfahrungen gemacht
    • Wir haben mehrere Vlans, aus welchem VLAN man den G-Riesen besurft, spielt keine Rolle.
    • An NAT Regeln hat sich nicht verändert.

    Vermutung:

    • Sehr wage vermute ich, dass im Routing etwas dazu führt, dass Google die Packete für korrupt hält

    Heute habe ich auch mal im Google Groups gepostet, falls von Interesse. Aber da kam bis auf einen Hinweis, dass das jemand vor 6 Tagen auch gepostet hat, bisher nichts, was weiter bringt.

    Da ich nicht weiß welche "Unterlagen" hier hilfreich sind, habe ich erstmal nichts angehängt. Gerne versuche ich aber bei Interesse und Bedarf kurzfristig nachzuliefern.

    Gibt es Erfahrungen zu diesem Thema oder Vermutungen, woran dies liegen könnte?

    Viele Grüße und einen schönen Sonntag wünscht,
    Reco

    Screenshot 2020-12-13 at 13.00.15.png

    Hier noch ein Trace von einem Aufruf:

    13:47:24.672711 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 359: (tos 0x0, ttl 128, id 33897, offset 0, flags [DF], proto TCP (6), length 345)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [P.], cksum 0x50a6 (correct), seq 2108537651:2108537956, ack 1260583171, win 1027, length 305
    13:47:24.685879 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 121, id 16391, offset 0, flags [none], proto TCP (6), length 40, bad cksum 0 (->45e0)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [.], cksum 0x75d3 (correct), seq 1, ack 305, win 282, length 0
    13:47:25.081287 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 122: (tos 0x0, ttl 121, id 16597, offset 0, flags [none], proto TCP (6), length 108, bad cksum 0 (->44ce)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0x5cb7 (correct), seq 1:69, ack 305, win 282, length 68
    13:47:25.081330 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 1474: (tos 0x0, ttl 121, id 16598, offset 0, flags [+], proto TCP (6), length 1460, bad cksum 0 (->1f85)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], seq 69:1489, ack 305, win 282, length 1420
    13:47:25.081337 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 121, id 16598, offset 1440, flags [none], proto TCP (6), length 30, bad cksum 0 (->4467)!)
    216.58.205.227 > 192.168.85.34: ip-proto-6
    13:47:25.081363 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 585: (tos 0x0, ttl 121, id 16599, offset 0, flags [none], proto TCP (6), length 571, bad cksum 0 (->42fd)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0x3f0c (correct), seq 1499:2030, ack 305, win 282, length 531
    13:47:25.081390 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 121, id 16600, offset 0, flags [none], proto TCP (6), length 71, bad cksum 0 (->44f0)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0xb838 (correct), seq 2030:2061, ack 305, win 282, length 31
    13:47:25.081414 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 121, id 16601, offset 0, flags [none], proto TCP (6), length 79, bad cksum 0 (->44e7)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0x5125 (correct), seq 2061:2100, ack 305, win 282, length 39
    13:47:25.081999 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 33898, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [.], cksum 0x6d10 (correct), seq 305, ack 1499, win 1027, length 0
    13:47:25.082113 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 33899, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [.], cksum 0x6ab9 (correct), seq 305, ack 2100, win 1025, length 0
    13:47:25.082453 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 128, id 33900, offset 0, flags [DF], proto TCP (6), length 79)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [P.], cksum 0x4815 (correct), seq 305:344, ack 2100, win 1025, length 39
    13:47:25.088921 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 121, id 16604, offset 0, flags [none], proto TCP (6), length 40, bad cksum 0 (->450b)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [.], cksum 0x6d79 (correct), seq 2100, ack 344, win 282, length 0
    13:47:25.168341 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 128, id 33901, offset 0, flags [DF], proto TCP (6), length 112)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [P.], cksum 0x3d3a (correct), seq 344:416, ack 2100, win 1025, length 72
    13:47:25.170409 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 128, id 33902, offset 0, flags [DF], proto TCP (6), length 75)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [P.], cksum 0x5355 (correct), seq 416:451, ack 2100, win 1025, length 35
    13:47:25.175468 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 121, id 16656, offset 0, flags [none], proto TCP (6), length 40, bad cksum 0 (->44d7)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [.], cksum 0x6d31 (correct), seq 2100, ack 416, win 282, length 0
    13:47:25.175504 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 121, id 16657, offset 0, flags [none], proto TCP (6), length 116, bad cksum 0 (->448a)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0x407e (correct), seq 2100:2176, ack 416, win 282, length 76
    13:47:25.175536 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 1474: (tos 0x0, ttl 121, id 16658, offset 0, flags [+], proto TCP (6), length 1460, bad cksum 0 (->1f49)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], seq 2176:3596, ack 416, win 282, length 1420
    13:47:25.175542 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 121, id 16658, offset 1440, flags [none], proto TCP (6), length 30, bad cksum 0 (->442b)!)
    216.58.205.227 > 192.168.85.34: ip-proto-6
    13:47:25.175567 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 171: (tos 0x0, ttl 121, id 16659, offset 0, flags [none], proto TCP (6), length 157, bad cksum 0 (->445f)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0xa9da (correct), seq 3606:3723, ack 416, win 282, length 117
    13:47:25.175590 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 121, id 16660, offset 0, flags [none], proto TCP (6), length 79, bad cksum 0 (->44ac)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [P.], cksum 0xdce2 (correct), seq 3723:3762, ack 416, win 282, length 39
    13:47:25.175917 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 33903, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [.], cksum 0x6443 (correct), seq 451, ack 3606, win 1027, length 0
    13:47:25.176081 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 33904, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [.], cksum 0x63a7 (correct), seq 451, ack 3762, win 1027, length 0
    13:47:25.176098 80:ee:73:cb:33:31 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 128, id 33905, offset 0, flags [DF], proto TCP (6), length 79)
    192.168.85.34.64778 > 216.58.205.227.443: Flags [P.], cksum 0xfc77 (correct), seq 451:490, ack 3762, win 1027, length 39
    13:47:25.183440 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 121, id 16663, offset 0, flags [none], proto TCP (6), length 40, bad cksum 0 (->44d0)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [.], cksum 0x6690 (correct), seq 3762, ack 451, win 282, length 0
    13:47:25.183476 00:0d:b9:44:d4:a0 > 80:ee:73:cb:33:31, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 121, id 16664, offset 0, flags [none], proto TCP (6), length 40, bad cksum 0 (->44cf)!)
    216.58.205.227.443 > 192.168.85.34.64778: Flags [.], cksum 0x6669 (correct), seq 3762, ack 490, win 282, length 0

  • LAYER 8 Moderator

    @reco Ahoi,

    403 heißt ja klar "Forbidden". Das wird von Google normalerweise nur ausgespielt, wenn man aus irgendeinem Grund geblockt wird. Nochmal zum Verständnis:

    Wann genau kommt denn die 403 Seite?

    • Geht die Google Suchseite auf? -> https://www.google.de
    • Suchebegriff absenden?
    • Klick auf eines der Resultate der Suche?

    Das war mir beim Durchlesen noch nicht so ganz klar.

    Dann zusätzlich: hast du die Möglichkeit, dass du auf einem Client ein VPN installierst/nutzt? Also ggf. irgendeine freie Variante vllt. von ProtonVPN o.ä.? Muss kein anderes Land sein, am besten gleiches Land wie du selbst bist und dann nochmal testen?

    Ich würde nämlich eher mutmaßen, dass dein Problem auf Grund eines IP-Shadowbans passiert und nicht weil mit der pfSense irgendwas falsch läuft. Ansonsten: welche DNS Server werden genutzt (nicht nur auf der Sense, sondern für die Clients)?

    Cheers
    \jens


  • @jegr Danke für die Einschätzung. Ich habe bei Google auch schon das Formular bzgl. der IP zwei mal ausgefüllt und abgesendet. Mal schauen ob das zu überhaupt irgendetwas führt.

    VPN teste ich nochmal. Hatte mich zwar auf die Plusnet Aussage verlassen aber ganz Wohl ist mir da auch nicht.

    Zu der Frage, wann es kommt:

    • www.google.de (geht)
    • Suchbegriff eingeben (geht - auch Autocomplete macht Vorschläge)
    • Enter -> 403 statt Ergebnissseite

    Melde mich gleich nach dem VPN Test.


  • @jegr Mit einer vpn ip aus Deutschland (btw. kostenfrei über protonVPN) läufts. Also scheint die naheliegendste Vermutung von ganz Anfang doch richtig zu sein. Zumindest für jetzt.

    Im Plusnet-Support öffne ich mal wieder das Ticket und frag mal nach, wie genau die das getestet haben... das ist schon ärgerlich.

    Hat jemand Erfahrung mit so einem Ban? Wie erreicht man wieder die Entsperrung, falls es wirklich einer ist?

  • LAYER 8 Moderator

    @reco OK also direkt NACH dem ersten Submit. Das würde für die ShadowBan Theorie sprechen, dann geht die Startseite/Suchseite nämlich oft noch, danach wird aber 403 geblockt. Wäre also durchaus eine Möglichkeit, auch wenn man dazu normalerweise einiges an API/Anfragen an Google raushauen muss bevor die eine IP oder eine Range blocken. Aber es klingt schon danach, als wäre es eine Entscheidung auf Grund von Kriterien wie IP und/oder UserAgent o.ä.

    Da die Firewall außer Block/Pass - ohne IDS und Kram - ansonsten da eigentlich nichts weiter tut, würde ich schon vermuten, dass der Faktor von außen kommt. Wie IP oder DNS bspw. Ansonsten wäre das schon äußert merkwürdig.

    Es gibt (aber auch) Extensions und DNS Möglichkeiten (u.a. auch im pfBlocker!), die on the fly versuchen, die Google Suche/Requests umzuschreiben bspw. auf Safe-Search um als Kindersicherung o.ä. zu agieren. Eventuell auch das ggf. mal untersuchen, da könnte auch Browser oder DNS mit im Spiel sein. Wobei Browser bei der Breite an Geräten eher unwahrscheinlich ist. Und da du meintest "trat auch ohne pfBlocker auf", müsste da schon was anderes vor deiner Sense sitzen, die DNS Queries umschreibt. Wäre merkwürdig.

    DNS macht die Sense selbst? Mit DNS Resolver? Forwarding aktiv oder Resolving Mode?
    Wenn Forwarding genutzt wird, mal absichtlich auf Resolver umschalten, damit DNS anders abgefragt wird.

    Gruß


  • @jegr Ja DNS, macht die PFSense. Da ich noch einen zweiten im Netz habe, habe ich zur sicherheit dem Testclient mal manuell alles eingetragen und sämtliche DNS Caches geleert.

    Browser schließe ich aus, da ich das tatsächlich mit allen möglichen Geräten und Browsern getetest habe.

    Kinderschutz u.ä. und blockaden über die DNS habe ich keine (die ich kenne).

    Nutze den DNS Resolver, mit einigen eigenen Einträgen.

    Im Client sieht der DNS-Eintrag so aus:
    DNS-Server . . . . . . . . . . . : 192.168.85.30
    8.8.8.8

    @JeGr Dank nochmals. Ich hatte im ersten Post ein Packettrace gepostet. Da sind einige bad cksum s drin. Ist das normal? In dem Detail bin ich ein totaler Fremder...

  • LAYER 8 Moderator

    @reco OK also erster DNS lokal die Sense, zweiter ist Google selbst. Sollte damit erst recht eigentlich keine Probleme haben.

    Die Bad Chksums sind meistens von der Netzwerkhardware schlechte/falsche Prüfsummen bzlg. Hardware Offloading. Kann man unter System/Adv. unter Netzwerk abschalten, default sind schon 2/3 Offloads aus, das dritte kann/sollte man auch ausmachen. Die NIC Treiber/HW ist da nie wirklich gut mit warm geworden. Es macht aber keinen Fehler oder ist kein Problem.

    Hast dus zwischenzeitlich mal mit VPN probiert, ob es dann auch auftritt`?


  • Ja, der VPN Test war positiv.

    @reco said in Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.:

    @jegr Mit einer vpn ip aus Deutschland (btw. kostenfrei über protonVPN) läufts. Also scheint die naheliegendste Vermutung von ganz Anfang doch richtig zu sein. Zumindest für jetzt.

    Im Plusnet-Support öffne ich mal wieder das Ticket und frag mal nach, wie genau die das getestet haben... das ist schon ärgerlich.

    Hat jemand Erfahrung mit so einem Ban? Wie erreicht man wieder die Entsperrung, falls es wirklich einer ist?

  • LAYER 8 Moderator

    @reco Das heißt was genau? 🤔


  • @jegr ja, mit einer VPN Verbindung ist eine Google Suche ausführbar. Sprich, es kommt dann keine 403. Dabei hatte ich auf einem Client im Netzwerk einen VPN-Client eingerichtet, der über einen Server in Deutschland raus ging.

    Der Google-Support hat gemeldet, dass sie keinen Support leisten 😲 und verwies auf die User-Groups. Dort melden aber Nutzer nur, dass man den Fehler bei sich suchen soll 🤒

    Plusnet, unser Provider, schaut auch nochmal, ob das ggf. im gesamten Subnetz ist.

    Mal sehen, was rauskommt. Momentan behelfen wir uns mit startpage.com, duckduckgo, bing und co. Aber so eine richtige Alternative ist das ganze nicht.


  • @reco said in Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.:

    Momentan behelfen wir uns mit startpage.com, duckduckgo, bing und co. Aber so eine richtige Alternative ist das ganze nicht.

    Mache das selbe, da ich einen VPN-Anbieter nutze und google sowas offensichtlich nicht duldet und stets und ständig mit captchas nervt.

  • LAYER 8 Moderator

    @reco said in Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.:

    Mal sehen, was rauskommt. Momentan behelfen wir uns mit startpage.com, duckduckgo, bing und co. Aber so eine richtige Alternative ist das ganze nicht.

    DuckDuckGo finde ich ja ansonsten eh die sinnvollere Alternative. Ja die Suche mag im ersten Moment nicht ganz so ergiebig sein, aber man findet seinen Kram schon auch nur ohne Google Tracking :)

    Trotzdem ist das dann natürlich ein Problem ggf. eures Providers und das sollte er mal dringend untersuchen. Denn das VPN belegt dann ja eindeutig, dass es vom gleichen Client mit anderer IP funktioniert.


  • @reco said in Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.:

    Mal sehen, was rauskommt. Momentan behelfen wir uns mit startpage.com, duckduckgo, bing und co. Aber so eine richtige Alternative ist das ganze nicht.

    Startpage.com verwendet doch die Google Suche. Sollte also dieselben Ergebnisse liefern, abgesehen von gewissen Personalisierungen. Aber mag natürlich sein, dass das manchen Leuten dann fehlt. 😉


  • ich nutze schon seit einiger Zeit https://www.ecosia.org
    und bin sehr zufrieden