gonzoll
Goto Top

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"):

fritz

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?

Content-ID: 7503028022

Url: https://administrator.de/forum/jumphost-vpn-ipsec-7503028022.html

Ausgedruckt am: 20.12.2024 um 01:12 Uhr

aqui
aqui 13.06.2023, aktualisiert am 15.06.2023 um 12:40:31 Uhr
Goto Top
Sollte hier die Status LED nicht schon grün sein?
Das kommt, wie immer, drauf an... face-wink
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 error
Was 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. face-sad

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.
Gerade Letzteres ist wichtig weil es den Tunnelaufbau und ggf. auftretende Fehler beider Endgeräte (Android und Fritzbox) mit dem Jumphost mitloggt.
So wie das Folgende sollte es bei dir aussehen...


back-to-topIKEv2 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 

back-to-topFritzbox 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 

back-to-topvServer 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"
     }
...
} 

back-to-topPassende 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!! 👍 😉
aqui
aqui 16.06.2023 um 15:30:55 Uhr
Goto Top
Wenn es das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu schliessen!
gonzoll
gonzoll 16.06.2023 um 15:49:59 Uhr
Goto Top
Hallo Aqui,
vielen Dank, für deine ausführliche Antworten und dafür, dass du dir die Zeit genommen hast mir zu helfen. Leider bin ich noch nicht dazu gekommen, deine Tipps zu befolgen. Ich kümmere mich darum, sobald es meine Zeit zulässt, und werde dann hier berichten.

Grüße!
aqui
aqui 16.06.2023 aktualisiert um 16:54:09 Uhr
Goto Top
OK, Es bleibt also spannend! Dann harren wir mal der hoffentlich positiven Dinge?! face-wink
gonzoll
gonzoll 18.06.2023 aktualisiert um 13:11:47 Uhr
Goto Top
Hallo Aqui,

habe den Test (mit selben traurigen Ergebnis) wiederholt und versuche hier diesmal, mehr Input zu liefernface-smile

1. Meine Jumphost Server Konfig (annonymisiert)
connections {
   fritzbox {
      local_addrs = <vps.server.ip>
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = <vps.server.ip>
          }
      remote {
          auth = psk
          id = keyid:strongswan@fritz.box
          }
      children {
          net {
              local_ts = 172.25.24.0/23
              remote_ts = 192.168.188.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }

   ikev2-mobile-defaults {
      unique = replace
      version = 2
      proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha256-modp1024
      send_cert = always
      pools = pool-ipv4
      local_addrs = <vps.server.ip>
      remote_addrs = 0.0.0.0/0,::/0
      local {
         auth = pubkey
         certs = server-cert.pem
         id = fqdn:<vps.server.fqdn>
      }
      remote {
         id = %any
         auth = eap-mschapv2
         eap_id = %any
       }
       children {
          ikev2-mobile {
          local_ts = 0.0.0.0/0
          esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1
          start_action = trap
          }
      }
   }
}
pools {
    pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 9.9.9.9,192.168.188.1
    }
}
secrets {
 eap-1 {
     id = user1
     secret = "<secret1>"  
     }
 eap-2 {
     id = user2
     secret = "<secret2>"  
     }
 ike-3 {
      id = keyid:strongswan@fritz.box
      secret = "<fritz.box.passwd>"  
     }
}


2. Meine FritzBox Konfig Datei (annonymisiert)
vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "StrongSwan";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <vps.server.ip>;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 172.25.24.1;
				localid {
                        key_id = "strongswan@fritz.box";  
                        }
                remoteid {
                        ipaddr = <vps.server.ip>;
                        }
                mode = phase1_mode_idp;
                phase1ss = "LT8h/all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "<fritz.box.passwd>";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.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";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
} 

3.Output von swanctl -q
root@ubuntu:~# swanctl -q
loaded certificate from '/etc/swanctl/x509/server-cert.pem'  
loaded certificate from '/etc/swanctl/x509ca/raspica-cert.pem'  
loaded RSA key from '/etc/swanctl/private/raspica-key.pem'  
loaded RSA key from '/etc/swanctl/private/server-key.pem'  
loaded eap secret 'eap-1'  
loaded eap secret 'eap-2'  
loaded ike secret 'ike-3'  
no authorities found, 0 unloaded
loaded pool 'pool-ipv4'  
successfully loaded 1 pools, 0 unloaded
loaded connection 'fritzbox'  
loaded connection 'ikev2-mobile-defaults'  
successfully loaded 2 connections, 0 unloaded

