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
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
-
@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?
-
@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...
-
@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?
-
@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.
-
@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 -
Hallo Zusammen,
da die Sache nun geklärt ist, möchte ich die Lösung hier erwähnen.
nach dem wir sämtliche Paketgrößeneinstellungen und Routings und Firmware und und und gecheckt, erneuert, ausgetauscht haben, hat sich der Fehler nicht beheben lassen.
Eine anfängliche Vermutung, durch google blockiert zu sein, ließ sich mit einem VPN-Test quasi bestätigen. Dazu habe ich über eine komerzielle VPN Verbindung eine Suche ausgeführt, die tatsächlich funktionierte.
Mit hilfe unseres DSL-Providers haben wir dann das IP-Subnetz gewechselt, so dass wir nun neue IPs haben. Der Fehler ist behoben und alle können nun wieder google besurfen.
Warum wurden wir gesperrt? Dazu gibt es seitens Google keinen Ansprechpartner und keine Aussage. Dass wir unverhältnismäßigen traffic auf google verursachen, das ist nicht der Fall. Die ein und ausgehenden requests sind eindeutig. Teilweise wurden PCs auf bekannte Viren und Bots durchsucht. Nichts auffälliges.
Eine Vermutung ist, dass Google einen bestimmten IP-Bereich sperrt, worunter wir dann auch gefallen sind. Hätten wir eine dnamische IP, so wäre das Phänomen einfach von alleine, beim nächsten IP-Wechsel, verschwunden.
Ich hoffe, das bringt noch weitere betrfoffene weiter...
Viele Grüße
reco -
@reco Danke für den kurzen Recap selbst nach 4 Monaten! Sehr anständig und bringt alle weiter - vor allem da wir so festhalten konnten, dass es tatsächlich nicht die pfSense war an der Stelle.
Besten Dank!
-
@reco said in Google Suchergebnissseite wirft immer eine 403 - aus dem gesamten Netz.:
Eine Vermutung ist, dass Google einen bestimmten IP-Bereich sperrt, worunter wir dann auch gefallen sind.
Wäre auch meine Vermutung. Ist übliche Praxis, dass die Betreiber den gesamten IP-Bereich eines Übeltäters auf die Blacklist setzten, mach ich selbst auch so.
Der Unschuldige, der da mit reinfällt, hat eben Pech.Doch normalerweise werden solche Einträge nach einiger Zeit wieder automatisch von der Blacklist gelöscht.
-
Wobei für die allgemeine google-Suche? Als Viel-VPN-Nutzer kann ich sagen, dass man mit Captchas überzogen wird etc, aber 403 finde ich immer noch extrem merkwürdig, gerade von google.
