[solved] OpenVPN als Portmapper

JeGr

@Bob-Dig said in OpenVPN als Portmapper:

In OVPN hatte ich eine erlauben any Regel. Ein Gateway habe ich aber glaube ich nicht gehabt, nur den OVPN-Server als Interface in der Sense...
Wo war wahrscheinlich mein Fehler?

Ohne Bilder schwierig zu raten, aber gerade bei Windows wären meine Steps gewesen:

Prüfen ob die Windows Firewall an ist
Ggf. das OVPN Tunnel Netz und dein Remote Netz / LAN als IP Range in der WinFirewall eintragen und erlauben (sonst ist alles was nicht !localnet ist abgelehnt)
Mal ohne WinFirewall testen
RDP sollte theoretisch auch auf der TunnelIP funktionieren, also bei Tunnelnetz 10.0.8.0/24 ist ja 1 oder 2 bei S2S der Winserver, also darauf mal die RDP Verbindung getestet (schauen ob RDP auf alle IPs hört!), anschließend nochmal auf seine LAN IP versuchen
Test ob simpler Ping ankommt
Wireshark o.ä. auf Windows Kiste werfen und mitloggen, schauen ob Ping oder andere Pakete auf dem tun0/VPN Tunnel ankommen

Könnte eventuell nur Windows selbst gewesen sein, eventuell auch das Routing Setting beim Tunnel (local-net/remote-net bei den Tunneleinstellungen - die müssen auf beiden Seiten natürlich passen, andernfalls policy based routing noch anpassen)

Bob.Dig

@JeGr Win-Firewalls hatte ich alle aus. Tunneleinstellungen, nun ja auf dem VPS habe ich ja quasi keine Netze. Policy Routing habe ich jetzt, also mit der alten Konfig, die ich wiederherstellen konnte, auch nicht, ich greife einfach auf die private IP des Servers zu. Wäre das bei S2S anders? Vielleicht fällt Dir ja noch was ein. Ich mache doch bestimmt die simpelsten Anfänger Fehler.

JeGr

wie gesagt, schauen ob RDP auf der TunnelIP geht. Wenn die Kiste als VPS bspw.

a.b.c.d

hat (wobei das ne public IP ist) und du dahin deinen Tunnel aufbaust mit Site2Site und willst NUR den VPS erreichen, dann

muss auf Server/VPS Seite in der S2S config die Remote Netz Konfig auf die IP deines LANs von dem du zugreifst
TunnelNetz definiert sein
auf Client Seite kann man dann Remote IPs leer lassen und lokal auf das LAN setzen

Wenn aufgebaut müsste:

pfSense die TunnelIP pingen können (ihre eigene und die andere Seite)
der VPS seine eigene TunnelIP und die Gegenseite pingen
der VPS die LAN Devices (wenn auf der pfSense auf dem OVPN Interface Regeln existieren, die ankommenden Traffic erlauben)

Das sollte es eigentlich sein um nur den VPS zu bekommen.

Bob.Dig

@JeGr said in OpenVPN als Portmapper:

muss auf Server/VPS Seite in der S2S config die Remote Netz Konfig auf die IP deines LANs von dem du zugreifst

Danke Jens, das hatte gefehlt.

Ich poste das hier mal in der Hoffnung, es bei Bedarf wiederzufinden.
route 192.168.1.0 255.255.255.0
route 192.168.10.0 255.255.255.0

Gibt es eine Empfehlung, welche Encryption Algorithm und Auth digest algorithm bei S2S zu nutzen sind?

Dieser Setup ist wirklich so deutlich einfacher als der andere, wenn man denn das mit der Route weiß und/oder man per SSH die entsprechenden Dateien auf der Sense gefunden hat.

Rico

Ich nutze für alle Tunnel AES-256-GCM/SHA256 und TLS Enc+Auth.

-Rico

Bob.Dig

@Rico Hey Rico,

bei S2S bzw. P2P mit Shared Key kann ich GCM nicht auswählen und speichern.

GCM Encryption Algorithms cannot be used with Shared Key mode.

Würde jetzt gerne dabei bleiben, weil so schön einfach, irgendwelche Empfehlungen oder unbedingt auf P2P SSL/TLS umsteigen?

Rico

Ah Shared Key.
Da würde ich AES-256-CBC/SHA256 machen.

-Rico

Bob.Dig

@Rico Ich werde besser TLS nehmen...

ECDH Curve default?

PS: Schade, beim P2P TLS-Server funktioniert der Client Export nicht, dafür hätte ich die IPv4 Local network(s) im GUI eintragen können...
Warum ... alles .... so ... kompliziert.

Rico

ECDH habe ich auf Default.
Und bevor die Frage kommt DH Parameter 2048 bit ;-)

EDIT: Ja, mit SSL/TLS kannst du Route pushen, das geht bei shared key nicht.

-Rico

Bob.Dig

@Rico said in OpenVPN als Portmapper:

EDIT: Ja, mit SSL/TLS kannst du Route pushen, das geht bei shared key nicht.