4.Mit einem Output von swanctl -T, wenn ich den Androiden danach neu starte und ihn am VPS einwählen lasse, kann ich nicht dienen, denn es gibt schlicht keinenface-sad
Habe zunächst swanctl -q aufgerufen und dann per Android Handy mich versucht, mit dem VPS Server zu verbinden. Der VPN Client liefet hier erneut "received NO_PROPOSAL_CHOSEN notify error" und swanctl -T liefert keinen Output:

root@ubuntu:~# swanctl -T
 

Wie ich die Fritzbox mit dem VPS neubverbinden soll, weiß ich nicht, denn ich sehe im FB Interface keine Option, wie ich eine VPN-Verbindung beenden und danach neustarten könnte, außer die bestehende Konfig zu löschen und sie anschließend neueinzurichten.

Und für alle Fälle hier meine Firewall Konfig des VPS:
firewall
aqui
aqui 18.06.2023 aktualisiert um 14:20:33 Uhr
Goto Top
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 
(Hier kannst du sehr schön das IKE Handshaking und den Wechsel auf NAT Traversal UDP 4500 sehen)

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)
gonzoll
gonzoll 18.06.2023 um 15:21:16 Uhr
Goto Top
Hi,

so, ich denke, wir kommen der Sache näher. Ich bin mal so arrogant und schließe Option 1 [IP Adresse des vServers im VPN Client stimmt nicht] aus ;)

Option 2:
root@ubuntu:~# tcpdump -i ens6 -n -t port 500 or 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 80.xxx.xxx.xxx.22858 > 82.xxx.xxx.xxx.500: isakmp: parent_sa ikev2_init[I]
IP 82.xxx.xxx.xxx.500 > 80.xxx.xxx.xxx.22858: isakmp: parent_sa ikev2_init[R]
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident
IP 82.xxx.xxx.xxx.500 > 94.xx.xx.xx.14500: isakmp: phase 2/others R inf
IP 80.xxx.xxx.xxx.22902 > 82.xxx.xxx.xxx.500: isakmp: parent_sa ikev2_init[I]
IP 82.xxx.xxx.xxx.500 > 80.xxx.xxx.xxx.22902: isakmp: parent_sa ikev2_init[R]
IP 94.xx.xx.xx.14500 > 82.xxx.xxx.xxx.500: isakmp: phase 1 I ident

Die 94er IP, das ist mein SSH Client über den ich mit dem VPS verbunden war und tcpdump aufgerufen habe.
Die 82er IP ist der VPS, und die 80er ist mein Android, über den ich versucht habe, die VPN-Verbindung aufzubauen. Das sieht man auch an "ikev2" Einträgen im Log, die wohl IPSec bezogen sind.

Was folgern wir daraus?
Ich denke, dass:
1. Die IP, die ich in der VPN Konfig verwende, stimmt.
2. VPS blockiert den VPN Traffic
3. Mein Provider blockiert den VPN Traffic nicht.

Sehe ich das richtig? Falls ja, kann ich meinen Vertrag bei IONOS in die Tonne kloppen? Wäre schade, habe nämlich für 12 Monate unterschrieben ;)

Was ich darüber hinaus nicht verstehe: Wenn der VPS den VPN Traffic blockiert, warum sehe ich im Android-Client-Log, dass der VPN-Server überhaupt antwortet? Siehe Eintrag

Jun 12 19:47:29 08[NET] received packet: from 8....5[500] to 192.0.0.2[54985] (36 bytes)

...im 1.Beitrag.
aqui
aqui 18.06.2023 aktualisiert um 15:45:23 Uhr
Goto Top
Ist etwas unverständlich jetzt...?! 🤔
  • "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. face-sad
  • "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.
