Routing von extern in ein VPN-Netz …

bitboy0

Irgendwas hab ich vergessen, aber ich finde nicht was.

Ich habe ein lokales Netz 10.10.10.0/24 und daran über VPN mehrere Netze mit 192.168.x.0/24
Als Tunnel-Netz benutze ich 10.10.91.0/24

vom Lokalen Netz erreiche ich sowohl die VPN-Router über die Adresse(n) 10.10.91.x/24 als auch die Geräte hinter dem Router über die Adressen 192.168.x.0/24

Von den VPN-Geräten erreiche ich ebenfalls die lokalen Netzwerkgeräte unter 10.10.10.x/24

Aber wenn ich von extern NAT einrichte um z.B. über http://vpn.domain.de:20080 das Gerät 10.10.91.11 auf Port 80 erreichen zu können kommt keine Verbindung zustande.
Nach dem gleichen Schema eingerichtete weiterleitungen auf Geräte aus dem internen Netz (z.B. 10.10.10.1) funktionieren.

Ich schätze, irgendwo fehlt ein Routing?

flix87

Ich vermute jetzt mal dann müsstest du im VPN Server den hacken bei
Redirect Gateway
Force all client generated traffic through the tunnel.
setzen.

Nur selbst dann weiß ich nicht genau ob das so gehen kann.
Aber ohne den Hacken kennt der VPN Client ja die Rückroute nicht.
Versuch es mal.

viragomann

@bitboy0:

Aber wenn ich von extern NAT einrichte um z.B. über http://vpn.domain.de:20080 das Gerät 10.10.91.11 auf Port 80 erreichen zu können kommt keine Verbindung zustande.

Ja, die Antworten von 10.10.91.11 gehen auf die Quelladresse, also auf die öffentliche IP des Geräts, mit dem du die Verbindung aufbauen möchtest. Und die Pakete von dem Gerät hinter der VPN auf diese öffentliche Quell-IP werden eben über das Default-Gateway geroutet, also direkt ins Internet. Auf dem Router da gibt es aber keine Verbindung, die auf diese Antwort wartet, also wird sie meist verworfen.

Mit Routing ist das nicht in Griff zu bekommen. Hier hilft Outbound NAT an der Eingangsseite der VPN.
Gehe auf Firewall > NAT > Outbound, aktiviere "Hybrid Outbound NAT rule generation" und klick mal auf Save. Dann füge unten eine solche Regel hinzu: Interface=OpenVPN, Source=any, Translation=Interface address

Damit wird die Quelladresse auf die VPN-Interface Adresse transferiert, und diese ist auf der anderen Seite der VPN bekannt, so dass die Antwortpakete auch wieder den richtigen Weg zurückfinden. Die pfSense hier hat die Verbindung gespeichert und ändert die Zieladresse entsprechend über NAT.

bitboy0

Auf dem bisherigen Server (Hosteurope) war ein RINETD installiert … der hat das übernommen.
Gibt es das auch für die Sense? Das war vermutlich der beste Weg!

http://www.lenzg.net/rinetd/rinetd.html

Mit den geänderten Outbound-NAT-Regeln geht es jedenfalls noch nicht.

flix87

Die Idee von Viragomann ist natürlich sehr gut :)

Hast du mal mit Wireshark Trace gemacht welche IP beim openvpn Client ankommen? So siehst du ja ob die NAT greift und richtig ein gestellt ist.

bitboy0

Die Idee mag gut sein, aber es geht leider nicht.

Zumindestens noch nicht. Ich werde mal alles noch mal auf den Kopf stellen und systematisch untersuchen wo das klemmt …

viragomann

@bitboy0:

Auf dem bisherigen Server (Hosteurope) war ein RINETD installiert … der hat das übernommen.

Das macht ja nicht mehr als pfSense nativ kann. Warum soll es das als Extra für pfSense geben?

Wie flix87 erwähnt hat, wenn es nicht klappt, schau dir mal die Pakete auf beiden Seiten an. Du kannst dazu auch das "Packet Capture" aus dem Diagnostic Menu der pfSense verwenden. Da musst du allerdings das OpenVPN Interface auswählen, am WAN sind die Pakete nicht zu sehen.

bitboy0

Also wenn ich aus dem Lokalen Netz zugreife, dann kann ich Pakete auf dem VPN interface fangen …

Ich hab das NAT so eingerichtet, wie ich es für die Dienste auf dem Server auch gemacht habe.
10.10.11.254 ist die vIP des WAN ... ist ja ein CARP aus zwei Sensen

