1
Webinterface - mal geht http, mal geht nur https (pfsene mit squid)
Hallo,
mir ist heute was seltsames aufgefallen und ich kenne den Grund dafür nicht bzw. würde gerne verstehen, warum das so ist...
Also ich habe bei mir eine pfsense (mit squid als transparent proxy, kein squidguard). Davor hängt eine Fritzbox 7490 (WAN), welche die Interneteinwahl regelt. Alle Clients hängen aber im Netz hinter der pfsense.
Dann hab ich im pfsense Netz noch eine Fritzbox 7490, welche nur für WLAN zuständig ist.
Bei beiden Fritzboxen, also die im WAN und die im lokalen Netz komme ich mittels der jeweiligen IP http://192.168.xxx.xxx aufs Webinterface. Also nur mit http --- ohne s.
Dann hab ich von der pfsene noch einen IPsec-VPN-Tunnel zu einer entfernten Fritzbox 7490. Diese kann ich anpingen. In deren Netz ist auch eine Synology, auch Netzwerkzugriff auf die Freigaben darauf funktionieren.
Jedoch was mich hier irritiert: Ich komme mit http nicht aufs Webinterface. Es kommt nach einiger Wartezeit folgende Meldung im Browser:
Verbindung zu 192.168.xxx.1 Fehlgeschlagen.
Das System antwortete: (65) No route to host
Das ist eine Meldung von meinem squid auf der pfsense.
Mit https komme ich sowohl auf die Fritzbox, als auch auf die Synology.
Wenn ich den squid auf der pfsense deaktiviere, dann komme ich auch wieder per http auf die entfernten Geräte.
Woran liegt das? Welche Einstellung ist hierfür verantwortlich? Warum geht http intern und nach WAN, jedoch nicht über ipsec?
mir ist heute was seltsames aufgefallen und ich kenne den Grund dafür nicht bzw. würde gerne verstehen, warum das so ist...
Also ich habe bei mir eine pfsense (mit squid als transparent proxy, kein squidguard). Davor hängt eine Fritzbox 7490 (WAN), welche die Interneteinwahl regelt. Alle Clients hängen aber im Netz hinter der pfsense.
Dann hab ich im pfsense Netz noch eine Fritzbox 7490, welche nur für WLAN zuständig ist.
Bei beiden Fritzboxen, also die im WAN und die im lokalen Netz komme ich mittels der jeweiligen IP http://192.168.xxx.xxx aufs Webinterface. Also nur mit http --- ohne s.
Dann hab ich von der pfsene noch einen IPsec-VPN-Tunnel zu einer entfernten Fritzbox 7490. Diese kann ich anpingen. In deren Netz ist auch eine Synology, auch Netzwerkzugriff auf die Freigaben darauf funktionieren.
Jedoch was mich hier irritiert: Ich komme mit http nicht aufs Webinterface. Es kommt nach einiger Wartezeit folgende Meldung im Browser:
Verbindung zu 192.168.xxx.1 Fehlgeschlagen.
Das System antwortete: (65) No route to host
Das ist eine Meldung von meinem squid auf der pfsense.
Mit https komme ich sowohl auf die Fritzbox, als auch auf die Synology.
Wenn ich den squid auf der pfsense deaktiviere, dann komme ich auch wieder per http auf die entfernten Geräte.
Woran liegt das? Welche Einstellung ist hierfür verantwortlich? Warum geht http intern und nach WAN, jedoch nicht über ipsec?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 519534
Url: https://administrator.de/contentid/519534
Printed on: April 26, 2024 at 21:04 o'clock
1 Comment
Jedoch was mich hier irritiert: Ich komme mit http nicht aufs Webinterface.
Nur nochmal doof nachgefragt da das nicht wirklich klar ist:Du kommst nicht per HTTP auf das Webinterface der remoten Synology, richtig ? HTTPS geht aber, auch richtig ?
Wenn dem so ist hast du quergecheckt im remoten Netz wenn du dort lokal auf die Synology per HTTP zugreifst das das geht ?? Nur um sicherzustellen das HTTP Zugriff auf der Synology nicht generell deaktiviert ist !
Wenn das soweit OK ist gibt es nur 2 Gründe warum das fehlschlägt:
- 1.) Der Squid ist falsch oder fehlerhaft konfiguriert was den TCP 80 Traffic (HTTP) anbetrifft.
- 2.) Die Firewall Regel im pfSense IPsec VPN Tunnel blockt TCP 80 Traffic
Leider kann man das nur im freien Fall raten da die Details zu deisen Settings hier fehelne aber das sind die 2 Punkte wo du genauer hinsehen solltest. Ggf. immer die Paket Sniffer Diagnostic der pfSense nutzen und nachsehen wo die TCP 80 Pakete genau bleiben. Ebenso das Firewall Log daraufhin checken !