Nur eben auf diesen Response antwortet der Androide dann einfach nicht mehr und bleibt nur noch stumm. ☹️ Deshalb scheitert auch die swanctl -T Anzeige weil der Androide den Tunnel nicht startet.
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.
gonzoll
gonzoll 18.06.2023 um 17:27:53 Uhr
Goto Top
Zunächst einmal erneut einen Riesendank für deine schnellen und sehr hilfreichen Antworten und Ratschläge! Ich denke, ich bin zwar immer noch nicht ganz am Ziel (Client sagt: Authentifizierung des Servers ist fehgeschlagen), aber schon einen großen Schritt weiter. Aber eins nach dem anderen:

Die 94er IP ist die (Gruppen-)IP, die mir mein ISP (DG) zuweist. Deswegen habe ich angenommen, dass es die SSH Session sein müsste, die ich im tcpdump Log sah, weil mir diese Connection von meinem Netzwerk zum VPS als erste einfiel. Theoretisch könnte das aber auch die VPN Verbindung der Fritzbox sein, oder die des PCs zum Web-Interface des VPS - keine Ahnung...

Aber egal, das Wichtigste ist, dass nachdem ich den Tipp mit systemctl restart strongswan befolgt habe, die Situation sich grundlegend geändert hat, denn nun habe ich:
1. eine Ausgabe in swantctl -T
2. eine andere Fehlermeldung im VPN Client des Handys (habe übrigens den strongSwan VPN Client 2.4.1 aus dem Play Store auf dem Handy installiert)
3.Die LED bei der VPN Verbindung im Fritzbox-Web-IF ist jetzt grün!

fritz

Die Verbindung kommt jetzt zwar immer noch nicht erfolgreich zu Stande, doch es wurde schon eine ganze Menge an Infos zwischen Server und Client ausgetauscht. Ich will jetzt nicht das ganze Log hier reinkopieren, weil das lang ist und beschränke mich nur auf die letzten meiner Meinung entscheidenden Zeilen:

