Routing Openvpn über LTE und Fritzboxen
-
Der Eintrag…
client-to-client (hat nichts mit den Clients in Server+Client-LAN zu tun)
…in der Server.conf dient dem Herstellen eines Multiclienttunnels.
Ich stehe wieder ein bisschen auf dem Schlauch. Welchen "Eintrag" meinst Du? In der server1.conf findet sich so ein Eintrag nicht.
-
Ich stehe wieder ein bisschen auf dem Schlauch. Welchen "Eintrag" meinst Du? In der server1.conf findet sich so ein Eintrag nicht.
…den Eintrag benötigst Du nur, wenn Du an einem OpenVPN-Server mehrere OpenVPN-Clients betreibst und wenn diese -Clients miteinander kommunizieren sollen.
Das betrifft nicht Dein Szenario. Du verbindest nur 2 Netze über den Tunnel.
Da Du damit aber...
zum Bsp.: Client 3 vom Netz 192.168.23.0/24
mit Client 2 vom Netz 172.19.48.0/24
..verbinden kannst, wird....
client-to-client
…häufig falsch interpretiert und findet dann in einer Server.conf Verwendung, wo das gar nicht angebracht ist.
Also bei Dir, alles Tacco, Deine Config braucht kein client-to-client.
War wohl alles bissl viel auf ein mal…. ;D
Gruß Peter -
netstat -rn sagt:
Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.1.1 UGS em1 10.0.8.0/24 10.0.8.2 UGS ovpns1 10.0.8.1 link#8 UHS lo0 10.0.8.2 link#8 UH ovpns1 127.0.0.1 link#6 UH lo0 172.23.1.0/24 link#2 U em0 172.23.1.1 link#2 UHS lo0 172.23.200.0/24 10.0.8.2 UGS ovpns1 192.168.1.0/24 link#3 U em1 192.168.1.1 00:11:0a:53:3f:9b UHS em1 192.168.1.2 link#3 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::1 link#6 UH lo0 fe80::%em0/64 link#2 U em0 fe80::211:aff:fe53:3f9a%em0 link#2 UHS lo0 fe80::%em1/64 link#3 U em1 fe80::211:aff:fe53:3f9b%em1 link#3 UHS lo0 fe80::%lo0/64 link#6 U lo0 fe80::1%lo0 link#6 UHS lo0 fe80::%ovpns1/64 link#8 U ovpns1 fe80::230:5ff:fe20:9516%ovpns1 link#8 UHS lo0 ff01::%em0/32 fe80::211:aff:fe53:3f9a%em0 U em0 ff01::%em1/32 fe80::211:aff:fe53:3f9b%em1 U em1 ff01::%lo0/32 ::1 U lo0 ff01::%ovpns1/32 fe80::230:5ff:fe20:9516%ovpns1 U ovpns1 ff02::%em0/32 fe80::211:aff:fe53:3f9a%em0 U em0 ff02::%em1/32 fe80::211:aff:fe53:3f9b%em1 U em1 ff02::%lo0/32 ::1 U lo0 ff02::%ovpns1/32 fe80::230:5ff:fe20:9516%ovpns1 U ovpns1Hilft das?
-
Da passt was nicht wirklich…
Die Routen auf dem Server sind OK so.....
10.0.8.1 Server, 10.0.8.2 Client
Beim Clientlog taucht...usr/local/sbin/ovpn-linkup ovpnc1 1500 1541 10.0.8.6 10.0.8.5 initAbgesehen davon das eine MTU Größe von 1500 mal zu Problemen führen kann…
...poste mal bitte die Ausgabe von...netstat -rn…auf dem Client.
-
Ok, mache ich gerne nachher, wenn ich dort bin. Melde mich dann abends wieder. Danke.
-
hier vom client:
Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.10.1 UGS re0 10.0.8.1/32 10.0.8.5 UGS ovpnc1 10.0.8.5 link#7 UH ovpnc1 10.0.8.6 link#7 UHS lo0 127.0.0.1 link#5 UH lo0 172.23.1.0/24 10.0.8.5 UGS ovpnc1 172.23.200.0/24 link#1 U em0 172.23.200.1 link#1 UHS lo0 192.168.10.0/24 link#2 U re0 192.168.10.1 00:24:1d:2e:cc:08 UHS re0 192.168.10.3 link#2 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::1 link#5 UH lo0 fe80::%em0/64 link#1 U em0 fe80::1:1%em0 link#1 UHS lo0 fe80::%re0/64 link#2 U re0 fe80::224:1dff:fe2e:cc08%re0 link#2 UHS lo0 fe80::%lo0/64 link#5 U lo0 fe80::1%lo0 link#5 UHS lo0 fe80::6a05:caff:fe04:57d3%ovpnc1 link#7 UHS lo0 ff01::%em0/32 fe80::1:1%em0 U em0 ff01::%re0/32 fe80::224:1dff:fe2e:cc08%re0 U re0 ff01::%lo0/32 ::1 U lo0 ff01::%ovpnc1/32 fe80::6a05:caff:fe04:57d3%ovpnc1 U ovpnc1 ff02::%em0/32 fe80::1:1%em0 U em0 ff02::%re0/32 fe80::224:1dff:fe2e:cc08%re0 U re0 ff02::%lo0/32 ::1 U lo0 ff02::%ovpnc1/32 fe80::6a05:caff:fe04:57d3%ovpnc1 U ovpnc1 -
Hi,
so was in der Art hatte ich schon vermutet. :(
Du willst eine Point-to-Point Verbindung aufbauen, Server und ein remoter Standort, richtig ?
Dein Tunnel steht vermutlich, Du kommst aber nicht vom Server-LAN auf Client-LAN, richtig ?
Wie sieht Deine OVPN-Server-Seite in Bezug auf die Client-Spezific-Overrides aus ?
Poste mal noch die…- /var/etc/opnvpn/server1.conf
- /var/etc/opnvpn/client1.conf
- /var/etc/opnvpn-csc vom Server
Gruß Peter
-
Du willst eine Point-to-Point Verbindung aufbauen, Server und ein remoter Standort, richtig ?
Dein Tunnel steht vermutlich, Du kommst aber nicht vom Server-LAN auf Client-LAN, richtig ?Zwei mal ja.
/var/etc/opnvpn/server1.conf
dev ovpns1 verb 2 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.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.1.2 tls-server server 10.0.8.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc ifconfig 10.0.8.1 10.0.8.2 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'internal-ca' 1" lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 1 push "route 172.23.1.0 255.255.255.0" route 172.23.200.0 255.255.255.0 ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024- /var/etc/opnvpn/client1.conf
Die existiert nicht im Verzeichnis auf dem Server.
- /var/etc/opnvpn-csc
ifconfig-push 10.0.8.2 10.0.8.1 iroute 172.23.200.0 255.255.255.0 -
/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
-
…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?
-
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 -
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 -
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?
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.
-
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/24Die 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-SHAIm 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.
-
DU BIS MEIN HELD ! ES LÜPPT !!!!
Also:
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:
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 :) :) :) :) :) :) :) :) :) :) :) :) :)
-
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…;)
-
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 ;) )
-
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.sockIm client gibt es keine Fehlermeldungen im log.
Und das alles, obwohl die VPN-Verbindung stabil läuft…
-
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 -
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).