3
Pfsense Routing Probleme mit IPSEC site-to-site und OpenVPN Einwahl
Hallo Zusammen,
zunächst vielen Dank an alle die hier helfen können - ich bin um jeden Ansatz dankbar!
Aktuell stehe ich vor folgendem Scenario und komme nicht weiter:
Netze:
192.168.60.0/24 (Seita A - Lokales Netzwerk)
10.0.8.0/24 (Tunnelnetzwerk zur Einwahl OpenVPN)
10.231.0.0/24 (Seite B - Endpunkt auf der Gegenseite von IPSEC Tunnel)
1x feste Site-to-site VPN IPSEC Tunnel inkl. Phase 2 Definition für das lokale Netz (Funktioniert problemlos)
1x OpenVPN Einwahlverbindungen von außerhalb in das Netzwerk
Nun zur eigentlichen Problemstellung:
Bei der Einwahl in das Netzwerk über OpenVPN von einem externen Gerät (z.B. Laptop) funktioniert die Einwahl super - IP Adresse aus dem 10.0.8.0/24 wird zugewiesen und das Netz 192.168.60.0/24 (LAN) und alle darin erreichbaren Geräte sind pingbar.
Jedoch bei dem Versuch Geräte aus dem Bereich 10.231.0.0/24 zu erreichen schlägt der Ping jedesmal fehl. Wenn ich jedoch aus dem LAN heraus einen Ping auf die IP Adressen absetze wird dieser auch richtig transportiert. Somit sollte der Angelpunkt eine Konfigurationsänderung in Pfsense sein (Soweit die Theorie ;).
In der lokalen Routingtabelle taucht das Netz auch sauber auf:
Des weiteren ist beim Paket Captura auch zu erkennen das er die Pakete zumindest bis zur Pfsense transportiert:
17:37:41.558603 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:41.659320 IP 192.168.60.10.8100 > 10.0.8.6.62230: tcp 0
17:37:42.458915 IP 10.0.8.6 > 10.231.0.75: ICMP echo request, id 1, seq 6324, length 40
17:37:42.558650 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:43.458743 IP 10.0.8.6 > 10.231.0.75: ICMP echo request, id 1, seq 6325, length 40
17:37:43.558621 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:43.658620 IP 10.0.8.6.62229 > 10.231.0.75.17300: tcp 0
17:37:43.758600 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
Jedoch versucht er dann die Pakete über das WAN Gateway zu schicken, anstatt über den IPSEC Tunnel.
Ich würde mich sehr freuen wenn jemand ein paar brauchbare Tipps hat - Mir gehen nun die Ideen aus.
Hier nun noch ein paar Screenshots die das ganze erleichtern sollen:
Vielen Dank!
zunächst vielen Dank an alle die hier helfen können - ich bin um jeden Ansatz dankbar!
Aktuell stehe ich vor folgendem Scenario und komme nicht weiter:
Netze:
192.168.60.0/24 (Seita A - Lokales Netzwerk)
10.0.8.0/24 (Tunnelnetzwerk zur Einwahl OpenVPN)
10.231.0.0/24 (Seite B - Endpunkt auf der Gegenseite von IPSEC Tunnel)
1x feste Site-to-site VPN IPSEC Tunnel inkl. Phase 2 Definition für das lokale Netz (Funktioniert problemlos)
1x OpenVPN Einwahlverbindungen von außerhalb in das Netzwerk
Nun zur eigentlichen Problemstellung:
Bei der Einwahl in das Netzwerk über OpenVPN von einem externen Gerät (z.B. Laptop) funktioniert die Einwahl super - IP Adresse aus dem 10.0.8.0/24 wird zugewiesen und das Netz 192.168.60.0/24 (LAN) und alle darin erreichbaren Geräte sind pingbar.
Jedoch bei dem Versuch Geräte aus dem Bereich 10.231.0.0/24 zu erreichen schlägt der Ping jedesmal fehl. Wenn ich jedoch aus dem LAN heraus einen Ping auf die IP Adressen absetze wird dieser auch richtig transportiert. Somit sollte der Angelpunkt eine Konfigurationsänderung in Pfsense sein (Soweit die Theorie ;).
In der lokalen Routingtabelle taucht das Netz auch sauber auf:
Des weiteren ist beim Paket Captura auch zu erkennen das er die Pakete zumindest bis zur Pfsense transportiert:
17:37:41.558603 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:41.659320 IP 192.168.60.10.8100 > 10.0.8.6.62230: tcp 0
17:37:42.458915 IP 10.0.8.6 > 10.231.0.75: ICMP echo request, id 1, seq 6324, length 40
17:37:42.558650 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:43.458743 IP 10.0.8.6 > 10.231.0.75: ICMP echo request, id 1, seq 6325, length 40
17:37:43.558621 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
17:37:43.658620 IP 10.0.8.6.62229 > 10.231.0.75.17300: tcp 0
17:37:43.758600 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
Jedoch versucht er dann die Pakete über das WAN Gateway zu schicken, anstatt über den IPSEC Tunnel.
Ich würde mich sehr freuen wenn jemand ein paar brauchbare Tipps hat - Mir gehen nun die Ideen aus.
Hier nun noch ein paar Screenshots die das ganze erleichtern sollen:
Vielen Dank!
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: 230539
Url: https://administrator.de/contentid/230539
Printed on: April 25, 2024 at 15:04 o'clock
3 Comments
Latest comment
Hallo,
Gruß,
Peter
Zitat von @mythice:
192.168.60.0/24 (Seita A - Lokales Netzwerk)
10.0.8.0/24 (Tunnelnetzwerk zur Einwahl OpenVPN)
10.231.0.0/24 (Seite B - Endpunkt auf der Gegenseite von IPSEC Tunnel)
192.168.60.0/24 (Seita A - Lokales Netzwerk)
10.0.8.0/24 (Tunnelnetzwerk zur Einwahl OpenVPN)
10.231.0.0/24 (Seite B - Endpunkt auf der Gegenseite von IPSEC Tunnel)
1x feste Site-to-site VPN IPSEC Tunnel inkl. Phase 2 Definition für das lokale Netz (Funktioniert problemlos)
1x OpenVPN Einwahlverbindungen von außerhalb in das Netzwerk
1x OpenVPN Einwahlverbindungen von außerhalb in das Netzwerk
Bei der Einwahl in das Netzwerk über OpenVPN von einem externen Gerät (z.B. Laptop)
Und jetzt die Kardinalsfrage: Auf welchen VPN Server bist du dann? Netz A oder Netz B und was ist über den Tunnel dann Erlaubt bzw. Verboten. Du kannst dich ja an beide VPN Server nicht gleichzeitig anmelden. Geht es jeweils wenn du dich an VPN Server A und an VPN Server B einwählst ist soll und darfst du dich nur an einen der Beiden VPN Server einwählen?Jedoch bei dem Versuch Geräte aus dem Bereich 10.231.0.0/24 zu erreichen schlägt der Ping jedesmal fehl.
Dürfen den die Geräte auf einer IP aus deinen netz Antworten?In der lokalen Routingtabelle taucht das Netz auch sauber auf:
Das 10.231.0.0? Ja. Da steht das alles über deine 10.0.8.x gehen soll.Des weiteren ist beim Paket Captura auch zu erkennen das er die Pakete zumindest bis zur Pfsense transportiert:
Nö. ich sehe keine Aufzeichnung deiner PfSense. Nur die kann es dir sagen.17:37:42.458915 IP 10.0.8.6 > 10.231.0.75: ICMP echo request, id 1, seq 6324, length 40
17:37:42.558650 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
Jedoch versucht er dann die Pakete über das WAN Gateway zu schicken, anstatt über den IPSEC Tunnel.
Nicht ganz. Schau dir die Metric deiner Routen an. Und wenn er (Wer ist er?) die Pakete dann endlich über deine WAN Schnittstelle schickt, stimmt dein Routing nicht oder er findet keinen Weg zu deinen Endziel. Und er (?) kann bei dem Site-to-Site Problemlos pingen oder ist er dann doch nicht er sondern ein anderer?17:37:42.558650 IP 94.250.XXX.XXX (IP von Gateway) > 10.0.8.6: ICMP net 10.231.0.75 unreachable, length 36
Jedoch versucht er dann die Pakete über das WAN Gateway zu schicken, anstatt über den IPSEC Tunnel.
Gruß,
Peter
Deine Subnetzmaske vom 10.231.0.0er Netz ist im OVPN Client bzw. in seiner Routing Tabelle falsch !
Hast du das gesehen ? Dort ist eine 16 Bit Maske angegeben aber in deiner Beschreibung oben redest du von einer 24 Bit Maske.
Vermutlich ist also hier das "push route" Kommando in der server.conf Datei bzw. den OVPN Server Settings falsch oder mit einer falschen Subnetzmaske konfiguriert.
Das solltest du unbedingt korrigieren. Möglich das damit falsche Routing Entscheidungen getroffen werden.
Zusätzlich solltest du darauf achten das die FW Regeln an den VPN Interfaces korrekt eingestellt sind und diese IP netze passieren dürfen.
Das Firewall Log der pfSense ist hier immer erste Anlaufstelle !
Die LAN Port FW Rule alles mit der Source 10.0.8.0 nach any zu erlauben ist Blödsinn, denn von dem Port kann eingehend niemals etwas mit einer Source IP 10.8.0.x kommen. Diese Regel kannst du also getrost wieder löschen, was auch sicherer ist.
Kollege pjordorf hat aber Recht, die Rollenverteilung der FWs ist etwas wirr beschrieben. Verstehen tut mal es so:
Wichtig ist hier noch eine statische Route auf der Seite B. Die muss eine Route ins 10.0.8.0er Netzwerk konfiguriert haben wo das next Hop Gateway der IPsec Tunnel ist.
Fehlt der würden sonst Pakete in das 10.0.8.0er netz also dem OVPN Clientnetz lokal ins Internet und damit ins Nirwana geroutet.
Am einfachsten machst du das natürlich wenn du dynamisch routest über den Tunnel (RIPv2 oder OSPF)...es geht aber natürlich auch mit statischen Routen bei den 3 Netzen.
Hast du das gesehen ? Dort ist eine 16 Bit Maske angegeben aber in deiner Beschreibung oben redest du von einer 24 Bit Maske.
Vermutlich ist also hier das "push route" Kommando in der server.conf Datei bzw. den OVPN Server Settings falsch oder mit einer falschen Subnetzmaske konfiguriert.
Das solltest du unbedingt korrigieren. Möglich das damit falsche Routing Entscheidungen getroffen werden.
Zusätzlich solltest du darauf achten das die FW Regeln an den VPN Interfaces korrekt eingestellt sind und diese IP netze passieren dürfen.
Das Firewall Log der pfSense ist hier immer erste Anlaufstelle !
Die LAN Port FW Rule alles mit der Source 10.0.8.0 nach any zu erlauben ist Blödsinn, denn von dem Port kann eingehend niemals etwas mit einer Source IP 10.8.0.x kommen. Diese Regel kannst du also getrost wieder löschen, was auch sicherer ist.
Kollege pjordorf hat aber Recht, die Rollenverteilung der FWs ist etwas wirr beschrieben. Verstehen tut mal es so:
- 192.168.60.0/24 (Seite A - Lokales Netzwerk), hier ist der OVPN Server zur Einwahl und der IPsec Tunnel zur Seite B
- 10.0.8.0/24 (Tunnelnetzwerk zur Einwahl OpenVPN) ist nur das interne OVPN Tunnel Netzwerk
- 10.231.0.0/24 (Seite B - Endpunkt auf der Gegenseite von IPSEC Tunnel) ist nur der IPsec Tunnel zum Standort A also Site to Site A - B
Wichtig ist hier noch eine statische Route auf der Seite B. Die muss eine Route ins 10.0.8.0er Netzwerk konfiguriert haben wo das next Hop Gateway der IPsec Tunnel ist.
Fehlt der würden sonst Pakete in das 10.0.8.0er netz also dem OVPN Clientnetz lokal ins Internet und damit ins Nirwana geroutet.
Am einfachsten machst du das natürlich wenn du dynamisch routest über den Tunnel (RIPv2 oder OSPF)...es geht aber natürlich auch mit statischen Routen bei den 3 Netzen.
1
Vielen Dank an Peter und Aqui!
Die Lösung des Problemes war tatsächlich die Gegenseite des Tunnels, welche die beiden Netze nicht lokal in Ihrer Phase 2 eingetragen hatte. (Statische Route auf Seite B)
Die Lösung des Problemes war tatsächlich die Gegenseite des Tunnels, welche die beiden Netze nicht lokal in Ihrer Phase 2 eingetragen hatte. (Statische Route auf Seite B)