Client-Log (anonymisiert):
Jun 18 16:42:37 11[IKE] received end entity cert "CN=82-xxx-xx-xxx.nip.io"  
Jun 18 16:42:37 11[CFG]   using certificate "CN=82-xxx-xx-xxx.nip.io"  
Jun 18 16:42:37 11[CFG]   using trusted ca certificate "CN=RasPi CA"  
Jun 18 16:42:37 11[CFG]   reached self-signed root ca with a path length of 0
Jun 18 16:42:37 11[CFG] checking certificate status of "CN=82-xxx-xx-xxx.nip.io"  
Jun 18 16:42:37 11[CFG] certificate status is not available
Jun 18 16:42:37 11[IKE] authentication of '82-xxx-xx-xxx.nip.io' with RSA_EMSA_PKCS1_SHA2_256 successful  
Jun 18 16:42:37 11[CFG] constraint check failed: identity '82.xxx.xx.xxx' required   
Jun 18 16:42:37 11[CFG] selected peer config 'android' unacceptable: constraint checking failed  
Jun 18 16:42:37 11[CFG] no alternative config found
Jun 18 16:42:37 11[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Jun 18 16:42:37 11[NET] sending packet: from 192.0.0.2[34981] to 82.xxx.xx.xxx[4500] (96 bytes)

Server-Log (anonymisiert):
11[CFG] looking for peer configs matching 82.xxx.xx.xxx[%any]...80.xxx.xxx.xx[user1]
11[CFG] selected peer config 'ikev2-mobile-defaults'  
11[IKE] initiating EAP_IDENTITY method (id 0x00)
11[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
11[IKE] peer supports MOBIKE
11[IKE] authentication of '82-xx-xx-xxx.nip.io' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful  
11[IKE] sending end entity cert "CN=82-xx-xx-xxx.nip.io"  
11[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
11[NET] sending packet: from 82.xxx.xx.xxx[4500] to 80.xxx.xxx.xx[6456] (1200 bytes)
16[NET] received packet: from 80.xxx.xxx.xx[6456] to 82.xxx.xx.xxx[4500] (96 bytes)
16[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
16[ENC] generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]
16[NET] sending packet: from 82.xxx.xx.xxx[4500] to 80.xxx.xxx.xx[6456] (96 bytes)
14[KNL] creating delete job for CHILD_SA ESP/0xc9b64a20/82.xxx.xx.xxx
14[JOB] CHILD_SA ESP/0xc9b64a20/82.xxx.xx.xxx not found for delete
12[KNL] creating delete job for CHILD_SA ESP/0x99af92f8/94.31.91.57
12[JOB] CHILD_SA ESP/0x99af92f8/94.31.91.57 not found for delete

Der Aufruf systemctl restart strongswan scheint wohl den Server neuzustarten, und ich dachte ein swanctl -q würde reichen, wenn man zuvor was an den Einstellungen gedreht hat...

Hast du eine Idee, woran es jetzt noch hakt, dass die Authentifizierung des Servers fehgeschlägt?
aqui
aqui 19.06.2023 aktualisiert um 12:35:59 Uhr
Goto Top
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
("user2" ist hier der MSChapv2 Username des VPN Clients (Windows, Xiaomi oder iPhoneX)

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   
Die CA Zertifikatsdatei gonzollca-cert.pem musst du in die VPN Clients in deren Zertifikatsspeicher importieren!

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   
ACHTUNG: 82-xx-xx-xxx.nip.io sollte natürlich genau stimmen und auch pingbar sein!!

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! face-wink

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.
gonzoll
gonzoll 19.06.2023 aktualisiert um 19:47:47 Uhr
Goto Top
So, im VPN Client auf dem Android Handy bei Server "82.xxx.xxx.xxx" durch "82-xxx-xxx-xxx.nip.io" ersetzt und...

321

ERFOLG face-smile

Aber kein 100%er, denn irgendwas muss immer schiefgehen ;)
Ich kann per VPN nicht auf alle Ressourcen zuhause zugreifen

Worauf ich zugreifen kann per Web-IF:
  • Beide Fritzboxen und auf den Fritz Repeater
  • Drucker
  • GL-iNet Router (hinter der Fritzbox)
  • Netgear Switch
  • Raspberry Pi (Pi-hole)
  • QNAP NAS

Auf folgende Ressourcen kann ich nicht zugreifen:
  • WD NAS (Forbidden: You don't have the permission to access / on this server)
  • meine Linux SAT-Receiver (Website ist nicht erreichbar)

Auf alle o.g. Ressourcen kann ich aus dem lokalen Netz problemlos zugreifen. Wo gibt es noch Verbesserungspotential?

Mein Mail Client scheint auf dem Handy über VPN auch keine Verbindung zum Mail-Server herstellen zu können. Das liegt wohl daran, dass ich generell aufs Internet nicht zugreifen kann, wenn ich über VPN mit Zuhause verbunden bin. Dazu habe ich was in deiner Anleitung gelesen und meine, es auch befolgt zu haben, doch wahrscheinlich nicht ganz richtig..? Habe auf dem vServer /etc/nftables.conf editiert und angepasst:

table ip nat {

        define VPN_NETS = {
        192.168.188.0/24
        }
        # fuer VPN Client Pakete ins Internet masquerade ausser VPN Netzwerke
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname ens6 ip daddr $VPN_NETS accept
                ip saddr 172.25.25.0/24 oif ens6 masquerade
        }

Trotzdem kein Internet am VPN Client...

P.S. Die "Gruppen-IP" ist der verunglückte Versuch, Folgendes auszudrücken: Bin Kunde bei der DG und habe keine öffentliche IPv4 - deswegen ja der ganze Umstand mit VPN über vServer. Die Fritzbox zeigt trotzdem eine "zugewiesene" IPv4 an. Wenn ich mich nicht täusche, ist eine private IPv4, die mir die DG zuweist, die allerdings nur im DG-Netz gilt und nicht von außen erreichbar ist.

1.000 Dank schon mal, dass ich mit deiner Hilfe soweit gekommen bin, Aqui!
aqui
aqui 19.06.2023 aktualisiert um 20:27:17 Uhr
Goto Top
OK, das sieht ja schon mal ganz gut aus. Zeigt das grundlegend (fast) alles rennt wie es soll! 👍
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)
Welcher DNS Server mit der VPN Einwahl an den Client übergeben wird steuert im Strongswan Setup der Abschnitt:
pools {
  pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 9.9.9.9
    }
  } 
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!
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. face-sad
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! 🙂
gonzoll
gonzoll 20.06.2023 aktualisiert um 12:47:28 Uhr
Goto Top
Erneut bin ich dank deiner Tipps weitergekommen. Bin aber immer noch nicht ganz am Ziel.
Habe als erstes versucht, vom VPN Client eine externe IP zu pingen - ohne Erfolg. Der Aufruf von nft list ruleset auf dem VPN Server brachte keinen Output. Erst nachdem ich über systemctl start nftables.service den Service neugestartet habe, führte der Aufruf von nft list ruleset zu einem sinnvollen Output. Danach konnte ich auch vom Client pingen. Die Host-Auflösung funktionierte aber immer noch nicht. Der DNS war in strongSwan folgendermaßen konfiguriert:

pools {
  pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 192.168.188.10
    }
  } 

Die IP 192.168.188.10 gehört meinen Pi hole im Hausnetz (die Fritzbox hat die 192.168.188.1). War so naiv zu denken, ich könnte den Pi hole DNS auch über die VPN Clients mit nutzen. Nachdem ich den Eintrag auf 9.9.9.9 geändert habe, konnte ich nun auf einmal auch über den VPN Client auf dem Smartphone normal Internet Dienste nutzen (WWW & Mail). Das ist schon mal ein Fortschritt. Es gab aber auch einen kleinen Rückschritt, denn ich konnte nun keine Ressourcen im Heimnetz erreichen. Also habe ich den DNS Eintrag in meiner strongSwan Konfig auf "dns = 9.9.9.9,192.168.188.10" geändert - ohne Erfolg. Erst nach dem ich das auf "dns = 9.9.9.9,192.168.188.1" gestellt habe, kann ich von meinem VPN Client wieder auf Ressourcen im Heimnetzwerk wie auch auf das "Internet" zugreifen. BINGO!

Das bedeutet also, dass man bei der DNS Konfig von strongSwan:
  • die 9.9.9.9 für das "normale Internet" braucht,
  • die Fritzbox-IP für den Heimnetz-Zugang braucht,
  • den alternativen DNS im Heimnetz (Pi hole) nicht von VPN Clients mit nutzen kann(?)

Weiß nicht, ab man das so uneigeschränkt stehen lassen kann. Das bestätigt zumindest meine Beobachtung.

Zugriffe auf mein WD NAS Web Interface (Forbidden: You don't have the permission to access / on this server) wie auch auf meine Linux SAT-Receiver:

chrome

führen immer noch nicht zum Erfolg. Dieser Zugang ist zwar nicht lebensnotwendig, doch es wäre schön, von jedem Fleckchen der Erde, den Receiver für eine Aufnahme programmieren zu können ;) Habe nach der Einstellung des Default Gateways gesucht und bin zumindest bei den SAT Receivern fündig geworden. Dort ist die Fritzbox (192.168.188.1) als ein solcher konfiguriert.

Ich bin dir sehr dankbar, Aqui, weil ich mit deiner Hilfe eine Menge erreicht habe! Die letzten Paar Meter schaffen wir vielleicht auch noch ;)
aqui
aqui 20.06.2023 aktualisiert um 13:16:15 Uhr
Goto Top
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
Wenn du beides definierst z.B. 192.168.188.1, 9.9.9.9 fragt er zuerst die FB, ist die nicht verfügbar nach einer Timeout Zeit dann Quad9.
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! 💪
gonzoll
gonzoll 21.06.2023 um 19:57:52 Uhr
Goto Top
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.

