Jumphost VPN (IPSec)
Ich habe folgenden Artikel zum Thema Jumphost VPN Setup mit vServer und FritzBox gelesen und versucht, ihn Schritt für schritt zu befolgen. Da ich diesen Beitrag erstelle, könnt ihr euch denken, es hat nicht zum Erfolg geführt.
Mein Setup:
Server: strongSwan swanctl 5.9.5 bei IONOS (VPS Linux XS)
Client: strongSwan VPN Client 2.4.1 für Android auf Handy
Heimnetz: Fritzbox 7580, FRITZ!OS: 07.29
Nach dem ich die Konfig auf die Fritzbox aufgespielt habe, sehe ich dieses Bild (IP maskiert "8 .... 5"):
Sollte hier die Status LED nicht schon grün sein?
Wenn ich mich vom Andoid Client versuche zu verbinden, kommt es auch zum Fehler. Hier das zugehörige Log (Serer IP maskiert "8....5"):
Kann mir jemand einen Tipp geben, was ich übersehen/vergessen haben könnte?
Mein Setup:
Server: strongSwan swanctl 5.9.5 bei IONOS (VPS Linux XS)
Client: strongSwan VPN Client 2.4.1 für Android auf Handy
Heimnetz: Fritzbox 7580, FRITZ!OS: 07.29
Nach dem ich die Konfig auf die Fritzbox aufgespielt habe, sehe ich dieses Bild (IP maskiert "8 .... 5"):
Sollte hier die Status LED nicht schon grün sein?
Wenn ich mich vom Andoid Client versuche zu verbinden, kommt es auch zum Fehler. Hier das zugehörige Log (Serer IP maskiert "8....5"):
Jun 12 19:47:29 00[DMN] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jun 12 19:47:29 00[DMN] Starting IKE service (strongSwan 5.9.9, Android 13 - TP1A.220624.014.G781BXXS5HWD4/2023-05-01, SM-G781B - samsung/r8qxxx/samsung, Linux 4.19.113-26205065, aarch64, org.strongswan.android)
Jun 12 19:47:29 00[LIB] providers loaded by OpenSSL: legacy default
Jun 12 19:47:29 00[LIB] loaded plugins: androidbridge charon android-log socket-default openssl nonce pkcs1 pem x509 xcbc kdf revocation eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
Jun 12 19:47:29 00[JOB] spawning 16 worker threads
Jun 12 19:47:29 07[IKE] initiating IKE_SA android[1] to 8....5
Jun 12 19:47:29 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jun 12 19:47:29 07[NET] sending packet: from 192.0.0.2[54985] to 8....5[500] (948 bytes)
Jun 12 19:47:29 08[NET] received packet: from 8....5[500] to 192.0.0.2[54985] (36 bytes)
Jun 12 19:47:29 08[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
Jun 12 19:47:29 08[IKE] received NO_PROPOSAL_CHOSEN notify error
Kann mir jemand einen Tipp geben, was ich übersehen/vergessen haben könnte?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7503028022
Url: https://administrator.de/contentid/7503028022
Ausgedruckt am: 19.11.2024 um 09:11 Uhr
27 Kommentare
Neuester Kommentar
Sollte hier die Status LED nicht schon grün sein?
Das kommt, wie immer, drauf an... Der IPsec Tunnel der FB (und damit der Buttonwechsel auf grün) wird nur dann automatisch aufgebaut unter 2 Bedingungen:
- Es muss relevanter Traffic durch den Tunnel laufen
- Es muss ein Keepalive auf der Fritzbox aktiviert sein (was dann relevanten Traffic generiert)
einen Tipp geben, was ich übersehen/vergessen haben könnte?
Der Debugger sagt es dir schon schwarz auf weiss: received NO_PROPOSAL_CHOSEN notify errorWas bedeutet das sich die beiden Enden nicht auf ein gemeinsames Schlüsselverfahren einigen konnten und der VPN Tunnelaufbau damit abbricht. Grund dafür ist fast immer eine Fehlkonfiguration.
Auch du kannst es dir schon denken... Leider hast du es versäumt einmal deine Jumphost Strongswan Konfig hier zu posten und auch ein Debug Lauf des Jumphosts (swanctl -T) wenn entweder Fritzbox oder VPN Client sich einwählen.
Leider ebenso fehlt auch deine FB Konfig Datei (mit anderen Worten also quasi alles was für eine zielführende Hilfe wichtig ist!) und damit sind wir dann wieder zum Kristallkugeln verdammt.
Hilfreich für eine zielführende Lösung ist also:
- Deine Jumphost Server Konfig (annonymisiert)
- Deine FritzBox Konfig Datei (annonymisiert)
- Output von swanctl -q
- Output von swanctl -T wenn du die Fritzbox und den Androiden danach neu startest und sie am vServer einwählen lässt.
So wie das Folgende sollte es bei dir aussehen...
Inhaltsverzeichnis
IKEv2 Client Debug Beispiel
Als leicht gekürztes Beispiel einmal wie der swanctl -T Output bei einem IKEv2 Client (Xiaomi mit Strongwan Client, Windows 10/11) aussieht der sich einwählt.
Die Messages sind so gut wie selbsterklärend. Welches Schlüsselverfahren verwendet wird auf das sich beide Enden geeinigt haben, siehst du an der Message "selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ"
Ein established... zeigt das der Tunnel fehlerfrei aufgebaut wurde.
root@vserver:/home/admin# swanctl -T
12[NET] received packet: from 88.35.199.98[513] to 121.21.14.34[500] (432 bytes)
12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
12[IKE] 88.35.199.98 is initiating an IKE_SA
12[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
12[IKE] remote host is behind NAT
12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
13[CFG] looking for peer configs matching 121.21.14.34[vserver.domain.de]...88.35.199.98[192.168.1.158]
13[CFG] selected peer config 'ikev2-mobile-defaults'
13[IKE] initiating EAP_IDENTITY method (id 0x00)
13[IKE] peer supports MOBIKE
13[IKE] authentication of 'vserver.domain.de' (myself) with RSA signature successful
15[IKE] received EAP identity 'user2'
15[IKE] initiating EAP_MSCHAPV2 method (id 0x1A)
15[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
11[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
11[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ]
10[ENC] parsed IKE_AUTH request 5 [ AUTH ]
10[IKE] authentication of '192.168.7.158' with EAP successful
10[IKE] authentication of 'vserver.domain.de' (myself) with EAP
10[IKE] IKE_SA ikev2-mobile-defaults[5] established between 121.21.14.34[vserver.domain.de]...88.35.199.98[192.168.1.158]
10[IKE] scheduling rekeying in 13961s
10[IKE] maximum IKE_SA lifetime 15401s
10[IKE] assigning virtual IP 172.25.25.1 to peer 'user2'
10[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
10[IKE] CHILD_SA ikev2-mobile{4} established with SPIs 09df02d1_o and TS 0.0.0.0/0 === 172.25.25.1/32
Fritzbox Debug Beispiel
Analog dann das swanctl -T Debugging von der Fritzbox
root@vserver:/home/admin# swanctl -T
10[NET] received packet: from 82.79.111.98[512] to 121.21.14.34[500] (532 bytes)
10[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
10[IKE] 82.79.111.98 is initiating a Main Mode IKE_SA
10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
10[NET] sending packet: from 121.21.14.34[500] to 82.79.111.98[512] (136 bytes)
11[NET] received packet: from 82.79.111.98[512] to 121.21.14.34[500] (316 bytes)
11[IKE] remote host is behind NAT
14[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
14[CFG] looking for pre-shared key peer configs matching 121.21.14.34-82.79.111.98
14[CFG] selected peer config "fritzbox"
14[IKE] IKE_SA fritzbox[3] established between 121.21.14.34[121.21.14.34]-82.79.111.98
14[IKE] scheduling rekeying in 13842s
14[IKE] maximum IKE_SA lifetime 15282s
05[ENC] parsed QUICK_MODE request 892757051 [ HASH SA No KE ID ID ]
05[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/MODP_1024/NO_EXT_SEQ
05[IKE] received 3600s lifetime, configured 3960s
15[ENC] parsed QUICK_MODE request 892757051 [ HASH ]
15[IKE] CHILD_SA net{3} established with SPIs cfef35de and TS 172.25.24.0/23 === 192.168.178.0/24
swanctl -l zeigt dann den aufgebauten Fritzbox VPN Tunnel und ein Pingcheck zeigt die Erreichbarkeit der Fritzbox via VPN vom vServer (Jumphost) aus:
root@vserver:/home/admin# swanctl -l
fritzbox: #1, ESTABLISHED, IKEv1, b7a8456046e1ac80_i c1ea80f731f07909_r*
local '121.21.14.34' @ 121.21.14.34[4500]
remote '73:74:72:6f:6e:67:73:77:61:6e:40:66:72:69:74:7a:2e:62:6f:78' @ 82.79.111.98[5634]
AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
established 572s ago, rekeying in 12878s
net: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_512_256/MODP_1024
installed 571s ago, rekeying in 2801s, expires in 3389s
in caf794c2, 504 bytes, 6 packets, 356s ago
out ed0f5302, 504 bytes, 6 packets, 356s ago
local 172.25.24.0/23
remote 192.168.178.0/24
root@vserver:/home/admin# ping -c 3 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=15.1 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=64 time=14.8 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=64 time=14.8 ms
--- 192.168.188.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 14.823/14.902/15.060/0.111 ms
vServer Strongswan Konfigabschnitt für die Fritzbox
IKEv2 Dialin IP Netzadresse: 172.25.25.0 /24
Loopback IP vServer: 172.25.24.1 /32 (Keepalive IP für Fritzbox)
Lokales LAN FritzBox: 192.168.178.0 /24
fritzbox {
local_addrs = 121.21.14.34
remote_addrs = 0.0.0.0/0
local {
auth = psk
id = 121.21.14.34
}
remote {
auth = psk
id = keyid:strongswan@fritz.box
}
children {
net {
local_ts = 172.25.24.0/23
remote_ts = 192.168.178.0/24
esp_proposals = aes256-sha512-modp2048,aes256-sha512-modp1024
}
}
version = 1
proposals = aes256-sha512-modp2048,aes256-sha512-modp1024
}
secrets {
ike-3 {
id = keyid:strongswan@fritz.box
secret = "test1234"
}
...
}
Passende Fritzbox VPN Konfig Datei dazu:
Lokales LAN FritzBox: 192.168.178.0 /24
IKEv2 Dialin IP Netzadresse: 172.25.25.0 /24
Loopback IP vServer: 172.25.24.1 /32 (Keepalive IP für Fritzbox)
vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "vServer-VPN";
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 121.21.14.34;
remote_virtualip = 0.0.0.0;
keepalive_ip = 172.25.24.1;
localid {
key_id = "strongswan@fritz.box";
}
remoteid {
ipaddr = 121.21.14.34;
}
mode = phase1_mode_idp;
phase1ss = "LT8h/all/all/all";
keytype = connkeytype_pre_shared;
key = "test1234";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.178.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 172.25.24.0;
mask = 255.255.254.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 172.25.24.0 255.255.254.0";
}
}
Works as designed!! 👍 😉
Wenn es das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu schliessen!
den Androiden danach neu starte und ihn am VPS einwählen lasse, kann ich nicht dienen, denn es gibt schlicht keinen
Aha... da liegt also der Hase im Pfeffer!Mit anderen Worten am vServer kommt generell erst gar kein IKE (UDP 500) Traffic an. Weder von der FritzBox noch von den VPN Clients. ☹️
Das ist dann natürlich klar, das dann auch generell in puncto VPN gar nix klappen kann. Kein IPsec Traffic = kein VPN...klare Sache.
Du musst überhaupt erstmal ergründen WAS den IPsec Traffic vom vServer blockt. Da gibt es mehrere mögliche Fehlerquellen:
- IP Adresse vServer im VPN Client stimmt nicht (Tippfehler, DNS Auflösung scheitert ggf. etc.)
- Lokale vServer Firewall blockiert IPsec Traffic. Hier ist auffällig das bei dir oben das ESP Protokoll im Setup fehlt!! Der ESP Tunnel transportiert die VPN Daten. Wie z.B. einen korrekte lokale Firewall mit nftables aussieht kannst du u.a. hier sehen.
- Dein Provider blockt VPN Traffic
Sehr wahrscheinlich dürfte es Punkt 2 sein. Hier solltest du mit apt install tcpdump dir mal einen kleinen CLI Paketsniffer installieren.
Den startest du dann mit tcpdump -i <interface> -n -t port 500 or 4500 und startest danach den VPN Client oder FritzBox.
Da sollte dann sofort sowas auftauchen wie das Folgende wenn der IPsec Tunnel startet:
root@vserver:/home/admin# tcpdump -i eth0 -n -t port 500 or 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 82.79.111.98.512 > 121.21.14.34.500: isakmp: parent_sa ikev2_init[I]
IP 121.21.14.34.500 > 82.79.111.98.512: isakmp: parent_sa ikev2_init[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
IP 121.21.14.34.4500 > 82.79.111.98.5683: NONESP-encap: isakmp: child_sa ikev2_auth[R]
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x1), length 136
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x2), length 136
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x3), length 120
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x1), length 200
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x2), length 184
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x4), length 120
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x3), length 184
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x5), length 104
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x4), length 264
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x6), length 120
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x7), length 120
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x8), length 120
IP 82.79.111.98.5683 > 121.21.14.34.4500: UDP-encap: ESP(spi=0xcc3bc363,seq=0x9), length 120
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x5), length 408
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x6), length 328
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x7), length 280
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x8), length 424
IP 121.21.14.34.4500 > 82.79.111.98.5683: UDP-encap: ESP(spi=0x0439859e,seq=0x9), length 200
Das verifiziert generell das der Client VPN Traffic von deinem Androiden oder der Fritzbox überhaupt erstmal am vServer ankommt. Sollte das so zu sehen sein siehst du es dann auch sofort im swanctl -T Output.
Bis dato ist das nämlich gar nicht der Fall und du musst erstmal rausbekommen WAS da blockt!
Es hilft auch einmal temporär komplett die Firewall zu deaktivieren. Bei nftables macht das ein systemctl stop nftables. Dann führst du den o.a. Sniffer Check durch.
So weisst du wenigstens genau WER der böse Buhmann ist und den VPN Traffic blockiert. 😉
(nftables startet man hinterher wieder mit systemctl start nftables)
Ist etwas unverständlich jetzt...?! 🤔
Ebenso beim 2ten Versuch!
Er müsste hier aber eigentlich mit einem NAT Traversal UDP 4500 ikev2_auth[I] (IKEv2 Auth Init) Paket antworten was er aber nicht tut.
Hier rächt sich jetzt die sc%$§"$ Vielfalt der Android Clients. Leider sagst du nicht ob du einen embeddeten Client benutzt oder einen externen.
Das NAT Traversal am Client gemacht wird ist nicht immer automatisch. Einige VPN Clients erfordern im Setup das man es explizit setzt. Vermutlich ist es das, denn der Androide ist hier der pöhse Buhmann wie man ja am Sniffer Trace unschwer sieht.
Sicherheitshalber solltest du mit systemctl restart strongswan den IPsec Dienst nochmal neu starten und neu versuchen um sicher zu gehen das der Androide den "Hänger" hat.
Laut deinem swanctl -q Output oben ist da aber alles Bella und korrekt.
Wenn du ggf. einen Windows oder Apple IKEv2 Client hast probiere es mal testweise mit dem.
- "Die 94er IP, das ist mein SSH Client über den ich mit dem VPS verbunden war" = Der dürfte dann aber niemals bei einem Sniffertrace von UDP 500 und UDP 4500 dort auftauchen! SSH benutzt bekanntlich TCP 22 also ganz andere Baustelle. Die 94er IP dürfte dort niemals auftauchen wenn du nur SSH machst. Sehr wahrscheinlich hast du da dann auch einen IPsec Tunnel versucht aufzubauen, kann das sein? Wäre doof wenn das parallel passiert weil das nur verwirrt.
- "VPS blockiert den VPN Traffic" = Wieso blockiert?? Es kommt ja de facto ein IKE 500 Init Request ([I]) vom Androiden an wenn der die 80er IP hat. Daraufhin sendet der vServer auch brav und wie es sich gehört gleich einen IKE Response ([R]) zurück.
Ebenso beim 2ten Versuch!
Er müsste hier aber eigentlich mit einem NAT Traversal UDP 4500 ikev2_auth[I] (IKEv2 Auth Init) Paket antworten was er aber nicht tut.
Hier rächt sich jetzt die sc%$§"$ Vielfalt der Android Clients. Leider sagst du nicht ob du einen embeddeten Client benutzt oder einen externen.
Das NAT Traversal am Client gemacht wird ist nicht immer automatisch. Einige VPN Clients erfordern im Setup das man es explizit setzt. Vermutlich ist es das, denn der Androide ist hier der pöhse Buhmann wie man ja am Sniffer Trace unschwer sieht.
Sicherheitshalber solltest du mit systemctl restart strongswan den IPsec Dienst nochmal neu starten und neu versuchen um sicher zu gehen das der Androide den "Hänger" hat.
Laut deinem swanctl -q Output oben ist da aber alles Bella und korrekt.
Wenn du ggf. einen Windows oder Apple IKEv2 Client hast probiere es mal testweise mit dem.
Client sagt: Authentifizierung des Servers ist fehgeschlagen
Dann ist etwas mit deinem Zertifikat schief gegangen... Oder du hast vergessen das CA Zertifikat auf das Endgerät zu importieren. Bedenke das wenn du 82-xx-xx-xxx.nip.io als Ziel IP angibst das auch die remote ID ist und dieses als SAN in das Zertifikat eingeflossen sein muss.Bei einem Windows Client wird das was als VPN Zieladresse angegeben wird auch immer als remote ID verwendet. Das sollte also immer übereinstimmen.
Statt eines "NAuth failed" sollte dort ein "Auth response" kommen. (Auszug aus swanctl -T)
13[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
13[IKE] peer supports MOBIKE
13[IKE] authentication of '82-xx-xx-xxx.nip.io' (myself) with RSA signature successful
13[IKE] sending end entity cert "CN=vpnserver, C=DE, ST=XY, L=XY, O=Private, OU=Private"
13[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
13[ENC] splitting IKE message (1600 bytes) into 2 fragments
13[ENC] generating IKE_AUTH response 1 [ EF(1/2) ]
13[ENC] generating IKE_AUTH response 1 [ EF(2/2) ]
13[NET] sending packet: from 82.xxx.xx.xxx[4500] to 80.xxx.xx.xxx[5672] (1236 bytes)
13[NET] sending packet: from 82.xxx.xx.xxx[4500] to 80.xxx.xx.xxx[5672] (436 bytes)
06[NET] received packet: from 80.xxx.xx.xxx[5672] to 82.xxx.xx.xxx[4500] (80 bytes)
06[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
06[IKE] received EAP identity 'user2'
06[IKE] initiating EAP_MSCHAPV2 method (id 0xAC)
06[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
07[IKE] IKE_SA ikev2-mobile-defaults[1] established between 82.xxx.xx.xxx[82-xx-xx-xxx.nip.io]...80.xxx.xx.xxx[192.168.201.158]
07[IKE] scheduling rekeying in 13567s
Gut sieht aber jetzt auch die FritzBox aus. Die ist ja nun grün und ein Ping auf die lokale IP der FB und vice versa von der FB und Clients im FB LAN auf die Loopback IP sollte klappen?! Tut es das?
Wenn ja wäre dann schonmal der FB VPN Tunnel einsatzklar. 👍
Was das Zertifikat bzw. Authentisierung des Servers bei den Clients anbetrifft sind das 2 Optionen:
- CA Zertifikat nicht auf den Androiden importiert! CA Zertifikat muss über das System oder den Strongswan Client importiert werden.
- 82-xx-xx-xxx.nip.io vergessen als SAN ins Zertifikat zu übernehmen.
Korrekt sollte das für die CA so aussehen:
pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/gonzoll-key.pem
pki --self --ca --lifetime 3650 --in /etc/swanctl/private/gonzoll-key.pem --type rsa --dn "CN=Gonzoll CA" --outform pem > /etc/swanctl/x509ca/gonzollca-cert.pem
Dann den Server Key:
pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/vpnserver-key.pem
pki --pub --in /etc/swanctl/private/vpnserver-key.pem --type rsa | pki --issue --lifetime 1825 --cacert /etc/swanctl/x509ca/gonzollca-cert.pem --cakey /etc/swanctl/private/gonzoll-key.pem --dn "CN=82-xx-xx-xxx.nip.io" --san 82-xx-xx-xxx.nip.io --flag serverAuth --flag ikeIntermediate --outform pem > /etc/swanctl/x509/vpnserver-cert.pem
Der Aufruf systemctl restart strongswan scheint wohl den Server neuzustarten
Er startet den gesamten Strongswan Prozess (Daemon) neu.und ich dachte ein swanctl -q würde reichen
Das liest lediglich den Konfig File neu ein startet aber nicht den Daemon neu.Es kann manchmal sein wenn man heftig an den Konfigs testet und ändert das sich der charon Daemon aufhängt. Da ist dann systemctl restart strongswan immer eine sichere Bank das ALLES neu gestartet wird!
Die 94er IP ist die (Gruppen-)IP, die mir mein ISP (DG) zuweist.
Wer oder was ist eine "Gruppen" IP?? Bahnhof, Ägypten...aber egal...tut hier (vermutlich) nix zur Sache.
OK, das sieht ja schon mal ganz gut aus. Zeigt das grundlegend (fast) alles rennt wie es soll! 👍
Du tauchst ja im internen LAN mit einer VPN Client Absender IP 172.25.25.x auf. Folglich brauchen die von dir angesprochenen Endgeräte zwingend ein Default Gateway was immer auf die Fritzbox zeigen muss, denn die Fritzbox bedient ja den VPN Tunnel zum vServer.
Prüfe das ob dem so ist! Das ist meist der einzige Grund.
Bei einigen wenigen NAS ist eine lokale Firewall aktiv. Diese lassen ohne entsprechende Konfig nur IP Adressen aus dem lokalen LAN zu. Das musst du ggf. customizen im Setup, da du ja eine anderen VPN Absender IP hast.
Das kannst du ganz einfach testen:
Hier der Quad 9 DNS. Du kannst Komma getrennt auch mehrere DNS eintragen wie z.B. die Fritzbox.
Achtung: Wenn die FB an erster Stelle steht wird diese benutzt aber dann muss der VPN Tunnel natürlich auch online sein ansonsten scheitert die DNS Abfrage an der FB. Besser ist dann also 9.9.9.9, 192.168.188.1.
Welchen DNS Server du verwendest kannst du frei wählen. Idealerweise definiert man die die dein vServer Provider vorgibt bzw. hier.
Deine Firewall NAT Konfig ist soweit ok. Prüfe immer mit nft list ruleset ob dein Regelwerk auch aktiv ist!
DS-Lite Provider nutzen intern entweder RFC1918 oder RFC6598 IPv4 Adressen und machen bei v4 dann ein zentrales NAT/Masquerading dieser internen Adressen ins Internet (CGNAT).
Auf folgende Ressourcen kann ich nicht zugreifen:
Das kann unterschiedliche Gründe haben. Ein Hauptgrund ist in 98% der Fälle das diese Geräte kein oder ein falsches Gateway konfiguriert haben.Du tauchst ja im internen LAN mit einer VPN Client Absender IP 172.25.25.x auf. Folglich brauchen die von dir angesprochenen Endgeräte zwingend ein Default Gateway was immer auf die Fritzbox zeigen muss, denn die Fritzbox bedient ja den VPN Tunnel zum vServer.
Prüfe das ob dem so ist! Das ist meist der einzige Grund.
Bei einigen wenigen NAS ist eine lokale Firewall aktiv. Diese lassen ohne entsprechende Konfig nur IP Adressen aus dem lokalen LAN zu. Das musst du ggf. customizen im Setup, da du ja eine anderen VPN Absender IP hast.
Und generell aufs Internet scheine ich auch nicht zugreifen zu können
Da muss man jetzt erstmal klären WAS du jetzt genau mit "Internet" genau meinst. Bei vielen Laien ist eine fehlende DNS Auflösung häufig schon "das Internet" ohne das sie einmal eine nackte Internet IP getestet haben. Geht es also nur um eine fehlende DNS Auflösung oder ob der Internet Zugang generell nicht klappt.Das kannst du ganz einfach testen:
- Um erstmal DNS Problematiken zu umgehen pinge vom Client einmal eine nackte IP z.B. 8.8.8.8. Wenn das klappt funktioniert der Internet Zugang an sich schon mal fehlerlos.
- Wenn z.B. ein ping www.heise.de scheitert, dann scheitert vermutlich auch ein nslookup www.heise.de. Das zeigt das du keinen oder einen falschen DNS Server benutzt wenn dein VPN Client aktiv ist. (Auf dem Smartphone helfen hier, wie immer, als Klassiker die HE.NET Tools)
pools {
pool-ipv4 {
addrs = 172.25.25.0/24
dns = 9.9.9.9
}
}
Achtung: Wenn die FB an erster Stelle steht wird diese benutzt aber dann muss der VPN Tunnel natürlich auch online sein ansonsten scheitert die DNS Abfrage an der FB. Besser ist dann also 9.9.9.9, 192.168.188.1.
Welchen DNS Server du verwendest kannst du frei wählen. Idealerweise definiert man die die dein vServer Provider vorgibt bzw. hier.
Deine Firewall NAT Konfig ist soweit ok. Prüfe immer mit nft list ruleset ob dein Regelwerk auch aktiv ist!
P.S. Die "Gruppen-IP" ist der verunglückte Versuch
Aaahh, ok. Das ist verstanden und auch normal, denn du hast einen DS-Lite Anschluss. DS-Lite Provider nutzen intern entweder RFC1918 oder RFC6598 IPv4 Adressen und machen bei v4 dann ein zentrales NAT/Masquerading dieser internen Adressen ins Internet (CGNAT).
1.000 Dank schon mal
Immer gerne! 🙂Erst nachdem ich über systemctl start nftables.service den Service neugestartet habe
Intuitiv richtig gemacht! 👍 Verifiziert das der Internet Zugang klappt und es nur noch am DNS hängt.War so naiv zu denken, ich könnte den Pi hole DNS auch über die VPN Clients mit nutzen
Das ist keineswegs naiv sondern durchaus richtig. Das kannst du ja auch genau so machen. Wichtig ist das du den Pi-Hole pingen kannst und vice versa.Nachteil bei dem Setup ist aber immer das du zwingend auf einen funktionierenden VPN Tunnel zur FB angewiesen bist um den PiHole zu erreichen. Ist der mal unterbrochen scheitert deine DNS Auflösung. Sicherer ist es dann immer einen 2ten DNS Server der direkt erreichbar ist mit anzugeben an zweiter Stelle.
Wenn du sichergestellt hast das VPN Client und PiHole sich pingtechnisch erreichen können musst du checken ob
- Der DNS Server vom VPN Client sauber übernommen wurde
- DNS Queries auch am PiHole ankommen
- Client: nslookup <hostname> sollte dir die verwendete DNS Adresse und das Ergebnis anzeigen. Du kannst auch einen DNS Lookup des Clients auf einen bestimmten DNS wie PiHole (oder jedem anderen DNS) erzwingen mit: nslookup www.heise.de 9.9.9.9 Dies erzwingt einen Lookup bei Quad9 statt des konfigurierten DNS. Analog würde dann nslookup www.heise.de 192.168.188.10 einen Lookup auf deinen PiHole erzwingen. DNS Lookups kann auch das HE.NET Tool a.d. Smartphone.
- DNS Server: Checke wieder mit tcpdump auf dem PiHole ob dort überhaupt DNS Requests der VPN Clients eingehen. tcpdump -i <interface> port 53
- Ggf. einfach testweise erstmal nur einen öffentlichen DNS wie den des vServer Providers oder 9.9.9.9 (oder beide) im Strongswan definieren und die o.a. Lookup Checks machen. (Nach Änderung swanctl -q nicht vergessen oder Daemon restart!)
Das bedeutet also, dass man bei der DNS Konfig von strongSwan...
Nein, auch nur die FritzBox würde reichen, denn die kann ja sowohl lokale Hostnamen als auch öffentliche auflösen. Den PiHole musst du entsprechend customizen das er lokale IP Adressen auflösen kann! Siehe dazu hier. Nur mit Bordmitteln macht er das nicht!Hier musst du dich entscheiden:
- Lokaler DNS Fritzbox, PiHole = erzwingt Verfügbarkeit des FB Tunnels
- Öffentlicher DNS = Keine Auflösung lokaler Hostnamen
Es gibt keine Einschränkung im VPN welchen DNS Server du verwendest solange der IPtechnisch vom VPN Client erreichbar ist!
Zugriffe auf mein WD NAS (Forbidden: You don't have the permission to access / on this server) wie auch auf meine Linux SAT-Receiver:
Das kann dann einzig und allein nur noch an diesen Geräten selber liegen. Zu 98% haben die eine Fireall oder Beschränkung drin das sie nur Zugriffe aus dem lokalen IP Netz erlauben, nicht aber mit fremden Absender IPs.Du kannst das ja testweise mal checken wenn du einen Test Laptop, Drucker, RasPi oder was immer mit genau der NAS oder Sat RX IP ins Netz klemmst und den remoten Zugriff darauf versuchst.
Klappt das (was zu erwarten ist da es mit allen anderen Komponenten im gleichen Netz auch klappt!) dann liegt es an den Geräten selber bzw. deren Setup.
Es wäre anders nicht erklärbar wenn alle anderen Geräte eine IP Verbindung zulassen nur 2 nicht.
Ein Ping auf diese Geräte sollte immer möglich sein!
Die letzten Paar Meter schaffen wir vielleicht auch noch
Ganz sicher! 💪DNS-Konfiguration einen zweiten DNS wie den Quad 9 auch gleich sparen. Sehe ich das richtig?
Wenn das der einzige Grund ist, dann siehst du das absolut richtig.Manchmal nutzt man so ein VPN auch wenn man an öffentlichen Hotspots nur sicher surfen will usw.
WD NAS - ein Ping vom VPN Client ist möglich, der Zugriff auf die Weboberfläche liefert aber:
"Forbidden: You don't have the permission to access / on this server"Das spricht sehr dafür das die grundlegende IP Connectivity korrekt ist, das NAS aber den Zugriff auf das WebGUI (HTTP oder HTTPS Traffic) einzig nur von lokalen IP Adressen zulässt. Das spricht zu 98% dafür das das NAS eine lokale Firewall hat für TCP 80, 443 Traffic.
Hier musst du mal ins Handbuch sehen oder den WD Support fragen wie man das freigibt.
Es wäre sehr unwahrscheinlich wenn WD NAS damit generell nicht in segmentierten Netzen arbeiten könnte. Ökonomisch würde sich der Hersteller damit selbst ins Knie schiessen weil die NAS in solchen Netzen dann völlig unverkäuflich wären. Davon ist nicht auszugehen das das der Fall ist. In sofern ist das zu 98% ein NAS Setup Problem und hat grundsätzlich mit dem VPN nichts zu tun.
2. Sat RX - ein Ping vom IPSec VPN Client ist nicht möglich
Das ist per se erstmal schlecht. Bedeutet ähnliches wie das NAS. Auch da vermutlich eine lokale Firewall oder das der Sat RX kein Gateway annimmt oder ignoriert.
Das ist jetzt sehr schwer zu sagen ohne dessen Setup zu kennen oder mal den Hersteller kontaktiert zu haben wie sich der RX in segmentierten Netzen verält wenn er von fremden IP Adressen kontaktiert wird.
Du kannst das ggf. mal lokal im LAN testen mit einem Rechner und 2 Netzwerkkarten oder kleinem Router ob auch dort lokal ein Zugriff aus anderen IP Netzen vom Sat RX ignoriert wird. Vermutlich ist das auch der Fall und dann wirst du um einen Support Call beim Hersteller nicht drum rumkommen.
Das es mit Wireguard (vermutlich nutzt du hier Wireguard auf der FritzBox?!) liegt daran das das AVM Wireguard nicht Standardkonform ist. Eine klassische Wireguard Konfig nutzt immer ein separates IP Netz für die Clients. (Siehe hier).
Nicht so bei AVM die den WG Clients IPs aus ihrem lokalen LAN Netz geben. Siehe dazu HIER.
Durch diese AVM "Sonderlocke" sieht dein Sat RX dann einen lokalen Zugriff. Mit einer klassischen Wireguard Konfig z.B. über deinen vServer und der FritzBox Anbindung mit Wireguard statt IPsec rennst du in die gleiche Problematik. ;-(
Auch dann dürften dein NAS und dein Sat RX in einer reinen WG Umgebung ebenso NICHT funktionieren!
Wie gesagt das musst du lokal mal in einem kleinen lokalen Router Setup testen um das wasserdicht zu verifizieren.
Auch ein Wireshark Trace des HTTP Clients wäre aufschlussreich wenn er auf das NAS zugreift. Beim Sat RX scheitert es ja schon an der einfachen IP Verbindung. Ohne IP natürlich keinerlei Dienste dort.
Der Server läuft in meinem Heimnetz auf einem Pi3.
Eigentlich ja überflüssig wenn du eine FritzBox hast die FW Version 7.5 laufen lassen kann?!Was aber dann völlig unverständlich ist, ist die Tatsache das du dann mit WG pingen kannst, denn bei einem WG Setup mit deinem vServer hast du ja zwangsweise auch ein separates IP Netz.
Dann greift die AVM "Sonderlocke" nicht da du ja dann mit klassischer WG Standartkonfig arbeitest? 🤔
Das würde dann aber auch bedeuten das es nicht an der fremden IP liegen kann.
Da ist dein Screenshot auch wiss denn es sagt "ping from 192.168.188.11..." was niemals sein kann wenn der WG Client in einem ganz anderen IP Netz liegt?
Die Kardinlsfrage ist welches interne WG Netz du dann verwendest??
Das würde dann keinen Sinn machen und unerklärlich warum von 10 Endgeräten im lokalen netz allesamt mit gleicher Konfig einzig 2 nicht funktionieren?! IP technisch macht das keinen Sinn.
warum der Rechner sich hier so bockig stellt?
Wieso "der Rechner"??? Es sind doch die 2 Endgeräte NAS und Sat RX?? Oder was meinst du mit "Rechner"??"uname -a" liefert für den Sat RX:
Hilft wenig... Ein ip a oder ip r wäre deutlich hilfreicher! Alternativ ifconfig und netstat -rn.Hier wäre wichtig zu wissen ob dort eine iptables oder nftables Firewall aktiv ist da da rumzickt?!
Bei iptables zeigt das ein sudo iptables -S oder sudo iptables -L -v -n bei nftables ein nft list ruleset.
Auf dem Rx habe ich vor langer Zeit einen OpenVPN-Client eingerichtet.
Uuhh böses Faul...Leichen im Keller! Vermutlich Bindung an eins dieser gruseligen, öffentlichen VPN Provider ala NordVPN um GeoIPs zu überwinden. Da muss man echt wissen was man tut...aber egal, andere Baustelle.
läuft das also ausschließlich über seinen OpenVPN-Client
Oha... Gut, da jetzt die Kardinalsfrage: "Gateway redirect" oder "Split Tunneling"?? Siehe dazu hier:Merkzettel: VPN Installation mit OpenVPN
Zu befürchen ist Ersteres und dein Test mit der OVPN Abschaltung bestätigt das dann auch!
kann ich meinem Rx irgendwie beibringen, dass wenn ihn einer aus dem 172.25.25.0/24 IP-Bereich kontaktiert, er diesen Client als lokalen Client akzeptiert
Klares Ja! Eine statische Route ist hier dein bester Freund! 🤔Das bedeutet dann das ALLES in den OpenVPN Tunnel geroutet wird. Damit dann natürlich auch dein VPN Client Rückroutentraffic der dann im IP Nirwana landet! Da liegt dann der Hase im Pfeffer!!
Das kannst du aber sehr schnell mit einer statischen IP Route deiner VPN Netze auf deine FritzBox fixen! Diese hat eine höhere Priorität vor dem Gateway Redirect des OpenVPN und dann sollte es mit dem VPN sofort klappen. Dein Test zeigt es ja auch eindeutig!
Temporär kannst du mit der Route ip route add 172.25.24.0/23 via 192.168.188.1 dafür sorgen das es dann zumindestens auf dem Sat RX auch mit OVPN klappt!!
Ein ip r sollte dir dann auf dem Sat RX die korrekte Routing Tabelle anzeigen so das du siehst das der VPN Tarric zu 172.25.24.0 /23 dann zur FritzBox geht.
Diese statische Route überlebt aber kein Reboot! Je nach Distro musst du das dann permanent machen.
Bei einer Debian basierten Distro z.B.
https://www.cyberciti.biz/faq/ip-route-add-network-command-for-linux-exp ...
https://www.mybluelinux.com/debian-permanent-static-routes/
Bleibt dann nur noch dein NAS. Das ist da aber de facto ein HTTP Problem da IPtechnisch alles rennt.
ch denke, es schadet nicht, den Eintrag "dns = 192.168.188.1" um ",9.9.9.9" oder ",1.1.1.1" zu ergänzen.
So ist es! So hast du immer eine Redundanz.Habe im NAS WebIF die markierte Option aktiviert und schon geht es!
👍 Kleine Ursache, große...Wenn es die 7.5er für meine FB gäbe
Sorry, hatte ich vergessen... Geht aber wegen DS lite nur mit IPv6
Dennoch kann man aber IPv4 im IPv6 Tunnel übertragen. Das Konzept die VPN Netzkopplung direkt über die FB zu machen ist aber deutlich besser als mit einem extra Host wo du noch ungeschützen Internet Traffic in dein lokales Netz schicken musst. Das ist immer ein schlechtes Design!
das war ja einfacher als ich dachte. Das mit der permanenten Lösung kriege ich auch noch hin.
👍👏 Tja, die simplen Basics von einfachem IP Routing. 😉Das sieht ja dann so aus als ob nun alles zur Zufriedenheit rennt, oder?
Sollte ich es mir anders überlegen?
Tja, das muss jeder selber für sich entscheiden. So gut wie alle diese Anbieter sind im Besitz von Unternhemen in totalitären Staaten wo auch die meisten Exit Points liegen. Oder sie nutzen Kundenanschlüsse nach GeoIP ungefragt als Exit Points. Da muss man sicher nicht noch erklären das da auch heftigst geschnüffelt und geschnorchelt wird. Wenn man damit leben kann....?!Was haltet ihr von VPN?
Du hast Recht, das ist in der Tat etwas komisch, das es immer die gleiche Gruppe ist. Wäre es der VPN Client oder die IP Connectivity an sich hast du Recht, dann würde sich das generell auf alle Endgeräte im Heimnetz auswirken, denn der Client weiss ja nicht wer oder was sich hinter einer IP verbirgt.
Hast du eine Chance einmal einen zusätzlichen IKEv2 onboard Client wie Windows, Apple etc. zu testen wie das Verhalten dort aussieht?
Interessant wäre es auch diesen alternativen Client (Laptop, MacBook etc.) einmal per Tethering an das Smartphone zu hängen und nochmal zu versuchen.
So kann man wasserdicht testen ob es ggf. ein Client Problem oder auch ein Problem des Smartphones und der mobilen Datenanbindung an sich ist.
Andere Frage: Hast du mal gecheckt ob dein Androide nicht auch einen nativen IKEv2 Client onboard hat wie z.B. die iPhones und iPads? Die meisten modernen Androiden haben das. Dann wäre der externe Client überflüssig, denn die onboard Clients sind in der Regel deutlich besser ins OS integriert vom Hersteller.
Ich nutze häufig so ein System mit Windows/Mac und iPhone onboard Clients und habe noch nie so ein Verhalten beobachtet.
Hast du eine Chance einmal einen zusätzlichen IKEv2 onboard Client wie Windows, Apple etc. zu testen wie das Verhalten dort aussieht?
Interessant wäre es auch diesen alternativen Client (Laptop, MacBook etc.) einmal per Tethering an das Smartphone zu hängen und nochmal zu versuchen.
So kann man wasserdicht testen ob es ggf. ein Client Problem oder auch ein Problem des Smartphones und der mobilen Datenanbindung an sich ist.
Andere Frage: Hast du mal gecheckt ob dein Androide nicht auch einen nativen IKEv2 Client onboard hat wie z.B. die iPhones und iPads? Die meisten modernen Androiden haben das. Dann wäre der externe Client überflüssig, denn die onboard Clients sind in der Regel deutlich besser ins OS integriert vom Hersteller.
Ich nutze häufig so ein System mit Windows/Mac und iPhone onboard Clients und habe noch nie so ein Verhalten beobachtet.
ich wäre gut beraten, wenn ich auch client-seitig ein StrongSwan-Produkt nutze.
3mal darfst du raten was ALLE Software Produkte und VPN Router von der Stange im Backend nutzen??!! Das ist immer der charon Daemon (Strongswan). Natürlich auch in Android selber und auch in der Fritzbox, was ja immer alles Linux ist. 😉Es sieht aber bisher sehr gut aus!
So sollte es sein! 👍👏
Da hast du natürlich Recht! Das liegt daran, weil die Zertifikatsverwaltung von Windows nur für .crt Extensions einen Autostart macht.
Startet man aber die Zert. Verwaltung certlm per Hand und wählt das Verzeichnis "Vertrauenswürdige Stammzertifizierungsstellen", wählt dann "Aktionen" und "Importieren" dann kann man auch ebenso Dateien mit der Endung .pem importieren.
Das ist aber ein guter Hinweis und ich werde das Tutorial dementsprechend anpassen! 👍
Startet man aber die Zert. Verwaltung certlm per Hand und wählt das Verzeichnis "Vertrauenswürdige Stammzertifizierungsstellen", wählt dann "Aktionen" und "Importieren" dann kann man auch ebenso Dateien mit der Endung .pem importieren.
Das ist aber ein guter Hinweis und ich werde das Tutorial dementsprechend anpassen! 👍