Routing zwischen mehreren LANs und VPN-Tunneln

Callya

Hallo Community,

ich habe dieses Setup aufgebaut:
alt text

Die orange linie ist eine OpenVPN-Verbindung, die auch funktioniert. Ich habe die Firewall auf dem Router Tuvok deaktiviert und auf den VPN-Clients eine any/any-Regel gemacht, um diese auszuschließen. Die Clients auf dem Bild sind exemplarisch, Linux-Maschinen und haben feste IP-Adressen. Das ipv4-Routing ist auf allen mit Routingaufgaben versehenen Servern enabled.

Die Router mit WAN-Adressen sind Fritzboxen (in Dachau und München) und eine Vodafone-Box in Bucharest.

Wenn ich jetzt von den Maschinen pinge stellt sich die Situation folgendermaßen dar:

Bambam -> AKK: OK
Bambam -> Checkov: NOK
Bambam -> Fred: OK
Bambam -> Asterix: NOK
Checkov -> AKK: OK
Checkov -> Fred: NOK
Checkov -> Picard: OK
Checkov -> Asterix: NOK
AKK -> Fred: NOK
AKK -> Checkov: OK
AKK -> Dobrinth: OK
AKK -> Asterix: NOK

Die LAN-Interfaces der VPN-Maschinen (Tuvok, Falballa, Bambam) können von den Servern (AKK, Barney, Asterix, Checkov) erfolgreich gepingt werden.

Daher vermute ich den Fehler im Routing. Hier sind die Routing-Tabellen von

Tuvok:
default 192.168.1.1 UGS 32081 1500 em0
127.0.0.1 link#5 UH 38 16384 lo0
192.168.1.0/24 link#1 U 22771 1500 em0
192.168.1.4 link#1 UHS 0 16384 lo0
192.168.2.0/24 192.168.254.2 UGS 0 1500 ovpns1
192.168.3.0/24 link#2 U 3051 1500 em1
192.168.3.1 link#2 UHS 0 16384 lo0
192.168.4.0/24 192.168.254.2 UGS 0 1500 ovpns1
192.168.254.0/24 192.168.254.2 UGS 10 1500 ovpns1
192.168.254.1 link#8 UHS 0 16384 lo0
192.168.254.2 link#8 UH 22307 1500 ovpns1
Bambam:
default via 192.168.4.1 dev wlan0 src 192.168.4.2 metric 302
192.168.1.0/24 via 192.168.254.1 dev tun0
192.168.2.0/24 via 192.168.254.1 dev tun0
192.168.3.0/24 via 192.168.254.1 dev tun0
192.168.4.0/24 dev wlan0 proto dhcp scope link src 192.168.4.2 metric 302
192.168.254.0/24 dev tun0 proto kernel scope link src 192.168.254.3
Falballa:
default via 192.168.2.1 dev wlan0 src 192.168.2.4 metric 302
192.168.1.0/24 via 192.168.254.1 dev tun0
192.168.2.0/24 dev wlan0 proto dhcp scope link src 192.168.2.4 metric 302
192.168.3.0/24 via 192.168.254.1 dev tun0
192.168.4.0/24 via 192.168.254.1 dev tun0
192.168.254.0/24 dev tun0 proto kernel scope link src 192.168.254.2
Akk:
default via 192.168.3.1 dev eth0 src 192.168.3.11 metric 202
192.168.3.0/24 dev eth0 proto dhcp scope link src 192.168.3.11 metric 20
Checkov:
default via 192.168.1.1 dev ens18 onlink
192.168.1.0/24 dev ens18 proto kernel scope link src 192.168.1.11
192.168.2.0/24 via 192.168.1.4 dev ens18
192.168.3.0/24 via 192.168.1.4 dev ens18
192.168.4.0/24 via 192.168.1.4 dev ens18
Picard:
default via 192.168.1.1 dev bond0 proto static metric 300
192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.247 metric 300
192.168.2.0/24 via 192.168.1.4 dev bond0
192.168.3.0/24 via 192.168.1.4 dev bond0 proto static metric 300
192.168.4.0/24 via 192.168.1.4 dev bond0 proto static metric 300

Was ich hier nicht verstehe ist, warum Tuvok (der pfSense-Router) den Traffic aus dem VPN in das 192.168.1er-Netz nicht durchreicht, in das 192.168.3er-Netz jedoch schon.

Hat jemand von Euch vielleicht eine Idee woran es liegen kann?

JeGr

@callya Ohne mehr Regeln und Details zu kennen schwierig.