Der einzige Grund, warum ich mich für dieses Setup entschieden habe, ist, über VPN und IPv4 mein Heimnetz aus fremden Netzen erreichen zu können. Dazu ist in jedem Fall ein funktionierender VPN Tunnel zur FB notwendig. Ist der mal unterbrochen, kann ich mein Heimnetz über VPN sowieso nicht erreichen. Wenn es mir also hierbei ausschließlich um die Erreichbarkeit meiner Ressourcen im Heimnetz geht, kann ich mir bei der DNS-Konfiguration einen zweiten DNS wie den Quad 9 auch gleich sparen. Sehe ich das richtig?
gonzoll
gonzoll 21.06.2023, aktualisiert am 22.06.2023 um 10:27:16 Uhr
Goto Top
Ein Ping auf diese Geräte sollte immer möglich sein!

Ich beschränke mich hier auf zwei Geräte, die ich über IPSec-VPN derzeit nicht erreichen kann:

1. 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"
Dieses Gerät ist also generell über das Netzwerk erreichbar, weil es grundsätzlich antwortet, auch wenn mir die Antwort nicht gefällt ;)
Update: Nachdem ich im WebIF des WD NAS die Option "Dashboard Cloud-Zugriff" aktiviert habe, klappt nun auch der Zugriff auf das WebIF des NAS über den StrongSwan VPN-Client!

