Veröffentlicht 23. August 20214 j Guten Tag liebe Community, zu Ăbungszwecken habe ich mir ein kleines virtuelles Debian Netzwerk gebaut. Die Firewall(UFW) auf dem Gateway(GW-01) macht mir nun Probleme ... Ich möchte von dem Client WS-01 ĂŒber einen Browser im Internet surfen, habe dazu die Ports 80 & 443 freigegeben, leider bringt das nichts, der Browser lĂ€dt die Seite nicht. Die Verbindungen funktionieren alle einwandfrei, sobald ich die UFW ausschalte, lĂ€uft alles wunderbar... ZusĂ€tzlich habe ich auch den Port 22 fĂŒr SSH freigegeben, was auch problemlos funktioniert. Die Firewall neu installiert und konfiguriert habe ich auch schon, Ă€ndert leider nichts am Problem. Hat jemand von euch eine Idee was das Problem sein könnte bzw. was ich falsch mache ? MfG FiSi_2021 Â
23. August 20214 j Wie ist die DNS-Auflösung eingerichtet? Stellt die UFW auch einen DNS-Server bereit und wenn ja ist WS-01 so eingerichtet, dass auch die 192.168.0.126 als DNS-Server verwendet wird? Oder stellt die UFW keinen DNS-Server bereit? In diesem Fall mĂŒsste dementsprechend nicht nur HTTP und HTTPS, sondern auch DNS in Richtung Internet erlaubt werden und WS-01 mĂŒsste dementsprechend einen oder mehrere DNS-Server im Internet nach der Namensauflösung befragen.
23. August 20214 j Autor Moin Moin, also das gw-01 stellt einen caching only dns bereit und ja, ist so eingerichtet das ws-01 den ĂŒber die 192.168.0.126 erreicht. Die UFW selbst stellt keinen DNS bereit ... Alles klar, dann muss ich also noch port 53 freigeben, schande ĂŒber mein haupt das ich da nicht selbst drauf gekommen bin đ„Ž Vielen Dank fĂŒr die Hilfe ! LG aus dem Hamburger Westen âïž
24. August 20214 j Nur mal so als Anregung. Port 22, 80 und 443 ist von ĂŒberall her erlaubt? Wieso? Das solltest du auf die beiden Netze, bzw. das zusammengefasste Netz 192.168.0.0/24 beschrĂ€nken, sonst funktioniert das aus Internetrichtung genauso und die Firewall ist sinnlos. ZurĂŒck kommt es ja nicht auf diesen "well known ports", sondern auf dynamischen "high ports" ab Port 1024. Davon abgesehen sollte die RĂŒckverbindung automatisch erlaubt werden von der Firewall. Also entweder gibst du Interface oder IP-Ranges an. Anywhere sollte möglichst nicht verwendet werden.
24. August 20214 j Autor Ok , danke fĂŒr die Infos ! Woher weiss ich denn auf welchen dynamischen Ports die RĂŒckmeldung kommt, welche Range ist die richtige ? Â Â
24. August 20214 j Autor Mal abgesehen davon ob diese Konfiguration jetzt sinnvoll ist oder nicht, eine Verbindung von ws-01 auf eine Website bekomme ich trotzdem nicht. Nameserver sind eingetragen. Sobald die firewall auf disable ist, lĂ€uft ja alles .... hmmmmmmmm đ  Â
24. August 20214 j Ich kenne UFW nicht, deswegen kann ich nur Hinweise geben, woran es liegen könnte. Kann WS-01 DNS-Namen auflösen, wenn UFW aktiviert ist, oder scheitert es schon daran? Kann GW-01 DNS-Namen auflösen, wenn UFW aktiviert ist? Muss vielleicht noch DNS ausgehend von GW-01 in Richtung Internet freigegeben werden, weil UFW eben auf GW-01 installiert ist und deswegen sowohl ein- als auch ausgehenden Verkehr kontrolliert? Was passiert, wenn Du Ping erlaubst? Kann aus dem internen Netzwerk die 192.168.0.126 angepingt werden, wenn UFW aktiv ist? Falls ja, kann z.B. die 8.8.8.8 (google DNS) angepingt werden? Falls ja, kann www.heise.de angepingt werden?
24. August 20214 j Autor WS-01 und GW-01 können Namen auflösen wenn UFW aktiv ist ! Ping aus dem internen Netzwerk funktioniert auch auf alle internen Maschinen, sowie auch nach draussen zu Google, Heise ....
24. August 20214 j Was geben denn die Logs her? Ggf vorher dass was geloggt werden soll prĂŒfen, im Zweifel debug. Wireshark wĂ€re auch Mal angebracht. Vor und hinter der FW sollte schnell zeigen ob /was gar nicht durchgeht. Im Zweifel muss man dann nochmal genauer schauen.Â
24. August 20214 j Autor So sehen die Logs aus. die zu prĂŒfen bzw debug, geht leider etwas ĂŒber meinen jetzigen wissensstand hinaus ... Â
24. August 20214 j Autor vor 3 Stunden schrieb FiSi_2021: So sehen die Logs aus. die zu prĂŒfen bzw debug, geht leider etwas ĂŒber meinen jetzigen wissensstand hinaus ...  Sollte mich wohl lieber "angehenderFiSi_2021" nennen oder FutureFiSi was einem halt direkt auffĂ€lt , [UFW BLOCK] in enp0s8 out enp0s3 muss ich eventuell nochmal extra ip_forwarding fĂŒr die firewall konfigurieren ? habe das ja eigentlich schon aktiviert und die pings hauen ja auch hin ... sorry fĂŒr den SPAM, mich lassen solche sachen bloĂ unruhig schlafen xD
24. August 20214 j Eigentlich ist das eine super Ăbung die du da hast. Dein Ziel sollte es sein erstmal das drumherum wirklich zu verstehen anstatt einfach nur deinen Aufruf erfolgreich durchzufĂŒhren. Alleine die Logmeldung auseinander zu friemeln und wirklich zu verstehen was jeder einzelne Wert ĂŒberhaupt darstellt bzw. bedeutet erzeugt einen groĂen Lernerfolg. Und dann solltest du auch einschĂ€tzen können ob das was da geblockt wird, wirklich der Grund fĂŒr dein Problem sein könnte oder nicht.
24. August 20214 j Lösung So gesehen ist ufw auch "nur" ein Frontend fĂŒr iptables Ich denke auch, forwarding ist hier das Stichwort, mit dem man sich noch ein wenig nĂ€her befassen sollte. Zum Thema PING: Das dĂŒrfte funktionieren, weil es bei ufw eine Sammlung von sog. "before rules" gibt. Die solltest du hier finden: /etc/ufw/before.rules Da steht u.a. drin: # ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT # ok icmp code for FORWARD -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT (zumindest bei mir, aber Mint und Debian sind ja recht nah beieinander) Diese rules (sofern vorhanden, wovon ich bei dir aber ausgehe) greifen vor sĂ€mtlichen manuell konfigurierten EintrĂ€gen. Hier sollten ĂŒbrigens auch schon die wichtigen "related / established"-Regeln drin stehen, die spĂ€ter fĂŒr einen sauberen RĂŒckweg von Paketen sorgen: # quickly process packets for which we already have a connection -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT Â
25. August 20214 j Autor Ok, verstehe ... Ja die "before rules" sind bei mir (Debian) identisch, die "related established" ebenso, danke fĂŒr den Hinweis ! Werde das alles nochmal in Ruhe durchgehen. Â Â
25. August 20214 j Autor UPDATE ! Nun funktioniert es endlich ! unter  /etc/default/ufw  musste der forwarding parameter auf "accept" gesetzt werden. Grossen Dank an euch alle, mit euren Denkanstössen ans Ziel gekommen â€ïž Â
26. August 20214 j zum Aufbau der Logs am Beispiel der ersten kompletten Zeile: Aug 24 => Datum 15:29:10 => Uhrzeit GW-01 => Hostname der Firewall Kernel: [22061.253173] => Kernelzeit seit Boot [UFW BLOCK] => durchgefĂŒhrte Aktion (Blockiert) IN=enp0s8 => Eingehendes Interface OUT=enp0s8 => ausgehendes Interface MAC=08:00:... => MAC Address Codes fĂŒr das Ziel SRC=192.168.0.1 => Quell-IP-Adresse DST=217.145.98.135 => Ziel-Adresse LEN=66 => LĂ€nge des PAyloads TOS=0x10 => Type of Service (keine Priorisierung bei 0x10) PREC=0x00 => Precedence (auch so ein PrioritĂ€ten Feld, hier keine Priorisierung) TTL=63 => Time to live noch 63 hops ID=1511 => Identificationsnummer des Paketes DF => keine Ahnung Proto=UDP => UDP Protokoll SPT=35924 => Source Port DPT=123 => Destination Port => Network Time Protocol (NTP) well known ports LEN=56 => LĂ€nge des Pakets (hier könnte auch WINDOW stehen, dann wĂ€re es die Window Size)
29. August 20214 j Du hast Input Rules erstellt, musst aber Forwarding Rules erstellen. Quasi "ufw route allow 80" usw.
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.