[Problem] OpenVpn erfolgreich eingerichtet. Leider ist außer der Fritzbox kein anderes Netz zu erreichen. ( Gleiches Problem mit Wireguard )

[michael_wl]

Hallo Leute,

ich komme mit meinem Problem nicht weiter. Habe OpenVpn erfolgreich am laufen. Verbindung wird aufgebaut vom Client zur FritzBox ohne Probleme.
Leider erreiche ich über diese Verbindung nur die Fritrzbox. Nichts geht über die Fritzbox raus als wie wenn ab dieser alles geblockt wird. Gleiches Problem hatte ich zuvor mit WireGuard.
Ich poste hier mal meine Einstellungen und Protokolle. Eventuell kann mir jemand den entscheidenden Tip geben.

Spoiler: Server Config

mode server
proto udp4
dev tun
tls-server
port 54201
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
keepalive 10 120

#auth SHA256
#ecdh-curve prime256v1
topology subnet
remote-cert-tls client
#tls-version-min 1.2
#tls-cipher AES256-SHA
#push "redirect-gateway def1"
#client-to-client
#syslog
#askpass "/tmp/flash/openvpn/stdin.txt"
auth-nocache

ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
crl-verify /tmp/flash/openvpn/crl.pem
#tls-auth /tmp/flash/openvpn/static.key 0
tls-crypt /tmp/flash/openvpn/static.key
#dh none
dh /tmp/flash/openvpn/dh.pem

user openvpn
group openvpn
#chroot /var/tmp/openvpn
log /var/tmp/debug_openvpn.out

server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 10.8.0.1"
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client

persist-tun
persist-key

Spoiler: Client Config

client
dev tun
proto udp4
remote mein.myddns.me 54201
resolv-retry infinite
nobind
remote-cert-tls server
#tls-version-min 1.2
#verify-x509-name raspberrypi-micha_ca7a0a7c-ff72-47ca-9757-f9dfccf2fad3 name
cipher AES-256-CBC
#auth SHA256
auth-nocache
verb 3
ifconfig 10.8.0.1 255.255.255.0
route 192.168.1.0 255.255.255.0
#askpass
#tls-cipher AES256-SHA
<ca>
-----BEGIN CERTIFICATE-----
MIIDaTCCAlGgAwIBAgIUKvQg/z4TjkEU/J8pd84On62POOYwDQYJKoZIhvcNAQEL
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIDbTCCAlWgAwIBAgIRANqob0GKT8T0rx+H3DE4xnAwDQYJKoZIhvcNAQELBQAw

-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDFU8Np6m6Djw3D

ewxwddmXKaXRPWQxKaTWYmo0
-----END PRIVATE KEY-----
</key>
<dh>
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEArpj5FojwffGkD2aobSi+D7wB+v+sQfM0ffFkFH7AIe+Kp+BzIITT

Mr3I4RnlECKIr3DwTXa+InB0YjCPvCWqIwIBAg==
-----END DH PARAMETERS-----
</dh>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
c1c6ad6984b2d43b0c9094e731c8af6d
-----END OpenVPN Static key V1-----
</tls-crypt>

Spoiler: debug_openvpn.out nach Start Server

Sun Jul 26 14:22:18 2020 OpenVPN 2.4.9 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jul 26 2020
Sun Jul 26 14:22:18 2020 library versions: OpenSSL 1.0.2u 20 Dec 2019, LZO 2.10
Sun Jul 26 14:22:18 2020 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Sun Jul 26 14:22:19 2020 Diffie-Hellman initialized with 2048 bit key
Sun Jul 26 14:22:19 2020 CRL: loaded 1 CRLs from file /tmp/flash/openvpn/crl.pem
Sun Jul 26 14:22:19 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jul 26 14:22:19 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jul 26 14:22:19 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jul 26 14:22:19 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jul 26 14:22:19 2020 TUN/TAP device tun0 opened
Sun Jul 26 14:22:19 2020 TUN/TAP TX queue length set to 100
Sun Jul 26 14:22:19 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Jul 26 14:22:19 2020 /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Sun Jul 26 14:22:19 2020 Socket Buffers: R=[229376->229376] S=[229376->229376]
Sun Jul 26 14:22:19 2020 UDPv4 link local (bound): [AF_INET][undef]:54201
Sun Jul 26 14:22:19 2020 UDPv4 link remote: [AF_UNSPEC]
Sun Jul 26 14:22:19 2020 GID set to openvpn
Sun Jul 26 14:22:19 2020 UID set to openvpn
Sun Jul 26 14:22:19 2020 MULTI: multi_init called, r=256 v=256
Sun Jul 26 14:22:19 2020 IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Sun Jul 26 14:22:19 2020 Initialization Sequence Completed