2. Sat RX - ein Ping vom IPSec VPN Client ist nicht möglich

Hier ein Ping auf das Gerät vom lokalen (W)LAN (kein VPN):
ping_11_lan

Hier ein Ping auf das Gerät über Wireguard VPN:
ping_11_wg
WireGuard VPN ist meine bevorzugte Lösung - läuft super! Der Server läuft in meinem Heimnetz auf einem Pi3. Wegen DS lite ist er aber nur über IPv6 (also nur beschränkt) von außen erreichbar. Deswegen versuche ich, über einen Jumphost eine alternative VPN-Anbindung an mein Heimnetz über IPv4 herzustellen - das nur als Hintergrundinformation.

Und hier ein Ping(Versuch) auf das Gerät über StrongSwan VPN:
ping_11_ipsec

Was kann ich tun, um die Ursache zu finden, warum der Rechner sich hier so bockig stellt?

"uname -a" liefert für den Sat RX:
Linux et9x00 3.8.7 #1 SMP Fri Jan 1 16:50:51 UTC 2021 mips GNU/Linux

Es ist folgendes Image aufgespielt:
OpenATV 6.4.20210715 (2021-07-06)

Oder gehört die Frage eher in das OpenATV Forum als hierhin?
gonzoll
gonzoll 22.06.2023 um 12:30:05 Uhr
Goto Top
Ich meine nun die Ursache für die Verbindungsprobleme zu meinem Sat Rx gefunden zu haben. Leider weiß ich aber immer noch nicht, wie ich diese lösen soll, ohne Kompromisse eingehen zu müssen.

Auf dem Rx habe ich vor langer Zeit einen OpenVPN-Client eingerichtet. Wenn sich der Rx mit dem Internet verbindet, läuft das also ausschließlich über seinen OpenVPN-Client, der sich mit einem kommerziellen Anbieter verbindet, der als Host fungiert. Ich habe nun festgestellt, dass ich von meinem StrongSwan-VPN-Client mich mit dem Rx verbinden kann, sobald ich die OpenVPN-Verbindung auf dem Rx abschalte. Wenn ich sie wieder einschalte, ist die IPSec-VPN-Konnektivität mit dem Rx nicht möglich. Ich folgere daraus, dass man sich mit dem Rx aus dem lokalen Netz (192.168.188.0/24) problemlos verbinden kann, weil da die OpenVPN-Verbindung umgangen wird. Sobald man aber sich nicht in diesem Netz befindet, und das tue ich nicht, wenn ich ein StrogSwan-Client bin (172.25.25.0/24), wird der Rx sich auschließlich über OpenVPN mit mir unterhalten wollen. Macht meine Analyse Sinn?

Falls ja, 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 und auf keine OpenVPN-Komminukation besteht? Oder ist die Abschaltung der Open-VPN-Verbindung auf dem Rx die einzige Möglichkeit, ihn von meinem StrongSwan-VPN-Client zu erreichen?
aqui
Lösung aqui 22.06.2023 aktualisiert um 14:51:48 Uhr
Goto Top
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. face-sad
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. face-sad
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! face-sad
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!! face-sad

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!! face-wink
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.
gonzoll
gonzoll 22.06.2023 aktualisiert um 18:04:37 Uhr
Goto Top
Manchmal nutzt man so ein VPN auch wenn man an öffentlichen Hotspots nur sicher surfen will usw.
Da bringst du mich auf eine Ideeface-smile Ich denke, es schadet nicht, den Eintrag "dns = 192.168.188.1" um ",9.9.9.9" oder ",1.1.1.1" zu ergänzen.

Bleibt dann nur noch dein NAS. Das ist da aber de facto ein HTTP Problem da IPtechnisch alles rennt.
Hat sich erledigtface-smile Habe im NAS WebIF die markierte Option aktiviert und schon geht es!

wd

Eigentlich ja überflüssig wenn du eine FritzBox hast die FW Version 7.5 laufen lassen kann?!
Wenn es die 7.5er für meine FB gäbe, würde ich tatsächlich diese schon längst installiert und als WG-Server eingerichtet haben. Leider ist bei meiner FB 7580 bei FW Version 7.29 Schlussface-sad Und 250€ für eine Neue ist mir nur wg. WG zu viel. Deswegen der Pi als WG-Server für 50€ face-smile Geht aber wegen DS lite nur mit IPv6 face-sad

Mit "Rechner" Meinte ich nur den Sat RX. Das WD NAS ist nun erreichbar uns einsatzbereit face-smile

Uuhh böses Faul...Leichen im Keller! face-sad
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.
So ähnlich. Hat aber bisher gut funktioniert. Sollte ich es mir anders überlegen?

Klares Ja! Eine statische Route ist hier dein bester Freund! 🤔
statische Route also... Wieder was Neues für mich Anfänger face-smile Aber gut, man lernt nie aus. Ich werde mich einlesen und mein Glück probieren. Besser so, als wenn du gesagt hättest "nein, das geht nicht" face-smile

Vielen lieben Dank für deine Tipps und die Zeit, die du dir genommen hast, um mir zu helfen! Ich werde mich als nächstes in die (für mich) neue Thematik einer statischen Route einlesen und hier berichten. Kann aber ein wenig dauern...
gonzoll
gonzoll 22.06.2023 um 22:00:15 Uhr
Goto Top
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!!

ähm ... das war ja einfacher als ich dachte. Kurz eingegeben und in der nächsten Millisekunde funktioniert der Zugriff auf meinen Sat RX via VPN face-smile Das mit der permanenten Lösung kriege ich auch noch hin. Vielen Dank!!
aqui
aqui 23.06.2023 aktualisiert um 09:41:13 Uhr
Goto Top
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... face-sad
Geht aber wegen DS lite nur mit IPv6
Dennoch kann man aber IPv4 im IPv6 Tunnel übertragen. face-wink
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?
gonzoll
gonzoll 23.06.2023 um 12:27:29 Uhr
Goto Top
Das sieht ja dann so aus als ob nun alles zur Zufriedenheit rennt, oder?

Jein face-smile Also theoretisch ja, aber es gibt noch zwei (kleine) Haken:
  • Ich kann nun bis auf einen Linux basierten Rechner alle Heimnetzgeräte über StrongSwan VPN erreichen. An dem letzten verbliebenen arbeite ich noch und bin zuversichtlich, dass ich das auch (mit einer statischen Route) hinbekomme. Wenn mir die Ideen ausgehen, melde ich mich wieder und thematisiere das dann hier noch mal.
  • Ich beobachte, dass der StrongSwan Client auf dem Android Smartphone ziemlich oft ein Problem hat, eine bestimmte Untermenge meiner Heimressourcen zu erreichen. Ich weiß nicht, wie ich es beschreiben soll, denn das Verhalten ist für mich unverständlich. Es gibt eine Gruppe von Devices, und dazu zählen mein QNAP NAS, der Canon Drucker, der Netgear Switch und der GL iNet Router, die ich per IPSec-VPN immer erreichen kann. Dann gibt es die andere Gruppe: die AVM-Geräte, die Sat RXs und das WD NAS. Der Verbindungsaufbau über VPN zu diesen Geräten ist sehr unzuverlässig. Mal klappt es, mal nicht. Ich habe es noch nicht geschafft herauszufinden, unter welchen Umständen die Verbindung nicht klappt. Es sind aber immer dieselben Geräte, die ich zeitweise über meinen StrongSwan Client vom Android Smartphone nicht erreichen kann (timeout). Manchmal denke ich, es ist ein Android-StrongSwan-Client Problem, denn wenn ich das Handy neustarte, beobachte ich das Problem nicht. Auf der anderen Seite erschließt es sich mir nicht, warum dann immer nur dieselbe Untermenge an Devices nicht erreichbar ist. Wenn der Client ein Problem hätte, dann würde er wahrscheinlich mit keinem Gerät zuhause kommunizieren können, denke ich. Desweiteren meine ich beobachtet zu haben, dass wenn ich mit dem Smartphone in meinem Heimnetz über WLAN verbunden bin und dann (testweise) den Client starte und die IPSec-VPN-Verbindung aufbaue, funktioniert diese ziemlich zuverlässig. Alle Geräte sind erreichbar. Wenn ich aber WLAN deaktiviere und mich über mobile Daten mit dem Internet verbinde, dann den VPN Client starte, ist die Anbindung an mein Heimnetz unzuverlässig. Damit meine ich, dass die oben genannte Gruppe von Devices nicht immer erreichbar ist (mal geht es, mal geht es nicht), während die erste Gerätegruppe immer erreichbar ist. Sorry, wenn das jetzt ein wenig wirr rüberkommt. Ich verstehe das Problem selber nicht und weiß nicht wirklich, wie ich es sinnvoll darstellen soll. Das krasse an der Geschichte ist, folgendes Beispiel, das ich schon öfter beobachtet habe: Das Handy ist über mobile Daten (T-Mobile) verbunden. Ich starte den VPN-Client. Der Verbindungsaufbau zum vServer funktioniert bisher immer und ist recht performant. Dann beobachte ich, dass ich die erste Gerätegruppe erreichen kann und die zweite nicht. Ich lege das Handy an die Seite, die VPN-Verbindung bleibt aufgebaut. Nach einer halben Stunde nehme ich das Handy wieder in die Hand und ... kann nun alle Geräte aus Gruppe 1 und 2 ausnahmslos erreichen. Unterschiedliches Verhalten innerhalb derselben VPN-Session also. Das macht mich ein wenig ratlos...

Aber ich will nicht meckern, denn ich habe schon sehr viel erreicht - dank deiner Hilfe!

P.S. Kommerzielle VPN Anbieter: Habe mir den von dir empfohlenen Beitrag durchgelesen und fand ihn interessant. Das mit den eingebauten Trackern wusste ich bisher nicht... Ich nutze den VPN Dienst selten zum Surfen. Die Hauptmotivation war, Geo Blocking zu umgehen und möglichst anonym zu sein (Exit Point, der nicht mit mir in Verbindung gebracht werden kann). Das Erste funktioniert, das Zweite wohl nur unter Vorbehalt.
aqui
aqui 23.06.2023 aktualisiert um 12:48:51 Uhr
Goto Top
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.
gonzoll
gonzoll 27.06.2023 um 19:47:11 Uhr
Goto Top
Habe deinen Rat befolgt und den nativen IKEv2 Client des Android Smartphones jetzt ein Paar Tage lang getestet, und ... habe bisher keine Ausfälle beobachten können, zumindest nicht über mobile Daten. Der StrongSwan Client versagte aber auch schon hin und wieder bei einer Verbindung über mobile Daten. Als Nächstes werde ich das mal in einem öffentlichen WLAN ausprobieren. Es sieht aber bisher sehr gut aus!
Da der IKEv2-Server auf dem vServer eine StrongSwan-Lösung ist, habe ich angenommen, ich wäre gut beraten, wenn ich auch client-seitig ein StrongSwan-Produkt nutze. Dem scheint aber nicht so zu sein. Hätte ich bloß von Anfang an auf dich gehört... ;)
aqui
aqui 28.06.2023 um 10:19:24 Uhr
Goto Top
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! 👍👏
gonzoll
gonzoll 30.06.2023 um 13:32:42 Uhr
Goto Top
Ich habe nun im nächsten Schritt die VPN Verbindung über einen Windows Client ausprobiert und auch zum Laufen gebracht. Der einzige Schritt deiner Anleitung, bei dem ich ein wenig improvisieren musste, betrifft das Importieren des Zertifikats unter Windows. Du sprichts von einer *.crt Datei, auf die man doppelklicken muss. Mein Zertifikat hatte die Extension *.pem. Mein Windows konnte nichts mit einer *.pem Datei anfangen. Nachdem ich sie aber nach *.crt umbenannt habe, lief alles wie beschrieben!
aqui
aqui 01.07.2023 aktualisiert um 14:02:35 Uhr
Goto Top
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.
zertimp
Das ist aber ein guter Hinweis und ich werde das Tutorial dementsprechend anpassen! 👍