IPv4 mit RED Verbindung Sophos UTM -> Sophos UTM

  • Hallo zusammen,


    steinigt mich nicht, aber das ist heute mein erster Eintrag.


    Ich habe bereits sehr stark das Thema zu IPv6 und IPv4 bei DG nachverfolgt. Leider habe auch ich das Problem, dass ich eine statische IPv4 benötige.

    Dazu habe ich bereits folgende Beiträge mir angeschaut und gefunden:

    - DynDNS nach Wechsel zu DG

    -> Die Lösung von Alfy gefällt mir dabei sehr gut


    - https://benjaminradan.de/oeffe…ipv4-adresse-trotz-cgnat/

    -> Habe ich als Möglichkeit versucht umzusetzen, bin jedoch gescheitert


    - https://www.busche.org/index.p…zur-sophos-utm-ueber-red/

    -> Ist meine bevorzugte Weise, da ich dann das NAT vernachlässigen kann und nur an einer Stelle zentral eine Einstellung für eine Freigabe treffen muss anstatt an zweien


    Leider hat bei mir bisher keine der Möglichkeiten funktioniert. Mal ist es an der Firewall gescheitert (trotz aktiver Einstellung und Erlauben von Any-Any-Any) , mal am RED Tunnel (down, up und keine Verbindung etc.), mal an einem "Error", der in keinem Log angezeigt wird.


    -------

    Folgendes Setup ist vorhanden:

    *netcup*

    - VPS200 - darauf eine Sophos UTM 9 installiert

    - VLAN dazu gebucht

    - 2. IP Adresse


    *Privat*

    - Virtuelle Sophos UTM 9

    -------

    Hat eventuell jemand ein ähnliches/gleiches Setup und kann mir da Unterstützung geben? (Gerne auch per Whatsapp/telefonat oder ähnlichem mit der Lösung dann hier im Forum)


    Sobald das alles bei mir läuft, würde ich mich auch dazu bereit erklären, ein kleines HowTo zu schreiben und hier im Forum zu veröffentlichen.


    Gruß

    Patrick

  • Die eine Anleitung (Busche) ist einigermaßen oberflächlich, da bleiben ein paar Details verborgen. Da besteht ein gewisses Risiko, dass man das falsch macht.


    Zur Erklärung: Ich nutze die Sophos nicht. Ich hab auch keine zweite öffentliche IP, die ich mir "nach Hause tunnele", dafür hab ich keine sinnvollen Anwendungsfälle. Ich greife lediglich über meine öffentliche IPv4 auf einem Netzcup Server auf ausgewählte Dienste zu Hause zu, das ganze wird inzwischen über einen Wireguard Tunnel realisiert (früher OpenVPN).


    -> Ist meine bevorzugte Weise, da ich dann das NAT vernachlässigen kann und nur an einer Stelle zentral eine Einstellung für eine Freigabe treffen muss anstatt an zweien

    Ich bin mir noch nicht sicher, wie du das meinst bzw. was du damit erreichen willst. Je nachdem, wie du zu Hause die Konfiguration vornimmst, musst du doch wieder ein NAT aufsetzen. Und ggf. kommst du damit auf zwei Defaultgateways in deinem Netz, was die Sache sehr schnell sehr komplex machen kann. Schickst du deinen gesamten Datenverkehr durch den RED Tunnel? Oder soll der nur für spezifische Zugriffe von außen dienen?


    Leider hat bei mir bisher keine der Möglichkeiten funktioniert. Mal ist es an der Firewall gescheitert (trotz aktiver Einstellung und Erlauben von Any-Any-Any) , mal am RED Tunnel (down, up und keine Verbindung etc.), mal an einem "Error", der in keinem Log angezeigt wird.

    Es ist natürlich extrem schwierig, auf dieser Basis den Fehler einzuschränken. Was genau ist denn gescheitert, wie äußert sich das, wie hast du es analysiert, was hast du dagegen getan? Welche Dienste willst du überhaupt über den Tunnel nutzen und wie hast du das zu Hause eingerichtet? Das müssten wir schon wissen.


    - VLAN dazu gebucht

    Wofür braucht man das?

  • Hallo Patrick,


    schön, dass Dir mein Setup gefällt. Leider verstehe ich anhand deiner Ausführungen nicht, was zurzeit das Problem ist. Lass uns analytisch vorgehen, dann klappt es bestimmt.


    1.) Ist die RED-Verbindung zwischen den Sophos UTM Firewalls (bei netcup und an deinem Internetanschluss) erfolgreich aufgebaut?

    2.) Hast du auf beiden Firewalls ein Interface vom Typ Ethernet erstellt und mit dem RED-Tunnel gekoppelt?

    3.) Hast du für die neuen Interfaces der beiden Firewalls IP-Adresse aus einem gemeinsamen IP-Subnetz vergeben?

    4.) Können die beiden Firewalls sich gegenseitig via ICMP erreichen?

  • Hallo ihr beiden,


    ich versuche mal auf alle Fragen zu antworten:

    Zu frank_m:

    1. Es sind Details verborgen: Das habe ich mir schon fast gedacht (Hatte mich schon über ein paar Punkte und unterschiedlichen Ansätze gewundert gehabt und dementsprechend freue ich mich, dass das jetzt noch einmal zur Sprache kommt)


    2. Warum möchte ich den gesamten Traffic tunneln?

    -> Mein Wunsch bzw. Überlegung ist es, dass der gesamte Traffic (natürlich nur die Ports usw., den ich in der Sophos bei netcup freigegeben habe) bei mir ankommt. Das möchte ich aber nur an einer einzigen Stelle machen.....und gerade jetzt kommts mir in den Kopf: Eigentlich blöd, weil ich es dann trotzdem zwei Mal einstellen muss :-D Also ignorieren wir den Fall mal^^


    3. Was möchte ich erreichen?

    -> Ich möchte diverse DNS-Einträge auf die IP legen. Je nach Eintrag werden ggf. andere Ports und andere IPs innerhalb meines Heimnetzes angesprochen.

    Es sollen am Ende Dinge wie ein Confluence, GitLab, nginx, Time series Datenbanken, Grafane usw. erreichbar gemacht werden.


    4. VLAN: Ich kann es dir nicht pauschal beantworten, weil es schon zu lange her ist :-D


    Zu Alfy:

    Ich hatte den Beitrag abgesendet und mir direkt gedacht: Irgendwas fehlt, aber ich weiß auch nicht, wo ich hätte anfangen sollen^^

    Zu 1.: Ja, die RED-Verbindung zwischen den Sophos ist aufgebaut (netcup ist RED Server und Home ist RED Client) - der grüne Haken ist unter RED Management vorhanden und nicht rot.


    Zu 2.+3.: Ich habe auf beiden Firewalls je ein Ethernet Interface erstellt

    -> Hier ist die Frage zum Verständnis: Ich kann jede x-beliebige IP Adresse nehmen. die nicht innerhalb meiner existierenden IP Range liegen, weil meine anderen Interfaces dazu benutzt werden, richtig?


    Habe da folgendes:

    *netcup

    - Interface #1: Public IP bei netcup und als Hardware eth0 (mit default Gateway aus netcup heraus)

    - Zusätzliche Adressen: 2. Public IP auf Interface #1

    - Interface #2: 172.27.29.2/24 und als Hardware reds1 (mein RED Interface; kein default Gateway)

    *Home

    - Interface #1: 10.0.16.61/24 mit default Gateway aktiviert

    - Interface #2: 10.0.16.71/24 mit default Gateway aktiviert (dadurch ist das Uplink Balancing automatisch aktiviert worden)

    - Interface #3: 172.27.29.3/24 und als Hardware redc1 (mein RED Interface; default Gateway ist 172.27.29.2)

    Generell nutze ich intern für mein Netzwerk diverse Subnetze im die 10.0.0.0/8er Netz und die 172.16.0.0/12 wird nicht in meinem Netzwerk genutzt und ist unbekannt.


    Zu 4.:

    - Von der UTM Home auf 172.27.29.3 (netcup red interface)-> 100% packet loss (was ja richtig sein müsste, weil die Home doch nur Client ist, oder?)

    - Von der UTM netcup auf 172.27.29.2 (Home interface) -> ICMP funktioniert

  • Mein Wunsch bzw. Überlegung ist es, dass der gesamte Traffic (natürlich nur die Ports usw., den ich in der Sophos bei netcup freigegeben habe) bei mir ankommt.

    Das hört sich so an, als geht es hier um den von außen ankommenden Datenverkehr, also das, was beim Zugriff auf eine DNS oder dyndns Adresse zu dir geschickt wird. Der augehende Datenverkehr soll also direkt über deine Internetverbindung geschickt werden? Dann hast du jetzt ein veritables Routing Problem zumindest wenn du die Anleitung mit der öffentlichen IP auf dem RED Interface befolgst.

  • Hallo Patrick,


    herzlichen Dank für deine ausführliche Antwort. Ich denke, dass Thema "Aufbau der RED-Verbindung" können wir als erledigt betrachten. Sobald auf beiden Seiten die Verbindung als aktiv (grüner Haken) angezeigt wird, ist darüber hinaus nichts mehr zu tun.

    Jedoch sollten wir über die Interfaces und das IP-Setup sprechen. Die beiden Firewalls sollten sich über die RED-Verbindung gegenseitig via IMCP erreichen können. Solange es aus einer Richtung zu 100% Packet Loss stimmt etwas nicht.


    Die Konfiguration der Interfaces meines RED-Servers (Sophos UTM bei netcup) sieht wie folgt aus:


    Die Konfiguration der Interfaces meines RED-Client (Sophos UTM am DG-Anschluss) sieht wie folgt aus:


    Zwischen den beiden Sophos UTM Firewalls verwende ich also das IP-Subetz 10.255.31.0 /32. Du kannst natürlich jedes beliebige IP-Subnetz aus dem privaten Addressraum nutzen, welches sich nicht mit einem bereits vorhanden IP-Subnetz (auf beiden Seiten) überschneidet.

    Den Haken "IPv4 Default GW" solltest Du nur bei einem einzigen Interface pro Firewall setzen; nämlich dem WAN-Interface (bzw. im Fall von Uplink-Balancing "den WAN-Interfaces").


    Mit den nachfolgenden Einstellungen (Network Protection -> Firewall -> IMCP) stellst Du sicher, dass beide Firewalls mit ICMP "zurecht kommen" und ein ICMP-Test in beide Richtungen funktioniert.


    Anschließend sollte ein ICMP-Test (Support -> Tools -> Ping Check) in beide Richtungen funktionieren.

    Zuerst vom RED-Client zum RED-Server:

    Anschließend vom RED-Server zum RED-Client:


  • Das hört sich so an, als geht es hier um den von außen ankommenden Datenverkehr, also das, was beim Zugriff auf eine DNS oder dyndns Adresse zu dir geschickt wird. Der augehende Datenverkehr soll also direkt über deine Internetverbindung geschickt werden? Dann hast du jetzt ein veritables Routing Problem zumindest wenn du die Anleitung mit der öffentlichen IP auf dem RED Interface befolgst.

    Wenn das Setup richtig funktioniert, werden die lokalen Clients für die "normale Kommunikation" stets den lokalen Internet-Breakout verwenden. Nur für die Rückantwort, des von außen an den Cloud Firewall empfangene und nach innen weitergeleitete Traffic, wird der Weg über den RED-Tunnel verwendet. Es gibt also kein asymmetrisches Routing und die Verwendung von Policy-Based-Routing ist auch nicht erforderlich.

  • Wenn das Setup richtig funktioniert,

    Welches Setup nutzt du? Auch das mit der 2. öffentlichen IP, welche auf das lokale RED Interface getunnelt wird?


    Nur für die Rückantwort, des von außen an den Cloud Firewall empfangene und nach innen weitergeleitete Traffic, wird der Weg über den RED-Tunnel verwendet.

    Und wie stellst du das sicher? DNAT?


    Aber das sind die Sachen, die ich meinte, als ich oben sagte, die Anleitung lässt gewisse Details offen.

  • Eine grobe Beschreibung meines Setups hat Patrick im ersten Beitrag verlinkt: DynDNS nach Wechsel zu DG


    Auf der Sophos UTM Cloud Firewall kann man entweder mit Port-Forwarding - was ja eine Form des DNAT ist - oder mit einer WAF arbeiten. Die WAF ist eine sehr nette Option, eignet sich aber nicht für alle Anwendungsfälle. Daher ist es in meinem Fall ein Mischbetrieb.


    Hinsichtlich der Qualität der verlinkten Anleitung stimme ich dir zu. Es ist kein Step-by-Step How-To dem man bedenklos folgen kann.

  • Du findest dieses Forum hier toll und möchtest es unterstützen? Großartig! Hier zeigen wir dir eine Möglichkeit, wie du uns supporten kannst. Es kostet dich keinen Cent mehr und das Forum bleibt hiermit weiter werbefrei.

    Amazon Link

    Nutze diesen Button um bei Amazon einzukaufen. Das kostet dich keinen Cent mehr, jedoch bekommen wir eine kleine Provision.
    Bei Amazon einkaufen und das GF unterstützen
    Mehr Infos gibt es in diesem Thread
  • Hey,


    so...ich habe es nun noch einmal im Detail ausgetestet und habe erneut ein paar unverständliche Dinge:

    *netcup

    - NAT Rule angelegt:

    Wobei

    - Rule Type DNAT ist (möchte die Source IPs auch gerne am Zielsystem sehen und nicht nur das Gateway, sonst würde ich Full-NAT wählen)

    - Using Service auf Any steht anstatt, dass ich da einzelne Dienste erlauben kann (gebe ich einen speziellen TCP destination port an und lasse den source port auf alle stehen, geht kein Traffic durch den RED Tunnel - Ist das normal?)

    - Going To meine Additional Address ist, welche auf dem Interface #1 liegt

    - Change the destination to mein RED-Interface zu Hause ist


    Bei der Firewall in netcup gibt es dann folgende Ausgabe:

    Es wird der Traffic also schonmal in den Tunnel geroutet. Die 172.27.29.3 ist dabei mein RED-Interface zu Hause.

    ------------

    *Home

    Ich glaube, hier kommt der große Fehler meinerseits (das ganze doppelte NAT etc. sind noch nie meine Stärke gewesen :-D )

    - Rule Type: DNAT

    - Using service: TCP Port 12345 (das ist immer mein Test)

    - Change destination to: IP Host 10.0.16.208, welcher einen nginx am Laufen hat und intern definitiv funktioniert

    - And the service to: TCP Port 80

    - Automatic Firewall Rule

    Das Ergebnis ist, dass innerhalb des Firewall Logs nichts mehr über die Anfrage ankommt. Deaktiviere ich die NAT Rule, dann erscheint mir die Anfrage durch den Tunnel als DROP, weil er keine Firewall Rule auf die 172.27.29.3 freigegeben hat.


    Irgendetwas fehlt mir hier, nur weiß ich nicht was.


    Gruß

    Patrick

  • Hallo Patrick,


    bevor wir uns über das Port-Forwarding unterhalten, muss das Routing zwischen den beiden Firewalls funktionieren. In deinem Fall dürfte die Konfiguration einer statischen Route am einfachsten sein (alternativ wäre auch dynamisches Routing möglich).


    Zum allgemein besseren Verständnis:

    • In deinem privaten Heimnetz verwendest du das IP-Subnetz 10.0.16.0 /24
    • Als IP-Subnetz zwischen deinen beiden Firewalls hast du 172.27.29.0 /24 gewählt
    • Das IP-Interface der Cloud-Firewall hat die IP-Adresse 172.27.29.2
    • Das IP-Interface der Heim-Firewall hat die IP-Adresse 172.27.29.3
    • In der Cloud-Firewall hast du eine statische Route für das IP-Subnetz 10.0.16.0 /24 mit dem Next Hop 172.27.29.3 (Heim-Firewall) konfiguriert.


    Wenn alles korrekt funktioniert, solltest Du nun mit einem Client aus deinem Heimnetz (10.0.16.0 /24) das IP-Interface der Cloud-Firewall (172.27.29.2) via ICMP erreichen können. Kannst Du das verifizieren?


    Anschließend würde ich für die Einrichtung des Port-Forwardings die Verwendung des Generic Proxy (Network Protection -> Advanced -> Generic Proxy) empfehlen. Die Konfiguration sieht z.B. wie folgt aus:


    In meinem Beispiel leitet die Firewall den am Interface "INT_WAN" empfangenen Traffic des Typs "SRV_Synolog[...]" an das Ziel "DS", Port "SRV_Synolog[...]" weiter. Die ursprüngliche Quelle des Traffics muss das Netz "NET_GRP_Internet_[...]" sein.

    Das interne Ziel "DS" empfängt den Traffic über vom ausgehenden Interface der Cloud-Firewall.


    Vom grundsätzlichen Öffnen aller Ports rate ich ausdrücklich ab. Wenn man eine vernünftige Firewall zur Verfügug hat, sollte man keinen Exposed Host konfigurieren. Stattdessen empfiehlt es sich, sich auf die tatsächlich benötigten Services zu beschränken. Pro Freischaltung also eine Proxy-Regel.


    Anschließend ist es wichtig, dass in der Heim-Firewall die entsprechenden Freigaben für die interne Quelle des Traffics - also in deinem Fall die IP-Adresse 172.27.29.2 - eingerichtet werden.


    *PS: Deine Aussage mit der ursprünglichen Quell-IP verstehe ich nicht so recht. Du würdest damit lediglich ein asymmetrisches Routing erzeugen und dir noch ein paar anderen Probleme einhandeln.

  • Guten Morgen,


    Deine Angaben zu den Netzwerksettings sind korrekt.


    Ich habe mir eine Ubuntu VM aufgesetzt, die eine IP in der 10.0.16.0/24 hat und den ICMP request gegen die 172.27.29.3 laufen lassen. Es kommt nichts zurück. Auch in meiner Netzwerk Clientübersicht taucht der Client als solches gar nicht erst auf.

    Frage ist natürlich: Sollte er das überhaupt, weil er rein virtuell ist und als "Hardware" das RED Interface hat und somit nur innerhalb der Sophos existiert?


    Gruß

    Patrick

  • Guten Morgen,


    es mag an der Uhrzeit liegen, aber irgendwie hast Du mich mit deiner Antwort gedanklich abgehängt.


    Du hast also in deinem Heimnetz (10.0.16.0 /24) eine Ubuntu VM. Diese erreicht jedoch via ICMP nicht das RED-Interface der Cloud-Firewall (und vermutlich auch nich das RED-Interface der Heim-Firewall).


    Welches Gateway nutzt die VM? Wie lautet die IP-Adresse der Sophos UTM im Heimnetz (10.0.16.0 /24)? Kann die VM das Interface der Firewall im Heimnetz via ICMP erreichen?

    Um Fehler mit der VM auszuschließen wäre es ggf. sinnvoll einen physischen Client zu testen.


    Ehrlich gesagt fürchte ich, dass du mit deinem Setup des Heimnetz etwas von der Anleitung abweichst. Daher bin ich auf die Antworten gespannt. Was ich aber bislang gar nicht verstehen will ist diese Aussage:

    Zitat

    Sollte er das überhaupt, weil er rein virtuell ist und als "Hardware" das RED Interface hat und somit nur innerhalb der Sophos existiert?

  • Moin!


    Das dürfte vermutlich etwas komplizierter sein, ja^^


    Ich versuche es mal....Ich habe in meinem Heimnetz auf meinem ESXi virtualisiert beide Systeme am Laufen:

    - eine Ubuntu VM

    -- 1 virtuelles Netzwerkinterface: 10.0.16.208

    - die Sophos UTM

    -- virtuelles Netzwerkinterface #1: 10.0.16.61

    -- virtuelles Netzwerkinterface #2: 10.0.16.71


    Gateway für beide: 10.0.16.1 (das ist meine Ubiquiti Dream Machine Pro, die die 10.0.11.1 hat).


    Alle IPs lassen sich gegenseitig ohne packet loss anpingen.

    ------

    Zu meiner Aussage: Die Sophos UTM ist auf beiden Seiten virtualisiert. Das RED-Interface (egal auf welcher Seite) wird in dem Sinne "manuell" im Webinterface angelegt. Bei der Auswahl der Hardware wählen wir kein "echtes" Interface aus, sondern den RED-Tunnel. Dieser ist demnach für mich rein virtuell. Wie das bei einer Hardware Appliance wiederum aussieht, kann ich nicht sagen.

  • So ganz generell finde ich in deinen Beschreibungen einige Unschönheiten. Die müssen in deinem Fall nicht zwangsläufig zu Problemen führen, aber die können im Detail richtig weh tun. Außerdem wird deutlich, dass die Beschreibung deines Heimnetzes noch sehr lückenhaft ist.


    -- virtuelles Netzwerkinterface #1: 10.0.16.61

    -- virtuelles Netzwerkinterface #2: 10.0.16.71

    Warum zwei Interfaces im gleichen Subnetz? Das ist üblicherweise eine Todsünde. Das kann - je nachdem, wie du die UTM mal einsetzen willst - böse nach hinten losgehen.


    Gateway für beide: 10.0.16.1 (das ist meine Ubiquiti Dream Machine Pro, die die 10.0.11.1 hat).

    Und das auch schon wieder. Welche IP hat deine Dream Machine denn nun? 10.0.11.1 oder 10.0.16.1? Oder beide? Wie ist das Routing von 10.0.11.0/24 zu 10.0.16.0/24? Oder sind es es gar nicht 2 /24 Netze, sondern ein /16? Wenn es zwei Netze sind: Ist ein NAT Router dazwischen? Wenn nicht: Wer kümmert sich um das Routing zwischen den beiden Netzen? Was ist 10.0.11.0 überhaupt für ein Netz?

  • Hallo Patrick,


    ich denke, dass ich die wesentlichen Aspekte deines Setups verstanden habe. Sieht dein Netzwerk in simplifizierter Form in etwa so aus?

    Ja, ich weiß, die Zeichnung ist nicht gerade hübsch geworden (quick-and-dirty).


    Zunächst muss ich Frank zustimmen. Die Heim-Firewall mit zwei Interfaces im gleichen IP-Subnetz zu betreiben ist wenig sinnvoll. Die Funktion des Uplink Balancing ist maßgeblich für die Lastverteiler oder ein Failover gedacht, wenn man verschiedene ISPs nutzen möchte. Dies scheint in deinem Setup nicht der Fall zu sein.


    Damit die Ubuntu VM das IP-Interface der Cloud-Firewall (172.27.29.2) via ICMP erreichen kann, musst du eine entsprechende Route einrichten. Dies kannst du in der jetzigen Form deines Setups auf verschiedene Weisen realisieren; keine davon ist besonderns schön und schon gar nicht empfehlenswert:

    1. Route auf der VM für das Netz 172.27.29.0 /24 mit dem Next Hop 10.0.16.61 UND / ODER 10.0.16.71
    2. Route auf der UniFi Dream Machine Pro für das Netz 172.27.29.0 /24 mit dem Next Hop 10.0.16.61 UND / ODER 10.0.16.71

    Nun kannst Du gut erkennen, wieso das Uplink Balancing der Heim-Firewall Probleme erzeugt. Die Firewall ist nicht eindeutig addressierbar.

    Ich vermute, dass Du Uplink Balancing mit der virtuellen IP-Adresse eines redundanten Firewall-Clusters verwechselt hast.


    Das zweite, was spätestens beim Eintragen der Routen auffällt, ist die Asymmetrie des Routings. Hier ein Biespiel (ausgehend von der oben beschriebenen Option 2):


    Die Ubuntu VM schickt ein Paket an die Cloud-Firewall (172.27.29.2.) Da das Ziel nicht im IP-Subnetz der VM liegt, schickt die VM das Paket an ihr Gateway (10.0.16.1). Das Gateway empfängt das Paket und leitet es gemäß der konfigurieretn Route an die Heim-Firewall (10.0.16.61 ODER 10.0.16.71) weiter. Die Heim-Firewall empfängt das Paket und stellt es am Ziel zu; das IP-Interface 172.27.29.2 der Cloud-Firewall.

    Zusammengefasst: VM -> Dream Machine -> Heim-Firewall -> Cloud-Firewall (3 Hops)


    Die Cloud-Firewall schickt ein Paket an die VM (10.0.16.208). Für dieses IP-Subnetz verwendet die Cloud-Firewall gemäß der bereits konfigurieretn Route die Heim-Firewall (172.27.29.3) als Next-Hop. Die Heim-Firewall kann das emfpangene Paket sofort an die VM zustellen.

    Zusammengefasst: Cloud-Firewall -> Heim-Firewall -> VM (3 Hops)


    Sofern meine Ausführungen und Vermutungen der Realität entsprechen, sollten wir uns über ein mögliches Re-Design deines Netzwerks unterhalten. Erst danach ist das Port-Forwarding über den RED-Tunnel sinnvoll einsetzbar.

  • Du findest dieses Forum hier toll und möchtest es unterstützen? Großartig! Hier zeigen wir dir eine Möglichkeit, wie du uns supporten kannst. Es kostet dich keinen Cent mehr und das Forum bleibt hiermit weiter werbefrei.

    Amazon Link

    Nutze diesen Button um bei Amazon einzukaufen. Das kostet dich keinen Cent mehr, jedoch bekommen wir eine kleine Provision.
    Bei Amazon einkaufen und das GF unterstützen
    Mehr Infos gibt es in diesem Thread

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden