Routing Openvpn über LTE und Fritzboxen

orcape

/var/etc/opnvpn/server1.conf

…sieht OK aus.

/var/etc/opnvpn-csc

…sieht OK aus.

/var/etc/opnvpn/client1.conf

Die existiert nicht im Verzeichnis auf dem Server.

…kann ja nicht, da musst Du schon auf dem Client gucken.. ;D

peter808

@orcape:

…kann ja nicht, da musst Du schon auf dem Client gucken.. ;D

Ups, die Transferleistung hatte ich vorhin auf die schnelle nicht erbracht ::) An die Datei komme ich aber erst wieder heute Abend.

Hast Du (auch ohne Kenntnis der client-Datei) eine Vermutung, wo das Problem sonst liegen könnte?

orcape

Hast Du (auch ohne Kenntnis der client-Datei) eine Vermutung, wo das Problem sonst liegen könnte?

Zum einen brauchst Du für Remote auch Firewall Regeln, die dir erlauben vom Tunnel auf das remote Netz zu kommen und für den WAN-Port eine für den Tunnelport.
Bei meiner Config, clientseitig (DD-WRT Router), hatte ich Dir diese schon gepostet.
Dann hast Du einen Tunnel laufen, der mit den remoten IP´s 10.0.8.6 10.0.8.5 ausgestattet ist.
Normalerweise sollte das bei einem Point-to-Point am Client nur die 10.0.8.2 sein. !!!
Ich hatte das Problem auch schon und habe dann keinen direkten Zugriff auf´s remote Netz bekommen, zumindest keinen direkten.
Das heißt, wenn Du per ssh in der Lage bist, Dich auf die IP 10.0.8.6 zu verbinden.
Damit wärst Du auf der remoten pfSense und solltest Dich von da aus auch auf die remote LAN-IP 172.23.200.1 (wenn das die Router-IP des remoten LAN ist) bzw. auf einem Client (FW aus) des remoten LAN einloggen können.
Wenn das so funktioniert, steht der Tunnel, ist aber ein Multiclienttunnel. (siehe einen der vorherigen Post von mir)
So kommst Du nicht direkt auf´s remote LAN, also muss da noch irgendwas an Deiner config nicht stimmen.
Ich tippe aber mal trotzdem auf den Server bzw. Client-Spezific-Overrides im GUI.
Bring trotzdem mal die Client-conf….
Gruß Peter

peter808

hier die client1.conf:

dev ovpnc1
verb 2
dev-type tun
tun-ipv6
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 udp
cipher BF-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.10.3
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote xxx.dyndns.org 1194
ifconfig 10.0.8.2 10.0.8.1
route 172.23.1.0 255.255.255.0
ca /var/etc/openvpn/client1.ca 
cert /var/etc/openvpn/client1.cert 
key /var/etc/openvpn/client1.key 
resolv-retry infinite

peter808

@orcape:

Zum einen brauchst Du für Remote auch Firewall Regeln, die dir erlauben vom Tunnel auf das remote Netz zu kommen und für den WAN-Port eine für den Tunnelport.

Die hatte ich auch auf client-Seite für den Port 1194 auf WAN und OpenVPN-Seite doch erstellen lassen, meinst Du die?

@orcape:

Dann hast Du einen Tunnel laufen, der mit den remoten IP´s 10.0.8.6 10.0.8.5 ausgestattet ist.
Normalerweise sollte das bei einem Point-to-Point am Client nur die 10.0.8.2 sein. !!!

Und wie kann ich das ändern? Ich muss doch im Webconfig für den Tunnel einen Adressbereich angeben, eine einzelne IP nimmt er nicht.

orcape

Und wie kann ich das ändern?

Gute Frage, nächste Frage…

Ich muss doch im Webconfig für den Tunnel einen Adressbereich angeben, eine einzelne IP nimmt er nicht.

Richtig, bei Dir…

10.0.8.0/24

Die Clientconfig sieht ja nicht schlecht aus, bis auf 2 Einträge.
Leider kann ich die nur mit DD-WRT vergleichen…

ca /tmp/openvpncl/ca.crt
cert /tmp/openvpncl/client.crt
key /tmp/openvpncl/client.key
management 127.0.0.1 16
management-log-cache 100
verb 3
mute 3
syslog
writepid /var/run/openvpncl.pid
client
resolv-retry infinite
nobind
persist-key
persist-tun
script-security 2
dev tun1
proto udp
cipher aes-128-cbc
auth sha1
remote "statische-IP" 1194
comp-lzo yes
tls-client
tun-mtu 1342
mtu-disc yes
ns-cert-type server
fast-io
tun-ipv6
tls-auth /tmp/openvpncl/ta.key 1
tls-cipher TLS-RSA-WITH-AES-128-CBC-SHA

Im Client GUI hast Du hoffentlich nur den Client konfiguriert und nicht noch Advanced-Einträge ?
Das…

ifconfig 10.0.8.2 10.0.8.1
route 172.23.1.0 255.255.255.0

…ist Server-Sache und gehört da eigentlich nicht rein.

peter808

DU BIS MEIN HELD ! ES LÜPPT !!!!

Also:

@orcape:

Und wie kann ich das ändern?
Gute Frage, nächste Frage…

Ich habe den Adressbereich mit 10.0.8./31 auf zwei IP-Adressen beschränkt

Und dann:

@orcape:

Das…
ifconfig 10.0.8.2 10.0.8.1
route 172.23.1.0 255.255.255.0
…ist Server-Sache und gehört da eigentlich nicht rein.

…diese von Dir genannten Einträge im config-file auskommentiert.

Nun läuft das VPN beidseitig mit allem, was wir brauchen (RDP, SSH etc.).

NOCHMALS TAUSEND DANK :) :) :) :) :) :) :) :) :) :) :) :) :)

orcape

Ich habe den Adressbereich mit 10.0.8./31 auf zwei IP-Adressen beschränkt

..und ich korrigiere mal.

10.0.8.0/31–- >---10.0.8.0/31

…ich muss Deinen Optimismus nur ein ganz klein wenig dämpfen... ;)
Mit der Änderung auf die /31 er Netzmaske, hast Du den Server gezwungen sich auf 2 IP's zu beschränken.
Es liegt da immer noch ein Konfigurationsproblem vor... :(

ifconfig 10.0.8.2 10.0.8.1
route 172.23.1.0 255.255.255.0

…und wenn Du die pfSense rebootest, hast Du das Problem wieder. Irgenwo müssen diese Einträge aus der GUI-Client Config kommen.
...das Du aber auch noch hin bekommst.. ;)
Wenn's noch Fragen gibt, kein Thema...

NOCHMALS TAUSEND DANK :) :) :) :) :) :) :) :) :) :) :) :) :)

Gerne doch und Danke für die Blumen…;)

peter808

@orcape:

Es liegt da immer noch ein Konfigurationsproblem vor… :(
ifconfig 10.0.8.2 10.0.8.1
route 172.23.1.0 255.255.255.0
…und wenn Du die pfSense rebootest, hast Du das Problem wieder. Irgenwo müssen diese Einträge aus der GUI-Client Config kommen.

Habe ich nun auch gelöst: die beiden Einträge waren im client-GUI unter "Tunnel settings" eingetragen (wo sie scheinbar nicht hin gehörten ;) )

peter808

Ein "kleines" Problem bleibt: der Tunnel wurde vorher - als noch keine Daten zwischen den Standorten flossen - immer im GUI mit grünem Pfeil und als "up" inkl. Verbindsbeginn dargestellt.

Nun steht hier plötzlich (obwohl ja alles lüppt):

1. im GUI/dashboard des client ein roter Pfeil (down) und:
Client UDP Unable to contact daemon
0 Service not running?

2. und im VPN-log der Zentrale steht alle Paar Sekunden:
openvpn[53950]: MANAGEMENT: Client disconnected
openvpn[53950]: MANAGEMENT: CMD 'state 1'
openvpn[53950]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock

Im client gibt es keine Fehlermeldungen im log.

Und das alles, obwohl die VPN-Verbindung stabil läuft…

orcape

Ein "kleines" Problem bleibt: der Tunnel wurde vorher - als noch keine Daten zwischen den Standorten flossen - immer im GUI mit grünem Pfeil und als "up" inkl. Verbindsbeginn dargestellt.

..und das Problem löst Du erst, wenn Du den Tunnel nicht mit einer /31 er Netzmaske zum arbeiten zwingst.
So ein Tunnel ist sensibel und will eine /24 er Netzmaske, wenn er damit funktioniert, hast Du dann auch Deinen letzten Fehler ausgemerzt.
Dann ist auch Dein Tunnel nett zu Dir und beschwert sich nicht mehr…. ;D
Gruß Peter

peter808

Das ist bei mir leider nicht so.

Stelle ich auf /24er, kommt die Verbindung zwar zustande, es fließen aber wieder keine Daten zwischen den Standorten.

Nur wenn ich auf /31er stelle, ist die VPN-Verbindung voll nutzbar (gerade nochmals getestet).

orcape

Das ist bei mir leider nicht so.

…dann überprüfe noch mal Deine GUI Einstellungen auf dem Client.
Irgendwo müssen die nun auskommentierten Einträge ja eingegeben worden sein.
Gruß Peter

peter808

Da reden wir jetzt gerade aneinander vorbei.

Auskommentiert im conf-file bzw. jetzt am Client im GUI gelöscht hatte ich die Einträge gem. meinem Posting #26.

Die Einträge zu den netmasks (24er oder 31er) habe ich nur über das GUI auf dem Server geändert unter Tunnel Settings >
IPv4 Tunnel Network.

orcape

Auskommentiert im conf-file bzw. jetzt am Client im GUI gelöscht hatte ich die Einträge gem. meinem Posting #26.

…ist jetzt klar.

Die Einträge zu den netmasks (24er oder 31er) habe ich nur über das GUI auf dem Server geändert unter Tunnel Settings >
IPv4 Tunnel Network.

Du musst trotzdem versuchen mit einer /24 er Netzmaske klar zu kommen.
Da muss noch ein anderer Fehler sein. Logs anschauen, testen kleiner Veränderungen. etc.
Gruß Peter