FQDN Routing über RED Tunnel

Da das "narmale WAN" meist über das default Gateway (oder den WAN-link-Manager) mit rel. niedriger Priorität geroutet werden, sollte eine "granularere" Route zu spezifischen öffentlichen IP's über die RED-Verbindung das schlagen.
Sonst bleibt noch das SD-WAN-Routing. Dort müsste auch mit FQDNs/Domains gearbeitet werden können.

Hallo Dirk,

vorab eine kurze Übersicht über mein Netzwerk:

Lokales LAN (LAN MAIN): 10.1.1.0/24
Entferntes LAN (Hetzner): 10.1.10.0/24

RED Tunnel: 10.1.200.0/28

Lokale Firewall RED IP: 10.1.200.2
Entfernte Firewall RED IP: 10.1.200.1

Jetzt habe unter Routing - Gateways ein neues Gateway mit der RED Tunnel IP der anderen Firewall angelegt. In der Übersicht wird der Status hier auch als "grün" angezeigt.

Anschließend habe ich versucht eine "Test" SD-WAN Route zu erstellen, welche allerdings nicht so wirklich funktioniert.

In der Übersicht sieht man zwar, dass ein ausgehender Traffic vorhanden ist, allerdings gibt es keinen eingehenden Traffic. Das ist wahrscheinlich auch der Grund, warum die als Ziel angegebene Webseite jetzt aus dem Netzwerk nicht mehr erreichbar ist.

Ich vermute, dass hier bei der anderen Firewall auch eine entsprechende Regel oder Route erforderlich ist, welche der anderen Firewall sagt, dass die Pakete wieder über den Tunnel zurückgeschickt werden sollen. Da ich soetwas aber noch nie umgesetzt und gebraucht habe, würde ich hier Hilfe benötigen, da ich keinen Plan habe was hierfür noch anzulegen ist.

Liebe Grüße
Manuel

teste das mal mit einer festen IP im internet.

z.B. 1.1.1.1  diese ist "pingbar" und kann per https angesprochen werden.

Bei Wildcard-DNS-Hosts gibt es noch ein paar Abhängigkeiten, auf die wir gern später eingehen können. (habe gerade sehr wenig Zeit)

Das funktioniert leider auch nicht. Sobald ich die Route aktiviere bricht der Ping ab und über https ist die Webseite dann auch nicht mehr erreichbar. Der ausgehende Traffic erhöht sich bei der SD-WAN Route.

LG
Manuel

Du kommst von dem Netz: 10.1.1.0 --> Hat die Firewall bei Hetzner eine Route zu diesem Netz? 

Genau. Mein lokales LAN hat die 10.1.1.0. Es sind auf beiden Firewalls jeweils die entsprechenden Routen als Statische Routen angelegt:

Lokale Firewall:

Hetzner Firewall:

Genau. Mein lokales LAN hat die 10.1.1.0. Es sind auf beiden Firewalls jeweils die entsprechenden Routen als Statische Routen angelegt:

Lokale Firewall:

Hetzner Firewall:

Kannst du die Route aktivieren, dann auf die Website via Ping zugreifen und ein packet capture mit BPF String: ICMP auf beiden Seiten machen?
Schick uns den Screenshot davon. 

Entschuldigt bitte die späte Rückmeldung. Leider bin ich erst jetzt dazugekommen.

Ich hoffe, dass passt so und ihr könnt damit etwas anfangen. Meine öffentliche IP Adresse und das Gateway habe ich unkenntlich gemacht.

Lokale Firewall (10.1.1.0/24)

Hetzner Firewall (10.1.10.0/24)

Das zeigt, da fehlt eine Firewall Regel? 

hmm. ich habe auf beiden Firewalls jeweils folgende Regel erstellt:

Ich komme auch von beiden Seiten ins jeweilige andere Netz.

Dein Ping möchte ins Internet (1.1.1.1) dafür hast du ja keine Firewall Regel? 

... und wenn in der FW-Regel (oder im SD-WAN-Routing) mit FQDN-Wildcards gearbeitet wird (*.wieistmeineip.at) , muss die FW die Namensauflösung für den Client machen. Sonst "kennt" die FW die IP's zu den möglichen Namen nicht und die Regeln funktionieren nicht.

.... daher die Empfehlung, das ganze erst mal mit IP's zu testen. 

Auf beiden Firewalls gibt es ganz unten noch die Default Network Policy mit LAN nach WAN - beliebiger Host & Dienst. Diese sollte den Ping ins Internet ja durchlassen oder etwa doch nicht?

In welcher Zone sind denn die RED Interfaces? 

Die RED Interfaces befinden sich in der LAN Zone.

Meine RED Interface Konfiguration sieht so aus:

Hetzner Firewall (als Server)

Lokale Firewall (als Client)

Die LAN(Zone)-to-WAN(Zone) Regel greift aber nicht, wenn die erste Firewall die Pakete für das internet an eine LAN-Zone übergibt.

Viel von dem Erwähnten sollte man auch im LogViewer recht gut nachvollziehen können.