IF_WANKABEL TCP * * 10.10.11.254 21 (FTP) 10.10.10.1 21 (FTP)
IF_WANKABEL TCP * * 10.10.11.254 20043 192.168.4.3 80 (HTTP)

eine passende Filterregel hat er automatisch angelegt.

Unter Outbound-NAT habe ich angelegt:
OpenVPN any * * * OpenVPN address * NO

Die erste Regel ist für unseren FTP ... das klappt sofort. Die Zweite ist für eine Webcam, aber da kommt im Packet Capture nichts an.

gruß

viragomann

@bitboy0:

Die erste Regel ist für unseren FTP … das klappt sofort. Die Zweite ist für eine Webcam, aber da kommt im Packet Capture nichts an.

Auf welche Seite der VPN? Zumindest auf der Eingangsseite musst du die Pakete sehen, sonst hat es da was mit dem Routing oder den Regeln.
Wenn sie auf der Eingangsseite da sind, sollte sie auch auf der anderen Seite zu sehen sein.

bitboy0

Ich hab auf dem passenden oVPN geschaut.

wenn ich intern von 10.10.10.0/24 über 10.10.91.0/24 auf 192.168.4.0/24 gehe habe ich alle Verbindungen und es kommen alle pakete an
Wenn ich extern von WANKABEL vIP (das ist die 10.10.11.254) zu 192.168.4.3 weiterleite passiert schlicht GAR NICHTS dort.

also die Pakete werden demnach nicht weitergeleitet und können deswegen auch nicht beantwortet werden.

aber warum? Eine einfach Portweiterleitung habe ich ja zig mal gemacht, nur da war das Ziel im lokalen Netz, also meistens 10.10.10.1
Passende Filter werden normal ja auch angelegt, wenn man das nicht absichtlich unterbindet.

Die NAT-Regeln siehst du ja in meinem letzten Post .. einmal für FTP und einmal die Webcam. Sieht für mich beides gleich aus, ausser eben die Adresse des Rechners, zu dem das geht

viragomann

Demnach scheint es ja, als ob die Pakete von extern in das 192.168.4.0/24 Netz gar nicht über die VPN geroutet werden würden. Also dafür ist dein NAT verantwortlich.
Aber am WAN Interface siehst die Pakete?

Übrigens hast du unterschiedlich Ports für das Problem genannt. Ich denke, du wirst das mal geändert haben, aber bitte bestätigen, damit du nicht an dem panalen Problem anstehst.
In deinem ersten Post hast du geschrieben:
@bitboy0:

Aber wenn ich von extern NAT einrichte um z.B. über http://vpn.domain.de:20080 das Gerät 10.10.91.11 auf Port 80 erreichen zu können kommt keine Verbindung zustande.

Und in der NAT Regel:
@bitboy0:

IF_WANKABEL TCP * * 10.10.11.254 20043 192.168.4.3 80 (HTTP)

bitboy0

Das sind ganz unterschiedliche Geräte, deswegen die Differenzen bei den Ports.

Also Pro Anlage sind es:

10.10.90.x:80 (Router Webinterface)
192.168.x.1:80 (Router Webinterface von innerhalb des Remote Netz)
192.168.x.2:443 (PC mit SSL/Webserver)
192.168.x.3:80 (Webcam)
192.168.x.4:80 (Temperatur/Feuchte-Sensor)

von Außen geht das über eine Folge von Ports.

20xx1 - 20xx4 wobei xx / x sich aus der Anlagenummer ableiten lässt.

So sieht es aus, wenn ich von außen auf Port 20043 anklopfe.
Ich habe nach der IP des abrufenden Mobilgerätes gefiltert, also hätte auch jede Antwort da ankommen müssen.

20:11:35.506737 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:11:36.458707 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:11:36.787339 IP 89.204.154.204.1131 > 10.10.11.254.20043: tcp 0
20:11:38.466009 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:11:41.666584 IP 89.204.154.204.18030 > 10.10.11.254.20043: tcp 0
20:11:42.486152 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:11:50.547159 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:12:06.694103 IP 89.204.154.204.3998 > 10.10.11.254.20043: tcp 0
20:12:09.131250 IP 89.204.154.204.18030 > 10.10.11.254.20043: tcp 0

Auf dem VPN kommt währenddessen nichts an … gar nichts.

Wenn ich aus dem Lokalen Netz hier auf das zugehörige Gerät zugreife klappt es und ich sehe auf dem VPN die Pakete.

bitboy0

Also einfache Zusammenfassung:

Die Pakete vom LAN werden erfolgreich in das VPN geschoben und die Antworten kommen auch zurück.
Die Pakete vom WAN werden empfangen, aber ich kann nicht erkennen, was dann damit passiert. Im VPN kommen sie jedenfalls nicht an und deswegen kann es auch nicht beantwortet werden. Ob dann die Translation funktioniert, kann ich deshalb auch nicht prüfen.