Spoiler: debug_openvpn.out Ergänzung nachdem sich ein Client verbunden hat

Sun Jul 26 14:24:45 2020 109.41.195.196:12895 TLS: Initial packet from [AF_INET]109.41.195.196:12895, sid=ef6b7415 aeed5080
Sun Jul 26 14:24:46 2020 109.41.195.196:12895 tls-crypt unwrap error: bad packet ID (may be a replay): [ #2 / time = (1595766285) Sun Jul 26 14:24:45 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Jul 26 14:24:46 2020 109.41.195.196:12895 tls-crypt unwrap error: packet replay
Sun Jul 26 14:24:46 2020 109.41.195.196:12895 TLS Error: tls-crypt unwrapping failed from [AF_INET]109.41.195.196:12895
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 VERIFY OK: depth=1, CN=mein.myddns.me
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 VERIFY KU OK
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 Validating certificate extended key usage
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 VERIFY EKU OK
Sun Jul 26 14:24:47 2020 109.41.195.196:12895 VERIFY OK: depth=0, CN=clientname
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 tls-crypt unwrap error: bad packet ID (may be a replay): [ #6 / time = (1595766285) Sun Jul 26 14:24:45 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 tls-crypt unwrap error: packet replay
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 TLS Error: tls-crypt unwrapping failed from [AF_INET]109.41.195.196:12895
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_VER=3.git::3e56f9a6
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_PLAT=ios
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_NCP=2
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_TCPNL=1
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_PROTO=2
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_IPv6=0
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_AUTO_SESS=1
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_GUI_VER=net.openvpn.connect.ios_3.2.0-3253
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 peer info: IV_SSO=openurl
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun Jul 26 14:24:48 2020 109.41.195.196:12895 [clientname] Peer Connection Initiated with [AF_INET]109.41.195.196:12895
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 MULTI: Learn: 10.8.0.2 -> clientname/109.41.195.196:12895
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 MULTI: primary virtual IP for clientname/109.41.195.196:12895: 10.8.0.2
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 PUSH: Received control message: 'PUSH_REQUEST'
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 SENT CONTROL [clientname]: 'PUSH_REPLY,dhcp-option DNS 10.8.0.1,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Jul 26 14:24:48 2020 clientname/109.41.195.196:12895 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

 

[f666]

Hi,

kannst du bitte kurz die Ausgaben von "route" bzw. "ip route" von der Fritzbox hier posten?

 

[michael_wl]

Ja klar, gerne sogar. Ich bin leider noch nicht weitergekommen und es ist immer noch so das an der FritzBox Schluss ist.
Ich habe gestern meinen internen Adressbereich entgegen dem ersten Post oben von 192.168.1.x auf 192.168.12.x verschoben wegen der Meldung " NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x "

Hier die Ausgaben. Danke schon mal für Hilfe.

root@fritz:/var/mod/root# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         speedport.ip    0.0.0.0         UG    9      0        0 lan
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
192.168.12.0    *               255.255.255.0   U     0      0        0 lan
root@fritz:/var/mod/root#
root@fritz:/var/mod/root# ip route
default via 192.168.12.1 dev lan  metric 9
10.8.0.0/24 dev tun0 scope link  src 10.8.0.1
169.254.0.0/16 dev lan scope link  src 169.254.1.1
192.168.12.0/24 dev lan scope link  src 192.168.12.2
root@fritz:/var/mod/root#

 

[PeterPawn]

Und im Speedport ist dann auch die FRITZ!Box als Gateway für das entfernte LAN eingetragen, damit die Antworten auch ihren Rückweg finden?

 

[michael_wl]

Wie geht das? Im Speedport finde ich keine solche Funktion.

Die Fritzbox ist mit dem Speedport über LAN verbunden. Ist das eventuell das Problem?

 

[PeterPawn]

Die anderen Geräte kriegen doch ihre Einstellungen von Speedport-Router (würde ich hier jedenfalls annehmen, solange da nichts Gegenteiliges beschrieben wurde und zu den Symptomen paßt es auch genau) und da wird mit ziemlicher Sicherheit auch dessen Adresse als Standardgateway dabei sein.

Jetzt müssen entweder die Clients (dann jeder, der über VPN erreichbar sein soll) oder der Speedport auch dafür sorgen, daß Antworten auf Pakete, die das LAN über das VPN in der FRITZ!Box erreicht haben, auch wieder bei der FRITZ!Box ankommen, damit sie per VPN zum entfernten LAN übertragen werden können.

 

[michael_wl]

Irgendwie stehe ich da gerade auf dem Schlauch.
Ich habe noch einen Raspberry PI am laufen ebenfalls mit OpenVpn. Damit funktioniert alles. Der müsste dann doch das gleiche Problem haben oder?
Da sieht alles genau gleich aus.

pi@raspberrypi-micha:~ $ route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.12.1    0.0.0.0         UG    202    0        0 eth0
10.6.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.12.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0
pi@raspberrypi-micha:~ $ ip route
default via 192.168.12.1 dev eth0 src 192.168.12.112 metric 202
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.12.0/24 dev eth0 proto dhcp scope link src 192.168.12.112 metric 202
pi@raspberrypi-micha:~ $

Ich habe mal die Ping Antworten überprüft.

Baue ich die VPN-Verbindung im Heimnetz auf dann dann geht das vom Client aus:
Ping zum Speedport 192.168.12.1 > Erfolgreich
Ping zum Fritzbox 192.168.12.2 > Erfolgreich
Ping zum VPN Server 10.8.0.1 > Erfolgreich
Ping zum VPN Client 10.8.0.2 > Erfolgreich

Baue ich die VPN-Verbindung vom Fremdnetz auf dann geht das vom Client aus:
Ping zum Speedport 192.168.12.1 > Request time-out
Ping zum Fritzbox 192.168.12.2 > Erfolgreich
Ping zum VPN Server 10.8.0.1 > Erfolgreich
Ping zum VPN Client 10.8.0.2 > Erfolgreich

Hilft das was?

Ergänzend OpenVpn PI vom Client aus:
Ping zum Speedport 192.168.12.1 > Erfolgreich
Ping zum Fritzbox 192.168.12.2 > Erfolgreich
Ping zum VPN Server 10.8.0.1 > Erfolgreich
Ping zum VPN Client 10.8.0.2 > Erfolgreich

 

[PeterPawn]

Der müsste dann doch das gleiche Problem haben oder?

Nicht zwingend ... dazu müßte man seine Konfiguration genau kennen (will ich aber gar nicht kennenlernen, damit das nicht als Aufforderung verstanden wird). Im Gegensatz zur FRITZ!Box könnte der RasPi auch NAT vom VPN ins LAN machen - dann sehen die Clients halt seine Adresse im LAN als Absender und antworten automatisch auch an diese.

Du zäumst hier das Maultier ohnehin am falschen Ende auf - Du solltest zunächst mal prüfen, wie die Pakete aussehen, die per VPN bei den Clients ankommen. Dann wird auch klar, wohin die Antworten (die man dabei i.d.R. so nebenbei auch gleich noch sieht) gehen. Die FRITZ!Box kann/macht ihrerseits kein NAT auf der LAN-Seite, auch nicht mit Freetz bzw. nur mit so viel Aufwand/Aufstand/Probiererei, daß man das kaum empfehlen kann.

Nur aus den Ergebnissen eines "ping" auf die Ursachen eines Problems schließen zu wollen, funktioniert i.d.R. nicht - damit kann man zwar feststellen, ob das alles richtig eingerichtet ist (IP-Adressen, Routing, etc.) oder nicht, aber man kann aus den ausbleibenden ICMP-Reply-Paketen eben nicht ablesen (denn die sind halt gar nicht vorhanden am Ausgangsort des ICMP-Request bzw. am Zielort des ICMP-Reply), was die Ursache dafür wäre.

Dafür gibt es andere Programme/TCP-Optionen (z.B. "record route" als IP-Option 7) und wenn man erst mal weiß, von welcher Adresse das ICMP-Request-Paket bei einem Ziel ankommt (der Speedport ist da aufgrund mangelnder Zugriffsmöglichkeiten sicherlich auch die denkbar schlechteste Wahl), dann kann man auf diesem Ziel auch mit anderen Mitteln (z.B. "traceroute", was sich unter Windows dann "tracert" nennt) ermitteln, welchen Weg Pakete von diesem Host zum Absender des ICMP-Requests nehmen würden.

EDIT: Abgesehen davon ist es mir schon vollkommen schleierhaft, wie Du zu der Feststellung gelangt bist, Du könntest über die OpenVPN-Verbindung wenigstens die FRITZ!Box selbst erreichen. Aber laß mich raten ... das hast Du bestimmt mit einem "ping 10.8.0.1" ermittelt? Wenn ich damit richtig liegen sollte, würde ich an Deiner Stelle noch mal einen Blick in meine Client-Konfiguration werfen - zumindest nach #1 verwenden sowohl der Server als auch Dein Client dann nämlich dieselbe Adresse und damit hast Du mit dem "ping" (so es verwendet wurde) nur die lokale Konfiguration des Interfaces tatsächlich "geprüft".

Ich weiß nicht, wo Du diese Konfiguration(en) her hast - aber das " ifconfig 10.8.0.1 255.255.255.0" in Deiner Client-Konfiguration ist mit ziemlicher Sicherheit unangebracht an dieser Stelle, zumindest mit diesem Inhalt. Denn wie man problemlos im OpenVPN-Log des Servers sehen kann, verwendet der diese Adresse (die erste aus dem per "server"-Option zugewiesenen Segment) selbst für sein "tun0"-Interface und versucht seinerseits, dem Client die 10.8.0.2/24 zuzuweisen - was dieser aber ignoriert, wenn Du ihm die Adresse für das Interface vorgibst.

Alles das ändert aber nichts daran, daß da die Clients irgendwie eine Idee haben müssen, wohin sie das Paket für den Rückweg senden sollen. Wenn das aus ihrer Sicht dann "Standard" ist und damit die Default-Route zum Speedport genommen wird (Deine FRITZ!Box ist ja offensichtlich gar nicht als (WAN-)Router konfiguriert und damit wohl kaum das Gateway für irgendein anderes Gerät, sofern dieses auf "das Internet" zugreifen kann), muß spätestens dieser wieder wissen, daß das ein "anderer Zustellbezirk" ist und das Paket besser an die Konkurrenz übergeben wird, weil man es selbst nicht (sinnvoll) weiterleiten kann.

 

[f666]

Kurz:
Deine anderen Stationen im LAN haben nur eine Default Route zum Speedport und schicken alles zu dem (auf Ethernet Ebene), was nicht für das lokale LAN bestimmt ist. Also genau die Pakete, welche durch das VPN gehen sollen.
Der Speedport kann aber mit diesen Paketen nichts anfangen und wird sie verwerfen (hoffentlich, da sie zu einem privaten IP Bereich gehören).
Entweder du bringst deinen Clients im LAN bei, die Fritzbox als Default Gateway zu benutzen oder du legst überall eine Route ins VPN an mit der Fritzbox als Gateway. Zum Testen könntest du beides 1x probieren.

 

[michael_wl]

Danke euch beiden schon mal für die vielen Informationen. Ich werde dran bleiben und hier berichten.

 

[michael_wl]

Ich bin etwas weitergekommen mit euren Infos. Eigentlich fehlt jetzt nur noch der Speedport Hybride. Der lässt sich nicht überreden seine Pakete zurück ins OpenVpn Netzt auf der FritzBox zu senden.
Habe einiges probiert, erfolglos. Hoffe ihr könnt mir einen weiteren Tip geben.

Mein Netzt ist eventuell auch etwas speziell was das angeht.
Da ist die Fritzbox mit IP 192.168.12.2
Dann der PI mit aufgesetzten PI-Hole 192.168.12.112
Und der Speedport Hybride 192.168.12.1

Nachdem ich am PI Routing umgestellt habe auf die FritzBox 192.168.12.2

Hat es geklappt das ich alle internen Netze in meinem Netzt erreicht habe. Der PI ist dabei der DHCP Server und vergibt an alle anderen im Netz Routing zur Fritzbox. Nur leider nicht zum SpeedPort Hybride.

Hier der aktuelle Stand der Dinge:

Spoiler: Server Config

mode server
proto udp4
dev tun
tls-server
port 54301
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
keepalive 10 120

topology subnet
remote-cert-tls client
auth-nocache

ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
crl-verify /tmp/flash/openvpn/crl.pem
tls-crypt /tmp/flash/openvpn/static.key
dh /tmp/flash/openvpn/dh.pem
client-to-client

user openvpn
group openvpn
log /var/tmp/debug_openvpn.out

server 10.18.0.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"

persist-tun
persist-key

daemon

Spoiler: Client Config

client
dev tun
proto udp4
remote name.myddns.me 54301
resolv-retry infinite
nobind
remote-cert-tls server
cipher AES-256-CBC
auth-nocache
verb 3
float
<ca>
-----BEGIN CERTIFICATE-----
MIIDZjCCAk6gAwIBAgIUcoNwmPbAgvy/h0A3ifvAop6tbbYwDQYJKoZIhvcNAQEL
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIDajCCAlKgAwIBAgIQZtGyn3YR0zNYWoJ8IZnHkzANBgkqhkiG9w0BAQsFADAf
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDIOJxl8704HC32
-----END PRIVATE KEY-----
</key>
<dh>
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEArpj5FojwffGkD2aobSi+D7wB+v+sQfM0ffFkFH7AIe+Kp+BzIITT
-----END DH PARAMETERS-----
</dh>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
c1c6ad6984b2d43b0c9094e731c8af6d
-----END OpenVPN Static key V1-----
</tls-crypt>

Spoiler: Log Server

Mon Aug 3 20:38:04 2020 OpenVPN 2.4.9 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Aug 2 2020
Mon Aug 3 20:38:04 2020 library versions: OpenSSL 1.0.2u 20 Dec 2019, LZO 2.10
Mon Aug 3 20:38:04 2020 Diffie-Hellman initialized with 2048 bit key
Mon Aug 3 20:38:04 2020 CRL: loaded 1 CRLs from file /tmp/flash/openvpn/crl.pem
Mon Aug 3 20:38:04 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Aug 3 20:38:04 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Aug 3 20:38:04 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Aug 3 20:38:04 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Aug 3 20:38:04 2020 TUN/TAP device tun0 opened
Mon Aug 3 20:38:04 2020 TUN/TAP TX queue length set to 100
Mon Aug 3 20:38:04 2020 /sbin/ifconfig tun0 10.18.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.18.0.255
Mon Aug 3 20:38:04 2020 Socket Buffers: R=[229376->229376] S=[229376->229376]
Mon Aug 3 20:38:04 2020 UDPv4 link local (bound): [AF_INET][undef]:54301
Mon Aug 3 20:38:04 2020 UDPv4 link remote: [AF_UNSPEC]
Mon Aug 3 20:38:04 2020 GID set to openvpn
Mon Aug 3 20:38:04 2020 UID set to openvpn
Mon Aug 3 20:38:04 2020 MULTI: multi_init called, r=256 v=256
Mon Aug 3 20:38:04 2020 IFCONFIG POOL: base=10.18.0.2 size=252, ipv6=0
Mon Aug 3 20:38:04 2020 Initialization Sequence Completed

Spoiler: Zusatz Log Server nach verbunden

Mon Aug 3 20:40:43 2020 109.41.193.104:8029 TLS: Initial packet from [AF_INET]109.41.193.104:8029, sid=b23235d5 72ad73ea
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 VERIFY OK: depth=1, CN=name.myddns.me
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 VERIFY KU OK
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 Validating certificate extended key usage
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 VERIFY EKU OK
Mon Aug 3 20:40:44 2020 109.41.193.104:8029 VERIFY OK: depth=0, CN=clientname
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_VER=3.git::3e56f9a6
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_PLAT=ios
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_NCP=2
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_TCPNL=1
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_PROTO=2
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_IPv6=0
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_AUTO_SESS=1
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_GUI_VER=net.openvpn.connect.ios_3.2.0-3253
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 peer info: IV_SSO=openurl
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mon Aug 3 20:40:45 2020 109.41.193.104:8029 [clientname] Peer Connection Initiated with [AF_INET]109.41.193.104:8029
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 MULTI_sva: pool returned IPv4=10.18.0.2, IPv6=(Not enabled)
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 MULTI: Learn: 10.18.0.2 -> clientname/109.41.193.104:8029
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 MULTI: primary virtual IP for clientname/109.41.193.104:8029: 10.18.0.2
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 PUSH: Received control message: 'PUSH_REQUEST'
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 SENT CONTROL [clientname]: 'PUSH_REPLY,route 192.168.12.0 255.255.255.0,route-gateway 10.18.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.18.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Aug 3 20:40:45 2020 clientname/109.41.193.104:8029 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Hiermit erreiche ich die Fritzbox.

Den PI

Den Hackintosh und auch alle anderen IP Adressen im Netz


Nicht zu erreichen ist der Speedport


Oben steht von @f666 " oder du legst überall eine Route ins VPN an mit der Fritzbox als Gateway". Genau da hänge ich jetzt. Wie kann ich das vom OpenVpn Netz auf der FritzBox zum Speedport machen?
Einstellungen gibt es da keine und was der PI als DHCP-Server vorgibt interessiert den Speedport nicht weiter.
Danke schon mal für jegliche Hilfe.

Ergänzung:
wenn ich mich auf der FritzBox per SSH einlogge und folgenden Befehl eingebe:

ip address add 192.168.12.1/24 dev tun0

Erreiche ich alles im Netzt aber irgendwie nur über "Trace Route" und auf der untersten Ebene. Bedeutet, FritzBox ist voll erreichbar, jedoch Speedport und PI nur die direkte IP Adresse und keine Webinterface.

 

[f666]

Ich kenne mich mit einem Speedport nicht aus, ich vermute aber, dass du wenig Chancen haben wirst, dort eine statische Route ins VPN über die Fritzbox hinzuzufügen.

Alternativ nimmst du den PI als VPN Gateway und führst daruf NAT (im speziellen Masquerading) durch für die Pakete, welche aus dem VPN ins lokale Netz gehen sollen.

 

[michael_wl]

Hallo @f666
Das wäre dann am Server setzen

push "redirect-gateway 192.168.12.112"

oder

redirect-gateway 192.168.12.112

?

192.168.12.112 ist der PI.

 

[f666]

Nee, so einfach ist es nicht. Du musst dich mit iptables (oder dem Nachfolger) auseinandersetzen.
Der PI muss alle Pakete aus dem VPN mit seiner IP Adresse (und seiner Ethernet Adresse) versehen und auf dem Rückweg ins VPN wieder die ursprüngliche IP Adresse einsetzen (Masquerading).
Ein (nicht ganz passendes) Beispiel, welches als Einstieg dienen kann, findest du z.B. hier:

https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

 

[PeterPawn]

@michael_wl:

Alternativ nimmst du den PI als VPN Gateway und führst daruf NAT [...]

Du hast aber verstanden, daß das dann darauf hinausläuft, weiterhin den RasPi als Gateway zu verwenden? Das war's ja (nach Deiner Schilderung oben), was Du schon hattest und durch ein VPN-Gateway (OpenVPN oder Wireguard) auf der FRITZ!Box ersetzen wolltest (aus dem Kopf, ich habe nicht noch einmal nachgelesen - das ist ja mittlerweile schon über eine Woche her).

Das wäre dann also die komplette Rolle rückwärts ... wenn Du die nicht tatsächlich machen willst, solltest Du überlegen, wie wichtig der Zugriff auf den Speedport über VPN wirklich ist. Denn das mit den NAT ins LAN funktioniert so auch nur mit dem RasPi - die FRITZ!Box spielt (auch mit Freetz) da nicht ohne weiteres mit. Da vermutlich(!) auf dem Speedport auch höchstens ein GUI von Interesse ist, könnte man ansonsten noch über einen HTTP-Proxy auf einem erreichbaren Gerät nachdenken.

 

[michael_wl]

Hallo @PeterPawn,
ich habe leider wegen viel Arbeit nur am Wochenende Zeit für dieses Thema. Daher die verzögerten Antworten.

Das ich die Benutzeroberfläche vom Speedport erreiche ist mir eigentlich egal. Es ist nur so das dadurch das ich den Speedport nicht erreiche auch kein Traffic über VPN nach draußen möglich ist. Alle internen IP-Adressen erreiche ich. es ist sogar möglich den PI-Hole als Werbeblocker zu verwenden.

push "dhcp-option DNS 10.18.0.1"
push "block-outside-dns"

Sobald ich aber den ganzen Traffic über den VPN-Tunnel leite

push "redirect-gateway def1"

ist außer den internen Adressen nichts mehr erreichbar.

Denke meine Probleme liegen daran das ich die FritzBox im Lan Betrieb benutze und als Mitbenutzung des Speedport Netzes.

Ich werde am Wochenende die Box mal umstellen auf Lan mit eigenem IP Netz.
Nachteil, die Firewall ist dann auf der FritzBox aktiv und das macht Probleme mit Telefonie und auch alle Geräte hinter der Fritzbox sind dann nicht mehr erreichbar.

Gibt es eigentlich eine Möglichkeit in der ar7.cfg oder irgendwie anders die Firewall der Fritzbox komplett zu deaktivieren? Damit würde ich dann sicher weiterkommen mit VPN.

 

[f666]

Ich glaube da liegt noch ein Denkfehler vor.
Wenn du den gesamten Traffic der VPN Clients (außer dem zum VPN Endpunkt) durch das VPN und durch den Speedport ins Internet leiten willst, musst du auf dem VPN Endpunkt via IP Tables Masquerading für den ausgehenden Verkehr (und für die einzelne Adresse des Speedports) aktivieren (und IP Forwarding). Da das auf modernen Fritzboxen nicht mehr möglich ist, bleibt dir in deinem Fall nur noch der Raspberry Pi als VPN Endpunkt. Die Fritzbox dient in deinem Setup nur noch als "dummer" Switch oder Accesspoint (IP-Client).
Der Raspberry Pi hat den SpeedPort als Default Gateway. Die anderen Teilnehmer in deinem internen Netzwerk sollten den Raspberry Pi als Default Gateway haben, um gescheit mit den VPN Clients kommunizieren zu können.

 

[michael_wl]

Leider funktioniert das auch nicht.
Wenn ich den Raspberry Pi als Default Gateway und beim Raspberry Pi den SpeedPort als Default Gateway angebe kommen keine Pakte aus dem internen Netzwerk zurück. Der Default Gateway beim Raspberry Pi muss die FritzBox sein damit die Pakete zurückkommen.

Egal, viel gelernt und teilweise funktioniert es ja. Ich werde es jetzt so lassen. Habe ja den Raspberry Pi wo OpenVPN und Wireguard zusammen bestens laufen. Das auch auf der FritzBox zum laufen zu bringen war ein interessanter Versuch, auch wenn nur bedingt erfolgreich.

Danke euch beiden für die Antworten und die Untersützung.