Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - lennart

#1
@Bob.Dig danke für Hilfe. Das funktioniert wie es soll. Ich verstehe nur noch nicht ganz was reply to auf technischer ebene genau bedeutet, aber das finde ich schon noch heraus.

Danke natürlich auch an alle anderen die hier versucht haben zu helfen 
#2
@Alpha_DE die Quell IP ändert sich aufgrund des Outbound Nat das notwendig ist, damit der Webserver nach beantworten der Anfrage wieder den richtigen Router findet. Wnn ich das Outbount NAT deaktiviere das im WG interface arbeitet (von mir selbst ersdtellt), dann wird zwar die richtige Quell IP weitergeleitet aber das Paket findet nicht denn weg zum richtigen Router zurück.
#3
Danke für den Denk Anstoß,

1. der Webserver über Port 80 dienst  nur zur Demonstration. Hinter dem Port forwarding stehen noch weitere TCP und UDP anwendungen.

2. Ist der Aufbau so wie ich ihn beschrieben habe überhaupt möglich? Eigendlich ist bis auf den zusätlichen Hob ja technisch gesehen nichts anders. Oder?

3. Gibt es eine möglichkeit herauszufinden wo die antwort des Webservers tatsächlich landet bzw. welchen weg diese nimmt. Wenn ich das wüste, dann könnte ich das Problem vieleichst selbst fixen.

Die Idee mit dem Caddy hallte ich mir aber offen.

Danke für die bisherige Hilfe!


#5
Hier die Bilder nochmal direkt
#6
Link zu PDF: https://nc.ljoswig.de/s/ACw6yZK2HxNRdmB

Moin,
wie in der Zeichnung (ganz unten im PDF) und in der Aufzählung geschildert,
der Aufbau (der einwandfrei) funktioniert und das Problem, das sich daraus ergibt.
1.   TCP-Paket eingehend auf WAN-Adresse bei Hetzner
2.   Port Forwarding auf Server im Lan (Opnsense Home)
3.   Outbound NAT: Quell IP wird auf Interface (wg) IP der Opnsense (10.99.99.1) gesetzt
4.   Antwort vom Server zurück über Wireguard zum Hetzner Router
5.   Outbound NAT. Quell IP wird wieder zurückgesetzt. (Automatisch durch 3)
6.   Port Forwarding: Destination wird wieder ersetzt (Automatisch durch Regel 2)
7.   Paket ausgehend zum Client
Das Problem, das sich daraus ergibt, ist das die Quell IP nicht mehr für den Web-Server sichtbar ist. So ist z.B. Brute Force Erkennung und Abwehr nicht mehr möglich.
Ohne das Outbound Nat würde der Webserver das Paket jedoch über das Default gateway schicken und nicht über den WG, weil die Source ja eine öffentliche IP ist.
Lösungsidee: Die Opnsense bei Hetzner wird als Default Gateway für den LAN Traffic des Webservers. Dann landet die Antwort auch wieder bei der Hetzner Opnsense.
Problem: Es funktioniert nicht! Der Upstream über Opnsense (Hetzner) geht.

Aber das Paket kommt ohne Outbound Nat (Schritt 3) nicht wieder beim Client an. Auf der Opnsense Home sind keine Port Forward oder eigenen Outbound NAT Rules generiert. Leider kann ich das Paket ja nicht wieder zurückverfolgen. Oder? Nach dem Erreichen des Web-Servers wird ja kein Log mehr bei der Antwort geschrieben?
Egal ob mit oder ohne Quell IP Umschreibung. Das Paket kommt beim Webserver an! Das habe ich überprüft.
Hat jemand eine Idee, woran das liegen könnte?


#7
Hi,

ich habe zu Hause eine OPNsense mit zwei Gateways zum Internet für Redundanz eingerichtet (IPv6 deaktiviert, WAN Group erstellt, Traffic mit Ziel von außerhalb von RFC1918 über die Gateway Group geleitet). Um immer nur eine IPv4-Adresse bzw. einen IPv6-Netzbereich zu haben, habe ich zusätzlich eine Hetzner Cloud-Maschine mit OPNsense installiert. Beide sind über WireGuard verbunden. Der IPv6-Upstream funktioniert problemlos, da ich einfach ein Gateway und eine Route für :: über das Gateway einrichten konnte.

Für IPv4 funktioniert das jedoch nicht so einfach, da die OPNsense selbst IPv4 benötigt, um zum VPN-Server zu gelangen, und ich auch nicht den gesamten IPv4-Traffic über WireGuard schicken möchte. Mein Ziel ist es, den IPv4-Traffic von bestimmten lokalen Netzwerken über den VPN zu leiten.

Ich habe ein Upstream-Gateway erstellt, das auf die WireGuard-IP des Hetzner-Servers zeigt, und in den Firewall-Regeln die LAN-Regel fürs IPv4-Upstream so geändert, dass sie auf das erstellte IPv4-WireGuard-Gateway verweist. Ich vermute, dass ich jetzt eine Outbound-NAT-Regel benötige. Outbound-NAT steht bei mir bereits auf Hybrid (OPNsense bei mir zu Hause). Was müsste in diese Regel rein und habe ich etwas vergessen? Die Firewall-Regel auf der Hetzner-OPNsense ist für das WireGuard-Interface auf Any-Any gesetzt und ich habe den Upstream mit einem PC getestet (Direktverbindung). Das Gateway-Monitoring funktioniert jedoch nicht für öffentliche IPs, für die Gateway-Adresse (OPNsense WireGuard LAN-Adresse) schon, also WireGuard funktioniert.

Der Upstream über die Hetzner-IP notwendig für z.B. Autorisation über IP (z.B. Mailserver) und geringere Ausfallzeiten, die beim Neuaufbau der Routen entstehen (ohne Upstream via Hetzner dauert es bei mir bis zu 2 Minuten, mit ca. 6 Sekunden).

Danke für die Hilfe!