URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar

benjsing

Hallo miteinander,

ich versuche aus meinem Heimnetzwerk https://www.awsh.de zu erreichen. Im Browser schlägt dies fehl. Über mobile Daten komme ich mit dem sofort Smartphone auf die Seite, sie ist also nicht down.

Meine Versuche bisher:

pfSense => pfBlockerNG => Reports

Hier taucht die Domain nicht auf, wenn ich versuche, sie zu erreichen

dennoch awsh.de und .awsh.de profilaktisch in die Whitelist aufgenommen

kein Erfolg

direkt im Webinterface von pfsense per ping nachgeschaut => 100% packet loss

Das ist sehr komisch!! Ich habe testweise mal app-measurement.com vom Webinterface aus angepingt. Diese Domain wird per pfBlockerNG blockiert und ist von meinem lokalen PC nicht anpingbar (bzw. wird halt abgefangen) - über pfSense funktioniert es allerdings trotzdem, die tatsächliche IP wird angepingt. Das heißt, selbst wenn awsh.de von pfBlockerNG blockiert werden sollte, müsste sie über das Webinterface anpingbar sein.

isitdownrightnow.com

Siehe hier. Die Domain ist (zum Zeitpunkt als ich das hier schreibe) erreichbar.

nslookup

nslookup awsh.de (hier wird pfSense befragt)

Non-authoritative answer:
Name:   awsh.de
Address: 62.214.48.119

nslookup awsh.de 9.9.9.9 (befrage direkt einen externen Server)

Server:         9.9.9.9
Address:        9.9.9.9#53

Non-authoritative answer:
Name:   awsh.de
Address: 62.214.48.119

Also

mir liegt die korrekte IP der Seite vor (bzw. die IP, die andere DNS Server raus schicken; ich habe nicht nur den hier zitierten DNS Server getestet - und alle geben, Zeitpunkt jetzt, die o.s. IP aus)
die Domain wird (vermutlich) nicht geblockt
die unter der Domain erreichbare Seite ist mobil und anscheinend aus anderen Netzen (isitdownrightnow bsp.) erreichbar

traceroute awsh.de lädt ewig lange, gibt aber außer Ziffern und Sternchen nicht aus.

Habt Ihr eine Idee, woran das liegen könnte?

Vielen Dank im Voraus für Euren Input :)

viragomann

Hallo!

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

pfSense => pfBlockerNG => Reports

Hier taucht die Domain nicht auf, wenn ich versuche, sie zu erreichen
dennoch awsh.de und .awsh.de profilaktisch in die Whitelist aufgenommen
kein Erfolg

Ich hätte den pfBlocker zum Testen doch schon völlig deaktiviert.

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

direkt im Webinterface von pfsense per ping nachgeschaut => 100% packet loss

Ein Ping auf eine IP bringt nichts, wenn du nicht sicher weißt, dass der Server darauf antwortet. Webserver antwortet eher selten auf Pings.

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

traceroute awsh.de lädt ewig lange, gibt aber außer Ziffern und Sternchen nicht aus.

Gar nichts? Nicht mal das Internet-Gateway?
Hast du das auf der pfSense versucht? Auch mit ICMP?

Du solltest auch die Möglichkeit in Betracht ziehen, dass ein Fehler im Internet vorliegt und die IP nicht richtig geroutet wird.
Allerdings sollte dann Traceroute zumindest irgendwelche Hops preisgeben.
Das würde ich mal mit anderen IPs gegenprüfen.

Ich würde jedenfalls erstmal überprüfen, ob die Pakete richtig dein WAN-Interface verlassen. Das Paket Capture Tool von pfSense ist dafür bestens geeignet.
Mach ein Capture am WAN, gib die Ziel IP zur Filterung bei Host Address ein und starte es. Initiiere dann einen Zugriff. Das kann mit einem Webbrowser von einem internen Client sein oder du kannst auch direkt auf der pfSense das Test-Port Tool verwenden und damit Port 80 oder 443 prüfen.
Im Capture solltest du dann Pakete von deiner WAN-IP auf die Ziel-IP sehen und normalerweise auch Antwortpaket von dieser an deine WAN.

benjsing

@viragomann vielen Dank für die Antwort. Ich habe sie erst jetzt gelesen, und mittlerweile hat sich das Problem von selbst behoben (ohne, dass ich nachvollziehen kann, woran es lag).

Aber genau, traceroute hat nichts ausgegeben, außer so etwas wie (aus dem Gedächtnis, nicht kopiert)

1 * * * * * * * * * * * * * * * * * *
# nach langer Wartezeit dann
2 * * * * * ** * * * * * * * * * * *
# etc.

Wenn ich jetzt denselben Befehl ausführe, bekomme ich (in Sekundenschnelle)

traceroute to awsh.de (62.214.48.119), 64 hops max, 52 byte packets
 1  192.168.100.1 (192.168.100.1)  3.525 ms  1.083 ms  1.144 ms
 2  192.168.178.1 (192.168.178.1)  3.401 ms  1.491 ms  4.004 ms
 3  p3e9bf16f.dip0.t-ipconnect.de (62.155.241.111)  13.326 ms  13.336 ms  12.587 ms
 4  d-ed6-i.d.de.net.dtag.de (217.5.82.154)  23.744 ms

Ich hätte den pfBlocker zum Testen doch schon völlig deaktiviert.

Das scheint bei mir nicht ohne Reboot von pfSense zufällig zu funktionieren. Nehmen wir wieder app-measurement.com als Beispiel. Schalte ich pfBlockerNG aus, lade DNS Cache, starte Terminal und/oder Browser neu, und pinge / rufe die URL auf, werde ich weiterhin auf die von pfBLockerNG vergebene IP im lokalen Netz verwiesen.

Um zuverlässig zu testen, müsste ich sowohl pfSense, als auch den Client, neu starten (bzw. falls es noch einen anderen Weg gibt, habe ich diesen noch nicht gefunden). Einfach nur pfBlockerNG deaktivieren reicht nicht aus, weshalb ich das irgendwann aufgegeben habe.

Also, Problem erst mal gelöst, aber beim nächsten Auftreten weiß ich wieder nicht, woran es liegt. Ich habe momentan aber sowieso einige Routing Probleme... in den Firewall Rules habe ich festgelegt, dass aus einem bestimmten VLAN auf das andere zugegriffen werden darf (und vice versa). Die Regel habe ich zum Test in die Logs integriert, und wenn ich mir die Logs live anschaue, sehe ich, dass tatsächlich der Zugriff von VLAN A in VLAN B erlaubt wird - trotzdem öffnet das Gerät aus VLAN A nicht die aufgerufene Seite in VLAN B, obwohl pfSense gerade bestätigt hat, dass die Verbindung erlaubt wurde.

viragomann

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

traceroute to awsh.de (62.214.48.119), 64 hops max, 52 byte packets
1 192.168.100.1 (192.168.100.1) 3.525 ms 1.083 ms 1.144 ms
2 192.168.178.1 (192.168.178.1) 3.401 ms 1.491 ms 4.004 ms

Du hast also noch einen ISP-Router vor der pfSense. Also zumindest dieser sollte im Traceroute auftauchen, auch wenn nach außen hin nichts geht. Seltsam.

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

wenn ich mir die Logs live anschaue, sehe ich, dass tatsächlich der Zugriff von VLAN A in VLAN B erlaubt wird - trotzdem öffnet das Gerät aus VLAN A nicht die aufgerufene Seite in VLAN B, obwohl pfSense gerade bestätigt hat, dass die Verbindung erlaubt wurde.

Ist sichergestellt, dass das Zielgerät den Zugriff nicht blockiert. Standardmäßig erlauben netzwerkbefähigte Betriebssysteme nur den Zugriff aus dem eigenen Subnetz. Mal zum Testen die Firewall deaktivieren (im Fall von Windows ev. auch neu starten).

benjsing

@viragomann

Ist sichergestellt, dass das Zielgerät den Zugriff nicht blockiert.

Es handelt sich hierbei um eine debian VM unter Proxmox. Unter Proxmox habe ich testweise einmal das Subnetz des anderen VLAN für eingehende Verbindungen erlaubt; das hat nicht funktioniert. Zuvor waren keinerlei Firewall Einstellungen gesetzt. Allerdings befinden sich meine Clients in noch einem anderen VLAN mit anderem Subnetz, und diese können (und konnten) den Server auch erreichen, ohne dass entsprechende Einstellungen gesetzt waren.

VLAN

10.10.10.0/24 => VIP auf IOT => geht
192.168.100.0/24 => IOT auf IOT => geht (klar)
192.168.80.0/24 => REST auf IOT => geht nicht

Dabei habe ich unter Firewall Rules REST NET den Zugriff auf IOT NET erlaubt (Testweise auch per Alias nur den tatsächlich erwünschten Geräten aus REST Zugriff auf nur die benötigten Ports auf das betroffene Gerät im IOT). Laut pfSense gehen die Verbindungen durch, es passiert jedoch nichts.

Meine aktuelle Lösung ist hierfür, das REST VLAN aufzulösen. Dort befinden sich nach langer Überzeugungsarbeit sowieso keine Windows Rechner mehr, also verlagere ich die Geräte einfach erst mal ins IOT VLAN, sodass sie zumindest regulär auf sämtliches Services zugreifen können, auf die sie Zugriff haben sollen ;)

viragomann

@benjsing said in URL nicht erreichbar (scheint allerdings nicht geblockt), via mobilen Daten verfügbar:

Laut pfSense gehen die Verbindungen durch, es passiert jedoch nichts.

Laut Firewall Logs oder laut Packet Capture? Ich würde letzteres verwenden, um sicherzustellen, dass die Pakete am REST Interface rausgehen und wenn, um sehen, ob da auch eine Antwort kommt.
Falls Pakete rausgehen, aber keine Antwort zurückkommt, sollte es am Zielgerät liegen. Eventuell kannst du aber auch auf der pfSense den ausgehenden Traffic auf die Interface IP natten, das sollte Firewalls der Zielgeräte oder Routing-Probleme dieser umgehen.

JeGr

@viragomann Wenn die erste Antwort bzw. der erste Hop von Traceroute schon * * * zurückgegeben hatte, dann stimmte zu dem Zeitpunkt was mit dem Routing nicht wirklich. Wäre dann eher interessant gewesen, was beim traceroute blubb dann tatsächlich der volle Output war. Wäre es pfBNG gewesen, dann hätte die Auflösung von awsh.de schon 0.0.0.0 oder 127.1.1.7 ergeben und wäre ins "nichts" gelaufen. Wenn die aber sauber zur IP aufgelöst wurde und der Trace dann nicht ging, dann war das kein pfSense, sondern eine Routing/Proxmox Problem.