Mein primärer Tipp wäre auf das asymmetrische Routing. Macht man nicht, macht immer Probleme. Egal ob jetzt kommt "ja aber bei mir..." oder "mit anderen geht das..." - asymmetrisches Routing kann und wird immer doofe Probleme machen die man nicht wirklich abschätzen kann. Daher vermeidet man es.

Da du nur von irgendwelchen "VPN Maschinen" schreibst und ich nicht weiß was Bambam und Falballa bspw. sind und ob die wirklich nur VPN machen, kann ich kein Allheilmittel nennen. Wenn das wirklich nur VPN Nodes sind, würde ich sie in eine extra DMZ mit anderer IP Range stecken, damit von dort auch wirklich ALLES geroutet wird und kein Traffic asymmetrisch zu Clients direkt läuft deren Antwort aber wieder über einen Router/Gateway läuft.

Wenn das alles 3 pfSensen sind, dann würde ich die ISP Anbindung mit den Fritzen und Vodafone Boxen ändern und dort ein Transfernetz bauen damit die pfSensen alle direkt in einer Linie hinter den Upstream Routern stehen und vor allem LAN Traffic. Dann läuft alles an Paketfluß über die Kisten und man weiß ganz genau, dass - so alles korrekt eingestellt ist - alles sauber durchgeroutet wird. Dann muss nur noch Regelwerk und VPN Config passen und man hat gewonnen.

Cheers
\jens

Callya

Danke für den Tipp. Eine Umstellung vom asymmetrischen Routing ist nicht möglich. Die Fritzbox in München und die Vodafone-Box sind vom Provider "kastriert".

Die am VPN beteiligten Maschinen sind:

Tuvok: eine VM mit pfSense
Falballa und Bambam: je ein Raspberry Pi Zero mit aktuellem Raspbian ohne weitere Dienste

Was ich allerdings ändern kann wäre ein zusätzliche pfSense-VM in Dachau, die in einem eigenen Netz hängt und Tuvok als default gateway benutzt.

Callya

Habe das Problem gelöst.

Auf den Clients hat die route:
192.168.254.0/24 via 192.168.2.4 dev eth0
gefehlt.

Die Ping-Antwort (ICMP reply) wurde vom empfangenden System magels route versucht über das default-Gateway zu routen. Diese sind aber die WAN-Router und nicht die OpenVPN-Server.

Nur im 192.168.3er-Netz ist das default-GW der pfSense-Router, der auch VPN-Server ist. Daher hat es hier funktioniert.

JeGr

@callya Ah das geht natürlich auch. Normalerweise hat man im Default GW dann die Route zum VPN Server drin damit der es weiterrouten kann. In deinem Setup wäre dann aber asymmetrisches Routing entstanden was sich mehrfach mies auswirken kann. Man kann aber natürlich auch auf den Clients das GW eintragen, dann senden die es direkt dahin. Ist aber in den meisten Fällen zu viel Arbeit weil jeder Client angefasst werden muss.

Alternative dazu noch möglich: via DHCP eine zusätzliche Route pushen, hängt dann aber vom GW ab, ob das diese Möglichkeit hat. Das müsste - wenn man das mit der pfSense machen wollen würde - die DHCP Option 121 sein wenn ich recht entsinne. Ist dann nur etwas "Gefriemel", da man DHCP Option 121 als "string" konfigurieren muss und da nicht einfach IP Netz und Maske reinklöppeln kann.

FYI: Wenn man DHCP Option 121 manuell konfigurieren möchte, muss das Format des Strings in pfSense so aussehen:

0xMMZZZZZZZZGGGGGGGG

Wobei die Buchstaben als Platzhalter stehen für:

M = Subnetz Maske in CIDR Notation in Hexadezimal, also /24 -> 18
Z = Zielnetz in Hexadezimal                      172.16.1.0 -> AC100100
G = Gateway über den geroutet wird in Hex     192.168.1.254 -> C0A801FE

das wird zusammengesetzt nach RFC 3442, was heißt, dass die unnötigen Bits weggelassen werden müssen (kompakte Schreibweise).

Somit:

Für 172.16.1.0/24 via 192.168.1.254:
DHCP Option 121: 18:AC:10:01:C0:A8:01:FE

Man kann natürlich auch mehrere Routen angeben, die werden dann einfach aneinander gehängt. Da würde ich aber stark empfehlen vorher die Netzplanung gut zu machen, dann muss man da ggf. nur ein größeres Netz routen (bspw. 172.16.x.y -> /16 routen für alle VPN Ziele). Man muss bei der Hex-Schreibweise dann aufpassen, dass man bei der Kompaktschreibweise wirklich nur die notwendigen Bits schreibt, sonst wird das GW falsch ausgelesen :)

Cheers
\jens