Ich habe die NAT-Regel genau so angelegt, wie es auch für die NAT-Regeln für die Serverdienste auf dem Server im LAN … Dazu passend hat die Sense jeweils eine Firewall-Rule automatisch erzeugt.

Irgendeiner eine Idee, wo die Pakete sterben?

viragomann

@bitboy0:

Die Pakete vom WAN werden empfangen, aber ich kann nicht erkennen, was dann damit passiert. Im VPN kommen sie jedenfalls nicht an und deswegen kann es auch nicht beantwortet werden. Ob dann die Translation funktioniert, kann ich deshalb auch nicht prüfen.

Wie schon oben erwähnt, die Pakete vom WAN werden offenbar nicht auf das 192.168.4.0/24 Netz geroutet.
Das kann an NAT oder an den Firewall Regeln liegen.
Die Route in dieses Netz muss ja wohl gesetzt sein, ansonsten würde es vom LAN aus auch nicht funktionieren.

Ich habe das eben bei mir einmal durchgetestet, was bei dir nicht funktionieren soll. Ich habe allerdings den eingehenden Traffic per NAT Regel direkt auf die VPN-IP weitergeleitet. Dafür dass das auch mit dem Netz dahinter klappt, ist eben die Route zuständig, und die ist ja in Ordnung.
Ich habe Paket Capture auf der pfSense (Server) laufen lassen, erst auf WAN, da sehe ich die Pakete eben in der Art:
Quell-IP:Quell-Port > ext. Ziel-IP:20020
Dann auf dem OpenVPN Interface
Quell-IP:Quell-Port > InNAT-IP:80
Eine Verbindung kam da nicht zustande, weil die Antwortpakete nicht zurückkamen.

Dann das Outbound NAT, wie erwähnt, eingerichtet. Dann sieht es so aus:
OVPN-Server-IP:40831 > InNAT-IP:80
InNAT-IP:80 > OVPN-Server-IP:40831
Und ich konnte mich auch mit meinem lokalen Webserver über den externen Port 20020 verbinden.

Dein Problem habe ich oben schon eingegrenzt. Wirf noch einen genauen Blick auf die Firewall Regeln und beachte, die werden nach dem Prinzip 'first match win' abgearbeit, also nur die erste Regel von oben, die die Bedingungen des eingehenden Pakets erfüllt, wird auch angewandt. Möglicherweise wird da die automatisch generierte Regel, die ganz unten angefügt wird, bereits ausgestochen.
Beachte auch die Floating rules.
Wenn dich das nicht weiterbringt, schalte sämtliches Logging ein und prüf die Firewall-Logs nach den verlorenen Paketen.

Mehr kann ich aus den mageren Information, die du uns bisher zögerlich geliefert hast, leider nicht erahnen.

bitboy0

Puhhhhh!

Also du hast mir SEHR geholfen … ich hab den Wald vor lauter Bäumen nicht gesehen.
Ein anderer Dienst auf einem anderen Server benutzt ausgerechnet diesen Portbereich für seinen Zweck... und natürlich war der in den NAT-Regeln darüber angeordet und hat so alle Anfragen abgefangen.
Das ist mir etwas peinlich, denn ich hab die Natregeln sicher 100 Mal durchgesehen und habe es nicht bemerkt! :o :(

Jetzt geht es ... aber ich hab noch ein anderes Problem und da mache ich ein anderes Thema dafür ...

viragomann

Na endlich, ein Erfolg in der Sache. Gratuliere.

@bitboy0:

Das ist mir etwas peinlich, denn ich hab die Natregeln sicher 100 Mal durchgesehen und habe es nicht bemerkt! :o :(

Wenn es viele Regeln sind, verwende ich hier die Suchfunktion des Browsers, bspw. nach dem Port, der nicht funktioniert. Doch funktioniert das auch nur, wenn der Port explizit angegeben ist, Aliases müssen alle einzeln geöffnet werden, damit man sieht, was sich dahinter verbirgt.

Doch die Packet Capture Funktion von pfSense tut in solchen Fällen immer hilfreiche Dienste.

bitboy0

Es war halt ein Portbereich… da war der Port mit eingeschlossen, aber nicht genau so in der Liste angegeben. Deswegen hab ich den in der Suche auch nicht finden können.
Aber ich hätte da schon auchselber drauf kommen müssen, finde ich ... das ärgert mich, wenn ich dann so viel Zeit verplempere und dabei ist der Fehler direkt vor der nase :(