Gibt es dafür ne logische Erklärung? Wahrscheinlich...
Wenn ich den "guten" P2P-TLS Server will, muss ich wohl leider die Client-Config selbst schreiben. Ich weiß, die sehen alle ähnlich aus, aber trotzdem, warüm?

Rico

Naja, du kannst dir den passenden Client als dummy auf der pfSense zusammenbauen und dann die Config aus /var/etc/openvpn holen. ;-)

-Rico

Bob.Dig

@Rico Ach scheiß drauf, shared key und gut ist.
Danke!

JeGr

AES256GCM-SHA256-ECDH-only mit secp384r1

wenn GCM nicht möglich dann CBC. Wenn man schwache HW hat, kann man ggf auf 128 runter, aber das macht kaum noch was aus heute. DH wird kaum noch gemacht. DH Params <=2k sind auch nicht mehr safe.

Bob.Dig

Neue Probleme haben sich aufgetan.

Zur Erinnerung, ich habe jüngst einen OVPN Server (P2P - Shared Key) auf der pfSense @home erstellt. Anschließend auf einem Windows VPS den Key exportiert und dort in OVPN geladen. Nun baut dieser VPS die Verbindung zu meiner pfSense auf. Das geht. Ich kann auch per RDP auf den VPS verbinden, nachdem ich dort routes angelegt hatte.

Was nun entgegen dem früheren Setup, wo der OVPN-Server noch auf dem VPS war, aber nicht mehr geht ist das Ausleiten von bestimmten Internet-Traffic @home über den VPS.

Ich vermute nun leider, das ist völlig normal, weil ja jetzt der Server auf der Sense ist.
Was sind meine Optionen?

Rico

Das OpenVPN Interface hast du hinzugefügt und nutzt es als Gateway in einer Firewall Regel?
Was genau funktioniert denn dann nicht?

-Rico

Bob.Dig

@Rico Ja, ist hinzugefügt, so wie vorher, als es als Client auf der pfSense realisiert war. Jetzt ist es aber halt als Server konfiguriert auf der Sense (P2P). Wenn ich eine Verbindung zum Ipv4 Internet aufbauen will, dann geht es nicht auf dem Host, wo ich die entsprechende Firewallregel anwende.

Kann ich das irgendwie retten? Vielleicht ein manueller Eintrag in der OVPN Config? Dieser müsste ich ja vermutlich sagen, dass Internet-Traffic über den Client(?) ausgeleitet werden soll. Klingt für mich auch eher unüblich.

Rico

Wer Server und wer Client ist spielt keine Rolle, du setzt ja das Gateway auf die andere Seite.
Outbound NAT Konfiguration vergessen?

-Rico

Bob.Dig

@Rico Outbound NAT Konfiguration auf der Sense habe ich nicht vergessen, sondern genauso gemacht, wie vorher auch. Ob das so aber richtig ist, kann ich nicht sagen.
Aber apropos, setze ich das Gateway wirklich auf die andere Seite? Es ist doch mein OVPNServer, den ich da gesetzt habe... das dürfte auch das Problem sein, oder?

Hier mal die config auf dem Windows VPS. Hier hatten ja schon die Routen gefehlt, vielleicht fehlt noch mehr:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA512
resolv-retry infinite
proto udp
remote XXX udp4
ifconfig 10.9.7.2 10.9.7.1
keepalive 10 60
ping-timer-rem
route 192.168.1.0 255.255.255.0
route 192.168.10.0 255.255.255.0
route 192.168.32.0 255.255.255.0
<secret>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
</secret>
comp-lzo no

Rico

Ich habs nun extra mal für dich getestet.

pfSense 1 mit einem WAN und LAN (192.168.203.0/24), hier läuft der OpenVPN Server PtP Shared Key und Test-Client im LAN (entspricht deiner Sense zuhause).
pfSense 2 mit einem WAN und LAN (192.168.204.0/24), hier läuft der OpenVPN Client, kein Client im LAN (entspricht deinem VPS).
Tunnelnetz 10.1.2.0/24 (für den Test eigentlich zu groß, aber egal).
pfSense 1 hat auf dem OpenVPN Interface IP 10.1.2.1 bekommen mit Gateway 10.1.2.2
pfSense 2 genau anders herum, Interface IP 10.1.2.2, Gateway 10.1.2.1

pfSense 1 Outbound NAT:

pfSense 1 bei der Default allow LAN to any rule das OpenVPN Gateway gesetzt. Bei pfSense 2 nichts weiter verändert.

Speedtest (Download aus dem Internet) mit dem Client der am LAN von pfSense 1 hängt:

pfSense 1:

pfSense 2:

-Rico

Rico

pfSense 2 OpenVPN Client config

dev ovpnc1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <pfSense 2 WAN IP>
lport 0
management /var/etc/openvpn/client1.sock unix
remote <pfSense 1 WAN IP> 1194 udp4
ifconfig 10.1.2.2 10.1.2.1
route 192.168.203.0 255.255.255.0
secret /var/etc/openvpn/client1.secret
compress
resolv-retry infinite

-Rico