VPN, 7390, 7270, 7170, StrongSwan

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Denke der ipsec läuft nicht auf deinem vServer. Was sagen denn die Logfiles?

Dazu evtl. mal plutodebug=all setzen.
 
Also ich habe jetzt plutodebug=all gesetzt. Alles unter /var/log gelöscht und mit "ipsec start" den daemon gestartet.
Nur wo sind die Logfiles? Die sollten doch irgendwo unter /var/log/ sein, oder nicht?
IPsec an sich müsste auf diesem Vserver gehen: zumindest bekomme ich mit vpnc eine VPN-Verbindung hin zur Fritzbox.
 
Bist Du Linux-Neuling?
Falls Du die Logs wirklich gelöscht hast, musst Du den syslog-Daemon neu starten. Dann siehst Du ja welche Datei(en) größer werden. Vermutlich in messages.
Einfacher ist die Log-Dateien nur zu leeren. Das geht mit ": > logdatei"

vpnc ist ein Client. Der hat mit dem IPsec-Daemon nichts zu tun.

Ferner ist mir aufgefallen, daß Du in der ipsec.secrets den Key mit ' statt " eingeschlossen hast. Bin nicht sicher, ob das ein Problem ist.
 
Ein Neuling eigentlich seit einigen Jahren nicht mehr, aber das mit den Logs wusste ich nicht - ich dachte die werden nach dem Löschen einfach neu angelegt.
Außerdem habe ich erwartet, dass es irgendeinen /var/log/ipsec.log gibt. Wie auch immer.
Des Rätsels Lösung scheint sich in /var/log/auth.log und in /var/log/daemon.log zu befinden.
Code: 
			>>>	auth.log	<<<
Dec 27 09:45:05 asterisk ipsec_starter[12772]: Starting strongSwan 4.5.2 IPsec [starter]...
Dec 27 09:45:05 asterisk ipsec_starter[12772]: no netkey IPsec stack detected
Dec 27 09:45:05 asterisk ipsec_starter[12772]: no KLIPS IPsec stack detected
Dec 27 09:45:05 asterisk ipsec_starter[12772]: no known IPsec stack detected, ignoring!
Dec 27 09:45:05 asterisk pluto[12780]: Starting IKEv1 pluto daemon (strongSwan 4.5.2) THREADS SMARTCARD VENDORID
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'test-vectors': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'curl': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'ldap': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'aes': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'des': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'sha1': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'sha2': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'md5': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'random': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'x509': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'pkcs1': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'pgp': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'dnskey': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'pem': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'openssl': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'gmp': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'hmac': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'xauth': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'attr': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: listening on interfaces: 
Dec 27 09:45:05 asterisk pluto[12780]:   venet0 
Dec 27 09:45:05 asterisk pluto[12780]:     127.0.0.2 
Dec 27 09:45:05 asterisk pluto[12780]:     84.200.77.111 
Dec 27 09:45:05 asterisk pluto[12780]:     2001:1608:10:39::c30:ccc 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'kernel-netlink': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: | plugin 'resolve': loaded successfully 
Dec 27 09:45:05 asterisk pluto[12780]: loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem openssl gmp hmac xauth attr kernel-netlink resolve  
Dec 27 09:45:05 asterisk pluto[12780]: | inserting event EVENT_REINIT_SECRET, timeout in 3600 seconds
Dec 27 09:45:05 asterisk pluto[12780]:   including NAT-Traversal patch (Version 0.6c) [disabled]
Dec 27 09:45:05 asterisk pluto[12780]: | pkcs11 module '/usr/lib/opensc-pkcs11.so' loading...
Dec 27 09:45:05 asterisk pluto[12780]: failed to load pkcs11 module '/usr/lib/opensc-pkcs11.so'
Dec 27 09:45:05 asterisk pluto[12780]: FATAL ERROR: socket() in init_pfkeyfd(). Errno 97: Address family not supported by protocol
Dec 27 09:45:05 asterisk pluto[12780]: | certs and keys locked by 'free_preshared_secrets'
Dec 27 09:45:05 asterisk pluto[12780]: | certs and keys unlocked by 'free_preshard_secrets'
Dec 27 09:45:05 asterisk pluto[12780]: | crl fetch request list locked by 'free_crl_fetch'
Dec 27 09:45:05 asterisk pluto[12780]: | crl fetch request list unlocked by 'free_crl_fetch'
Dec 27 09:45:05 asterisk pluto[12780]: | ocsp fetch request list locked by 'free_ocsp_fetch'
Dec 27 09:45:05 asterisk pluto[12780]: | ocsp fetch request list unlocked by 'free_ocsp_fetch'
Dec 27 09:45:05 asterisk pluto[12780]: | authcert list locked by 'free_authcerts'
Dec 27 09:45:05 asterisk pluto[12780]: | authcert list unlocked by 'free_authcerts'
Dec 27 09:45:05 asterisk pluto[12780]: | crl list locked by 'free_crls'
Dec 27 09:45:05 asterisk pluto[12780]: | crl list unlocked by 'free_crls'
Dec 27 09:45:05 asterisk pluto[12780]: | ocsp cache locked by 'free_ocsp_cache'
Dec 27 09:45:05 asterisk pluto[12780]: | ocsp cache unlocked by 'free_ocsp_cache'
Dec 27 09:45:05 asterisk pluto[12780]: | pkcs11 module finalized and unloaded
Dec 27 09:45:05 asterisk ipsec_starter[12779]: pluto has died -- restart scheduled (5sec)
Dec 27 09:45:05 asterisk ipsec_starter[12779]: pluto refused to be started
Dec 27 09:45:05 asterisk ipsec_starter[12779]: charon (12781) started after 20 ms
Dec 27 09:45:10 asterisk pluto[12798]: Starting IKEv1 pluto daemon (strongSwan 4.5.2) THREADS SMARTCARD VENDORID
           ; das wiederholt sich dann
Im /var/log/daemon.log steht
Code: 
Dec 27 09:45:05 asterisk charon: 00[DMN] Starting IKEv2 charon daemon (strongSwan 4.5.2) 
Dec 27 09:45:05 asterisk charon: 00[LIB] Padlock not found, CPU is GenuineIntel 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'padlock': failed to load - padlock_plugin_create returned NULL 
Dec 27 09:45:05 asterisk charon: 00[KNL] listening on interfaces: 
Dec 27 09:45:05 asterisk charon: 00[KNL]   venet0 
Dec 27 09:45:05 asterisk charon: 00[KNL]     127.0.0.2 
Dec 27 09:45:05 asterisk charon: 00[KNL]     84.200.77.111 
Dec 27 09:45:05 asterisk charon: 00[KNL]     2001:1608:10:39::c30:ccc 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on receive socket failed 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on send socket failed 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on send socket failed 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on receive socket failed 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on send socket failed 
Dec 27 09:45:05 asterisk charon: 00[KNL] unable to set IPSEC_POLICY on socket: Invalid argument 
Dec 27 09:45:05 asterisk charon: 00[NET] installing bypass policy on send socket failed 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts' 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts' 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts' 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts' 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading crls from '/etc/ipsec.d/crls' 
Dec 27 09:45:05 asterisk charon: 00[CFG] loading secrets from '/etc/ipsec.secrets' 
Dec 27 09:45:05 asterisk charon: 00[CFG]   loaded IKE secret for %any 
Dec 27 09:45:05 asterisk charon: 00[CFG] sql plugin: database URI not set 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'sql': failed to load - sql_plugin_create returned NULL 
Dec 27 09:45:05 asterisk charon: 00[CFG] loaded 0 RADIUS server configurations 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'medsrv' failed to load: /usr/lib/ipsec/plugins/libstrongswan-medsrv.so: cannot open shared object file: No such file or directory 
Dec 27 09:45:05 asterisk charon: 00[CFG] mediation client database URI not defined, skipped 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'medcli': failed to load - medcli_plugin_create returned NULL 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'nm' failed to load: /usr/lib/ipsec/plugins/libstrongswan-nm.so: cannot open shared object file: No such file or directory 
Dec 27 09:45:05 asterisk charon: 00[CFG] HA config misses local/remote address 
Dec 27 09:45:05 asterisk charon: 00[LIB] plugin 'ha': failed to load - ha_plugin_create returned NULL 
Dec 27 09:45:05 asterisk charon: 00[DMN] loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 revocation constraints pubkey pkcs1 pgp pem openssl fips-prf gmp agent pkcs11 xcbc hmac ctr ccm gcm attr kernel-netlink resolve socket-raw farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc dhcp led addrblock  
Dec 27 09:45:05 asterisk charon: 00[JOB] spawning 16 worker threads 
Dec 27 09:45:05 asterisk charon: 08[CFG] received stroke: add connection 'test' 
Dec 27 09:45:05 asterisk charon: 08[CFG] added configuration 'test' 
Dec 27 09:45:10 asterisk charon: 12[CFG] received stroke: add connection 'test' 
Dec 27 09:45:10 asterisk charon: 12[CFG] added child to existing configuration 'test' 
Dec 27 09:45:10 asterisk charon: 14[CFG] received stroke: initiate 'test' 
Dec 27 09:45:10 asterisk charon: 14[CFG] ignoring initiation request for IKEv1 config 
Dec 27 09:45:15 asterisk charon: 16[CFG] received stroke: add connection 'test' 
Dec 27 09:45:15 asterisk charon: 16[CFG] added child to existing configuration 'test' 
Dec 27 09:45:20 asterisk charon: 16[CFG] received stroke: add connection 'test' 
Dec 27 09:45:20 asterisk charon: 16[CFG] added child to existing configuration 'test' 
Dec 27 09:45:25 asterisk charon: 16[CFG] received stroke: add connection 'test'

Die Gegenstelle ist eine 7390er mit 6.01 Firmware. Wenn ich dort manuell eine LAN-LAN Verbindung anlege (also ohne die cfg zu importieren wie es vor dieser Firmware gemacht werden musste), dann steht auf der Übersichtsseite der fritz.box, dass die VPN-Verbindung aufgebaut wird wenn ich kurz davor "ipsec up test" mache. Am Ende wird die Verbindung zwar nicht aufgebaut, aber irgendwie sagt mir das, dass mein vserver doch ipsec kann und es nur an irgendwelchen falschen configs scheitert.
 
Meines Erachtens nach stürzt Dein pluto mit dem Fehler ab:

FATAL ERROR: socket() in init_pfkeyfd(). Errno 97: Address family not supported by protocol

Danach würde ich mal googeln.
 
Ich habe damit heute (gestern) mal rumgespielt, es klappte auf Anhieb. Layer9-vpn-Konfigurationsdatei (mit eigenen Daten und anderem Secret) auf 7490 hochgeladen, strongSwan-Konfiguration lt. Anleitung angepaßt — läuft. Offenes Problem: 7490 hat dynamische DSL-IP, strongSwan liest DNS aber nur beim Start aus => nach IP-Wechsel müßte strongSwan neu gestartet werden.
Code: 
traceroute to 192.251.226.11 (192.251.226.11) from 192.168.176.4, 64 hops max, 40 byte packets
 1  gw.berlin.uu.org (192.168.176.2)  1 ms  1 ms  1 ms
 2  FB-VDSL-BRLN.uu.org (192.168.176.1)  1 ms  1 ms  1 ms
 3  susan.uu.org (192.251.226.11)  32 ms  32 ms  33 ms

traceroute to 192.251.226.11 (192.251.226.11), 64 hops max, 40 byte packets
 1  gw.berlin.uu.org (193.26.120.113)  2 ms  3 ms  5 ms
 2  susan.uu.org (192.251.226.11)  54 ms  61 ms  54 ms
 
Zuletzt bearbeitet:
Baut jetzt die Fritzbox zum Linux-Server die Verbindung auf, oder umgekehrt?
Normalerweise müsste die Fritzbox nach der Zwangstrennung und Erhalt neuer IP sich wieder beim Strongswan anmelden und alles müsste normal laufen (strongswan läuft auf einem Vserver mit fester IP).
Nur für den Fall der Fälle, dass ich da nichts missverstehe: rightid(id) ist der dyndns-Name meiner Fritte, rightsubnet=192.168.178.0/24 ist das Netzwerk meiner Fritte, left ist die feste IP des Linux-Servers mit Strongswan und leftsubnet ist ein beliebiger Netzwerk, was ich mir ausdenke?
 
Beide Richtungen klappt (wenn strongSwan die aktuelle DNS-Auflösung hat, dafür nehme ich "ipsec reload" derzeit).

Achtung, die FB (und auch strongSwan IIRC) baut das VPN nur auf, wenn Traffic darüber laufen soll. Also im Zweifel braucht's für den Automatismus 'n periodischen ping oder sowas.

"Left" ist der vServer, "right" Deine Fritte:
Code: 
    right=fritte.dyn.dns.service
    [email protected]
    rightsubnet=192.168.178.0/24

"Leftsubnet" ist das über IPSec zu routende Netz auf Seiten Deines vServers (und das muß entsprechend in die fritz.vpn-Datei rein, siehe layer9-Blogeintrag). "Rightsubnet" ist das Deiner Fritte ("Heimnetz"). Nur Verkehr zwischen diesen Netzen läuft über jenen IPSec-Tunnel. Und Vorsicht, daß Du Dich nicht aussperrst von Deinem vServer ;)
 
wusel-09 schrieb:
Beide Richtungen klappt (wenn strongSwan die aktuelle DNS-Auflösung hat, dafür nehme ich "ipsec reload" derzeit).
Zum Vergrößern anklicken....
Wenn Du nach der Anleitung bei layer9 den "main mode" verwendest, mußt Du die Identität der Gegenstelle vorher über den DNS-Namen auflösen können. Dabei geht es nicht nur darum, den richtigen Server (anhand seiner Adresse) auf der anderen Seite zu "treffen" ...

Beim Main-Mode steht die (IPSec-)Identität der Gegenstelle erst nach dem Aufbau des sicheren Kanals zur Verfügung. Ohne eine andere Quelle für diese Information (eben aus dem DNS) kann das Gateway keine passende Konfiguration selektieren. Im "aggressive mode" steht sie schon vor der Einrichtung eines sicheren Kanals zur Verfügung und damit kann das Gateway die korrekte Konfiguration für die Gegenstelle identifizieren.

Der "aggressive mode" ist aber gleichzeitig auch anfällig für Angriffe auf den Hash des PSK (damit erfolgt in diesem Modus die Identifizierung), also sollte dabei dann ein wirklich guter PSK (ich nehme grundsätzlich ab 32 Byte random) zum Einsatz kommen, der sowohl gegen Wörterbuchattacken als auch gegen Brute-Force-Angriffe immun ist. Dann ist auch der "aggressive mode" (bei Fritz!Boxen ohnehin der Standard) nicht gefährlicher ...

Ansonsten klappt IPSec mit dynamischen Gegenstellen und "main mode" nur mit Zertifikaten, denn da steht dann die Identität der Gegenstelle auch wieder vor dem Tunnelaufbau zur Verfügung.

Ich kenne die Schwäne nicht (bei mir läuft racoon), kann also nicht genau sagen, ob dort der "aggressive mode" überhaupt funktioniert (war nicht "pluto" da für den IKE zuständig ?) ...

Achtung, die FB (und auch strongSwan IIRC) baut das VPN nur auf, wenn Traffic darüber laufen soll. Also im Zweifel braucht's für den Automatismus 'n periodischen ping oder sowas.
Zum Vergrößern anklicken....
Ausgehend von seinen vorherigen Posts würde ich auf eine geplante Verbindung "Fritz!Box<>vServer mit Asterisk" tippen. In so einer Konstellation reicht es dann - bei meinen Boxen - in der Regel aus, auf der Fritz!Box eine "Eigene Rufnummer" einzutragen, die auf den Asterisk-Server zeigt (und möglichst auch funktioniert, sonst ist's mit 'Offenhalten' des VPN irgendwann Essig).

Damit hat man dann automatisch alles für den Aufbau der VPN-Verbindung seitens der Box ... inkl. "keepalive" per SIP-Ping - und muß sich nicht weiter um andere Mechanismen kümmern.
 
Ganz im Ernst, bei layer9 steht doch alles, was brauchst Du noch? Ich habe es jedenfalls so aufgesetzt – per genpw allerdings ein anderes PSK erzeugt und natürlich in vpncfg, ipsec.conf und ipsecrets.conf PSK, DNS-Namen und IPs geändert – und es klappte auf Anhieb.
 
Die Anleitung von layer9 habe ich natürlich gleich ganz am Anfang versucht. Sowie danach diverse andere Anleitungen.
Momentan bin ich so weit, dass strongswan sagt, dass die Verbindung besteht, aber fritzbox sagt "wird aufgebaut".
Code: 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "VPN zum V-Server";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 84.200.111.222;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "meindyndns.selfhost.bz";
                }
                remoteid {
                        ipaddr = 84.200.111.222;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.176.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.96.1;
                                mask = 255.255.255.255;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.96.1 255.255.255.255";
        }
        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";
}


// EOF
Code: 
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	plutodebug=all
	crlcheckinterval=180
	strictcrlpolicy=no
	charonstart=no

conn berlin
	aggressive=no
	ikelifetime=4h
	keylife=1h
	keyingtries=1
	keyexchange=ikev1
	left=84.200.111.222
	leftsubnet=192.168.96.1/32
	ike=aes256-sha-modp1024
	esp=aes256-sha1
	pfs=yes
       right=meindyndns.selfhost.bz
	[email protected]
	rightsubnet=192.168.176.0/24
	authby=secret
       auto=add
Code: 
: PSK geheim
Code: 
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: Starting strongSwan 5.1.2 IPsec [starter]...
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: # deprecated keyword 'plutodebug' in config setup
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: # deprecated keyword 'crlcheckinterval' in config setup
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: # deprecated keyword 'charonstart' in config setup
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: # deprecated keyword 'pfs' in conn 'berlin'
Jun 28 16:56:00 psychomantis ipsec_starter[8334]:   PFS is enabled by specifying a DH group in the 'esp' cipher suite
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: ### 4 parsing errors (0 fatal) ###
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: no netkey IPsec stack detected
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: no KLIPS IPsec stack detected
Jun 28 16:56:00 psychomantis ipsec_starter[8334]: no known IPsec stack detected, ignoring!
Jun 28 16:56:00 psychomantis ipsec_starter[8341]: charon (8342) started after 20 ms
Jun 28 16:56:01 psychomantis CRON[8360]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 28 16:56:01 psychomantis CRON[8360]: pam_unix(cron:session): session closed for user root
Jun 28 16:56:02 psychomantis charon: 10[IKE] 188.99.11.22 is initiating a Main Mode IKE_SA
Jun 28 16:56:04 psychomantis charon: 12[IKE] IKE_SA berlin[1] established between 84.200.111.222[84.200.111.222]...188.99.11.22[meindyndns.selfhost.bz]
Jun 28 16:56:34 psychomantis charon: 08[IKE] deleting IKE_SA berlin[1] between 84.200.111.222[84.200.111.222]...188.99.11.22[meindyndns.selfhost.bz]
Jun 28 16:56:34 psychomantis charon: 10[IKE] 188.99.11.22 is initiating a Main Mode IKE_SA
Jun 28 16:56:35 psychomantis charon: 12[IKE] IKE_SA berlin[2] established between 84.200.111.222[84.200.111.222]...188.99.11.22[meindyndns.selfhost.bz]
Jun 28 16:57:01 psychomantis CRON[8370]: pam_unix(cron:session): session opened for user root by (uid=0)
Code: 
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.2, Linux 2.6.32-042stab084.3, i686):
  uptime: 12 minutes, since Jun 28 16:56:00 2014
  malloc: sbrk 540672, mmap 0, used 181360, free 359312
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock
Listening IP addresses:
  84.200.77.3
  84.200.111.222
Connections:
      berlin:  84.200.111.222...meindyndns.selfhost.bz  IKEv1
      berlin:   local:  [84.200.111.222] uses pre-shared key authentication
      berlin:   remote: [meindyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.96.1/32 === 192.168.176.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      berlin[2]: ESTABLISHED 11 minutes ago, 84.200.111.222[84.200.111.222]...188.99.11.22[meindyndns.selfhost.bz]
      berlin[2]: IKEv1 SPIs: 4073807aec1e91b9_i 0a025cb27d46c1d0_r*, pre-shared key reauthentication in 3 hours
      berlin[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
root@psychomantis:~#

Sieht vielleicht jemand einen Fehler oder gibt es Ideen, was ich noch als Parameter probieren kann?
 
Ich habe die Änderungen zu meinem Setup mal markiert ...

PsychoMantis schrieb:
Code: 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "[COLOR="#FF0000"]84.200.111.222[/COLOR]";
                always_renew = [COLOR="#FF0000"]no[/COLOR];
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
[...]
Code: 
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	[COLOR="#FF0000"]#plutodebug=all[/COLOR]
	[COLOR="#FF0000"]#crlcheckinterval=600[/COLOR]
	[COLOR="#FF0000"]#strictcrlpolicy=yes[/COLOR]
        [COLOR="#FF0000"]# nat_traversal=yes[/COLOR]
	charonstart=no
        [COLOR="#FF0000"]# plutostart=yes[/COLOR]


conn berlin
	[COLOR="#FF0000"]#[/COLOR]aggressive=no
	ikelifetime=4h
	keylife=1h
	[COLOR="#FF0000"]#[/COLOR]keyingtries=1
	[COLOR="#FF0000"]#[/COLOR]keyexchange=ikev1
	left=84.200.111.222
	leftsubnet=192.168.96.1/32
	ike=aes[COLOR="#FF0000"]128[/COLOR]-sha-modp1024
	esp=aes[COLOR="#FF0000"]128[/COLOR]-sha1
	[COLOR="#FF0000"]#[/COLOR]pfs=yes
        right=meindyndns.selfhost.bz
	[email protected]
	rightsubnet=192.168.176.0/24
	authby=secret
        auto=add
Code: 
[COLOR="#FF0000"]@meindyndns.selfhost.bz 84.200.111.222[/COLOR]: PSK [COLOR="#FF0000"]"[/COLOR]geheim[COLOR="#FF0000"]"[/COLOR]
Zum Vergrößern anklicken....
HTH ...
 
PsychoMantis schrieb:
Sieht vielleicht jemand einen Fehler oder gibt es Ideen, was ich noch als Parameter probieren kann?
Zum Vergrößern anklicken....
Es gibt bei IPSec mehrere Modi (Beispiel-Konfigurationen dafür findest Du hier). Da die Anleitung bei layer9 auch schon etwas älter ist und sich im VPN der Box seit 04.80 einiges getan hat, würde ich auch eher für "Verstehen" anstelle von "Probieren" plädieren.

An Deiner Konfiguration fallen mir zwei Punkte auf:

1. Du nagelst den vServer beim KeyExchange auf das "alte" IKEv1-Verfahren fest, das ist aber beseitigt, wenn Du wusels Ratschläge befolgst. Ob der 'avmike' noch v1 kann, weiß ich nicht. Da - je nach IKE-Version - auch die Phasen beim Aufbau einer IPSec-Verbindung etwas anders ablaufen, wäre das in meinen Augen eine mögliche Ursache.

2. Dein vServer wird als "Host" für die Fritz!Box konfiguriert. Das ist zwar nachvollziehbar (er hat sicherlich nur die eine Adresse), ob das aber vom AVM-VPN auch richtig interpretiert wird (s.o. zu den Modi), weiß ich nicht. Theoretisch dürfte aber auch nichts dagegen sprechen, wenn Du auf der Seite des vServers einfach ein /28-Netz (oder was auch immer, nur keinen "Host", also /32) konfigurierst (bzw. das in der IPSec-Konfiguration auch nur behauptest).

Wie sich in der AVM-VPN-Konfiguration die Einstellungen für die verschiedenen "Betriebsarten" unterscheiden, kannst Du ja einfach mit dem Einrichtungsassistenten der Box ausprobieren für die 3 "Anwendungsszenarien", die dort angeboten werden - wobei der erste Punkt (Host<->LAN mit XAuth) eigentlich nicht interessant ist in Deinem Fall.

Sowie eine der beiden Seiten sich in einem anderen Modus wähnt (hier meine ich Tunnel- vs. Transport-Mode), werden die beiden Seiten nach dem Einrichten der SAs nicht "warm", da in beiden Modi ein unterschiedlicher Aufbau der Netzwerkpakete zur Anwendung gelangt und sie so gegenseitig nur fehlerhafte Pakete erkennen.

Was auch immer Du jetzt noch probieren solltest ... auf der Fritz!Box-Seite ist die Datei /var/tmp/avmike.log ein extrem hilfreiches Protokoll. Und wenn ich es richtig sehe, ist der vServer ja wirklich der Meinung, im zweiten Anlauf um 16:56:35 eine gültige SA eingerichtet zu haben (jedenfalls hält er die auch 12 Minuten später noch für gültig, was eigentlich ein Invalidieren und den Neuaufbau seitens der Fritz!Box in diesen 12 Minuten auch ausschließt). Da wäre dann natürlich die Ansicht des 'avmike' zu diesem Punkt auch interessant. Wenn der das nämlich anders sieht und seinerseits ständige Anforderungen zum Neuaufbau der Verbindung sendet, die aber vom vServer ignoriert werden, weil der nur noch verschlüsselt mit der Box kommunizieren will (er hat ja seiner Meinung nach eine funktionierende Verbindung), wäre das ein Ansatz für die Fehlersuche.

Dem Gefühl nach würde ich sagen, daß da die Phase 2 (das Einrichten der "logischen" Netzwerkverbindung) nicht richtig zum Ende gelangt. Solange man aber - wie ich - keine Ahnung hat, was diese ganzen Unterwelt-Gestalten da im Normalfall protokollieren müßten, ist das schwer zu belegen.

Die gesamte strongSwan-Dokumentation ist mir ehrlich gesagt zu umfangreich und auch etwas zu unübersichtlich ... daher weiß ich nicht einmal genau, wer bei strongSwan wofür zuständig ist (ich vermute mal, charon ist der eigentlich IKE-Daemon und pluto "bloß" der Wasserträger, der die Konfigurationen verwaltet). Da müßte dann ja noch jemand für das Einrichten der IPSec-Policies zuständig sein ... oder arbeitet strongSwan da komplett anders ? Was wird eigentlich bei 'ip xfrm policy show' angezeigt, wenn der vServer die Verbindung für "aktiv" hält ?

Schon die Tatsache, daß die bei layer9 für das Debugging verwendete plutodebug-Option "deprecated" ist (daraus geht für mich noch nicht eindeutig hervor, ob sie trotzdem wirksam wird oder nicht), läßt mich etwas an der Aktualität einiger alter HowTos zweifeln ... und wie man ohne entsprechende Protokolle irgendwelche Fehler finden will, leuchtet mir ohnehin nicht ein.
 
PeterPawn schrieb:
Was wird eigentlich bei 'ip xfrm policy show' angezeigt, wenn der vServer die Verbindung für "aktiv" hält ?.
Zum Vergrößern anklicken....

Code: 
# ip xfrm policy show | sed -e 's/192.xxx.xxx/192.0.2/g' -e 's/193.xxx.xxx/198.51.100/g'
src 192.168.176.0/24 dst 192.0.2.0/27 
        dir in priority 2248 
        tmpl src 84.128.172.65 dst 198.51.100.231
                proto comp reqid 16446 mode tunnel
                level use 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16445 mode transport
src 192.168.176.0/24 dst 192.0.2.0/27 
        dir fwd priority 2248 
        tmpl src 84.128.172.65 dst 198.51.100.231
                proto comp reqid 16446 mode tunnel
                level use 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16445 mode transport
src 192.0.2.0/27 dst 192.168.176.0/24 
        dir out priority 2248 
        tmpl src 198.51.100.231 dst 84.128.172.65
                proto comp reqid 16446 mode tunnel
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16445 mode transport
FTR: Ich route ein /27 des Servers und ein RFC1918/24 der FB. Da die (für dies IPSec-Setup verwendete) IP des Servers nicht Teil des VPNs ist, muß ich zum Verbindungcheck die Verbinding aus 192.0.2.0/27 aufbauen, bzw. von hinter der Fritz!Box eine solche ansprechen, sonst geht's nicht über den IPSec- (sondern den OpenVPN-) Tunnel.
 
Bei mir zeigt "ip xfrm policy show" einfach nur leere Zeile an.
/var/tmp/ike.log sieht so aus:
Code: 
2014-06-29 00:35:08 avmike:< add(appl=dsld,cname=VPN zum V-Server,localip=77.191.9.6, remoteip=84.200.111.222, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/no-pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x40001 tunnel no_xauth no_cfgmode no_nat_t no_certsrv_server_auth)
2014-06-29 00:35:08 avmike:new neighbour VPN zum V-Server: 
2014-06-29 00:35:08 avmike:mainmode VPN zum V-Server: selected lifetime: 3600 sec(no notify)
2014-06-29 00:35:08 avmike:VPN zum V-Server remote peer supported XAUTH
2014-06-29 00:35:08 avmike:VPN zum V-Server remote peer supported DPD
2014-06-29 00:35:09 avmike:mainmode VPN zum V-Server: add SA 1
2014-06-29 00:35:09 avmike:VPN zum V-Server: Phase 1 ready
2014-06-29 00:35:09 avmike:VPN zum V-Server: start waiting connections
2014-06-29 00:35:09 avmike:VPN zum V-Server: Phase 2 starting (start waiting)
2014-06-29 00:35:09 avmike:< cb_sa_create_failed(name=VPN zum V-Server,reason=IKE-Error 0x2026)
2014-06-29 00:35:10 avmike:mainmode VPN zum V-Server: del SA 1
2014-06-29 00:35:30 avmike:< add(appl=dsld,cname=VPN zum V-Server,localip=77.191.40.2, remoteip=84.200.111.222, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/no-pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x40001 tunnel no_xauth no_cfgmode no_nat_t no_certsrv_server_auth)
2014-06-29 00:35:30 avmike:new neighbour VPN zum V-Server: 
2014-06-29 00:35:32 avmike:mainmode VPN zum V-Server: selected lifetime: 3600 sec(no notify)
2014-06-29 00:35:32 avmike:VPN zum V-Server remote peer supported XAUTH
2014-06-29 00:35:32 avmike:VPN zum V-Server remote peer supported DPD
2014-06-29 00:35:32 avmike:mainmode VPN zum V-Server: add SA 1
2014-06-29 00:35:32 avmike:VPN zum V-Server: Phase 1 ready
2014-06-29 00:35:32 avmike:VPN zum V-Server: start waiting connections
2014-06-29 00:35:32 avmike:VPN zum V-Server: Phase 2 starting (start waiting)
2014-06-29 00:35:33 avmike:< cb_sa_create_failed(name=VPN zum V-Server,reason=IKE-Error 0x2026)

Ob ich keyexchange=ikev1 in die ipsec.conf eintrage oder auskommentiere, spielt keine Rolle. Habe mich hier und da nun reichlich eingelesen.
Fritzbox kann xauth und xauth geht nur mit ikev1, also ist meine Schlussfolgerung, dass der avmike sehr wohl ikev1 (und vermutlich kein ikev2) kann.
Trage ich in die ipsec.conf keyexchange=ikev2 ein, kommt keine Verbindung zustande.
Wenn ich das alles richtig verstanden habe, gab es vor strongswan Version 5 noch einen pluto und einen charon. Pluto war für ikev1 zuständig und charon für ikev2.
Mit Version > 5.0 wurde das abgeschafft und charon macht nun beides.
Habe auch versucht manuell strongswan 4.3 zu installieren, aber ipsec statusall liefert da nur leere Zeile.
 
Code: 
2014-06-29 00:35:09 avmike:< cb_sa_create_failed(name=VPN zum V-Server,reason=IKE-Error 0x2026)
2014-06-29 00:35:33 avmike:< cb_sa_create_failed(name=VPN zum V-Server,reason=IKE-Error 0x2026)
Zum Vergrößern anklicken....

LMGTFY ;)
PCMor schrieb:
[IKE-Error 0x2026 "no proposal chosen"]

Deutet darauf hin, dass die beiden sich in der IKE-Phase (Austausch des PSK) nicht einig sind, mit welcher Verschlüsselung der Key-Exchange laufen soll.
Zum Vergrößern anklicken....

Hast Du mal auf aes128 geändert (Deine Config hat aes256)?
 
wusel-09 schrieb:
Hast Du mal auf aes128 geändert (Deine Config hat aes256)?
Zum Vergrößern anklicken....
Welche Proposals sich bei der Fritz!Box hinter der Auswahl (phase1ss/phase2ss im jeweiligen vpn.cfg-Abschnitt für eine VPN-Verbindung) verbergen, kann man in der Datei /etc/default/avm/ipsec.cfg nachlesen, getrennt nach Phase1 (ike_strategien) und Phase2 (ipsec_strategien).

Die Fritz!Box beherrscht auch AES256-CBC, mit und ohne AH, auch mit PFS bei Bedarf.
Solange die Bandbreite nicht wirklich ein Problem ist (wie z.B. bei echten "UMTS"-Verbindungen), würde ich auf einem Proposal ohne Kompression bestehen, da es heutzutage nur noch wenige Daten gibt (und wenn, dann sind diese i.d.R. ohnehin eher klein und wenig), die nicht bereits irgendwie "vorkomprimiert" sind. Da dafür dann auch jeweils eine zusätzliche Transformation (s. xfrm-Anzeige von Dir weiter oben) notwendig wird, begrenzt man sich damit u.U. den Durchsatz mehr, als daß es ihn steigert.

Damit die Daten in einer IPSec-Verbindung auch wirklich verschlüsselt werden, richtet der IKE-Daemon an zwei Stellen "Umleitungen" für bestimmte Pakete ein. Es muß ja zuerst einmal selektiert werden, welcher Verkehr überhaupt verschlüsselt werden soll (ip xfrm policy) und dann noch wie dieser Verkehr verschlüsselt werden soll (ip xfrm state show). Solange der IKE-Daemon das nicht beides eingerichtet hat, verschlüsselt das System die Daten auch nicht.

Ausgehend von den anderen Meldungen im Logfile von Psychomantis würde ich eher sagen, Phase 1 ist abgeschlossen (da verständigen sich die Partner ja erst einmal, ob sie sich überhaupt gegenseitig kennen und so überhaupt eine Verbindung aufbauen wollen).
Code: 
2014-06-29 00:35:32 avmike:mainmode VPN zum V-Server: selected lifetime: 3600 sec(no notify)
2014-06-29 00:35:32 avmike:VPN zum V-Server remote peer supported XAUTH
2014-06-29 00:35:32 avmike:VPN zum V-Server remote peer supported DPD
2014-06-29 00:35:32 avmike:mainmode VPN zum V-Server: add SA 1
2014-06-29 00:35:32 avmike:VPN zum V-Server: Phase 1 ready
Schon ab Zeile 1 oben findet ein Key-Exchange statt, die "lifetime" ist i.d.R. der kleinere der - von beiden Seiten vorgeschlagenen - Werte. Auch die Aussage "remote peer supported" basiert auf den konkreten "Capabilities" der Gegenstelle. Es wird in Phase1 eine Einigung erzielt und eine "Security Association" (SA) eingerichtet (vorletzte Zeile). Anschließend ist Phase1 abgeschlossen.

Das Problem der fehlenden Einigung auf ein gemeinsames Verfahren dürfte sich hier also auf Phase2 beziehen (Phase 2 starting). In Phase2 werden dann die "Netzwerkeinstellungen" auf beiden Seiten abgeglichen und daraus die schon erwähnten Transformationen abgeleitet.

PsychoMantis schrieb:
Fritzbox kann xauth und xauth geht nur mit ikev1, also ist meine Schlussfolgerung, dass der avmike sehr wohl ikev1 (und vermutlich kein ikev2) kann.
Trage ich in die ipsec.conf keyexchange=ikev2 ein, kommt keine Verbindung zustande.
Zum Vergrößern anklicken....
Das, was man im IKE-Protokoll landläufig unter "XAuth" und "IKE-Config-Mode" versteht (zwei ursprünglich proprietäre Erweiterungen von Cisco zur Authentifizierung von Benutzern innerhalb einer Gruppe (von Leuten, die den PSK des Gateways kennen) und zur Konfiguration von Netzwerkeinstellungen (so eine Art DHCP für IPSec-Verbindungen)), ist bei IKEv2 direkt als Anforderung berücksichtigt worden.
Aus der Tatsache, daß bei IKEv2 keine Verbindung zustande kommt, zu schließen, daß die Box nur IKEv1 beherrscht (ich weiß es nicht besser, werde deshalb aber kein IKEv2-capable IPSec bei mir installieren, um das zu testen), finde ich persönlich etwas kühn ... wenn ich es richtig verstanden habe, kommt bei IKEv1 ja auch keine Verbindung zustande und der Logik folgend, beherrscht die Box dann auch kein IKEv1. :)

PsychoMantis schrieb:
Habe auch versucht manuell strongswan 4.3 zu installieren, aber ipsec statusall liefert da nur leere Zeile.
Zum Vergrößern anklicken....
Wie muß man sich das denn jetzt vorstellen ? Hast Du strongSwan 5 (daß es da gewaltige Unterschiede gibt, habe sogar ich begriffen) deinstalliert ? Beide IKE-Implementierungen wirst Du schwerlich parallel betreiben können, da nur eine gleichzeitig die UDP-Ports 500 und/oder 4500 "belegen" kann.

Edit:
Was man anhand des avmike-Protokolls noch sieht ... der vServer annonciert keine NAT-T-Fähigkeit. Wenn ich es persönlich einrichten müßte, würde ich immer (den minimalen Volumen-Overhead ignorierend) NAT-Traversal bevorzugen. Während beim "normalen" IPSec mit UDP (IP-Protokoll 17), Port 500 als auch ESP (IP-Protokoll 50) zwei "unterschiedliche" Verbindungen zusammen funktionieren müssen, reicht es bei NAT-Traversal aus, wenn auf UDP Port 4500 eine Verbindung zustande kommen kann. Falls da wirklich noch ein NAT-Gateway im Verbindungsweg ist, geht es ohne NAT-T auch nur mit erheblichen Einschränkungen überhaupt (ESP kennt keine Ports (für mehrere Verbindungen), deshalb kann nur eine einzelne Verbindung genutzt werden).
 
Zuletzt bearbeitet:
Ich habe mal versucht mit dieser ipsec.conf eine Verbindung aufzubauen
Code: 
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	charondebug=ike

conn berlin
	keyexchange=ikev1
	left=84.200.111.222
	leftsubnet=192.168.1.0/24
	ike=aes-camellia              #hier             habe ich auch alles andere versucht
	esp=aes-camellia-null                #und da 
        right=meindyndns.selfhost.bz
	[email protected]
	rightsubnet=192.168.176.0/24
	authby=psk
        auto=route
Code: 
root@psychomantis:~# ipsec start
Starting strongSwan 5.1.2 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!
root@psychomantis:~# ipsec up berlin
initiating Main Mode IKE_SA berlin[1] to 188.105.24.8
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 84.200.111.222[500] to 188.105.24.8[500] (180 bytes)
received packet: from 188.105.24.8[500] to 84.200.111.222[500] (148 bytes)
parsed ID_PROT response 0 [ SA N((24576)) V V ]
received XAuth vendor ID
received DPD vendor ID
generating ID_PROT request 0 [ KE No ]
sending packet: from 84.200.111.222[500] to 188.105.24.8[500] (196 bytes)
received packet: from 188.105.24.8[500] to 84.200.111.222[500] (180 bytes)
parsed ID_PROT response 0 [ KE No ]
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 84.200.111.222[500] to 188.105.24.8[500] (68 bytes)
received packet: from 188.105.24.8[500] to 84.200.111.222[500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA berlin[1] established between 84.200.111.222[84.200.111.222]...188.105.24.8[meindyndns.selfhost.bz]
scheduling reauthentication in 9733s
maximum IKE_SA lifetime 10273s
allocating SPI failed: Invalid argument (22)
unable to get SPI for reqid {1}
allocating SPI from kernel failed
establishing connection 'berlin' failed
root@psychomantis:~#

Die Ausgabe von strongswan sieht für mich auch so aus, dass Phase 1 abgeschlossen ist, aber Phase 2 dann abbricht.
Nur warum verstehe ich nicht. Es fehlt was im Kernel und ich kann nichts tun, weil es nur ein V-Server ist auf OpenVZ?
 
PsychoMantis schrieb:
Nur warum verstehe ich nicht. Es fehlt was im Kernel und ich kann nichts tun, weil es nur ein V-Server ist auf OpenVZ?
Zum Vergrößern anklicken....
Denkbar, aber nicht zwingend ... https://openvz.org/IPsec

Da es sich bei den Kernel-Modulen um allgemeine Netzwerk-Bestandteile handelt, ist der direkte Bezug auf "libreswan" auch nicht zwingend ... die Module gehören zum System-Stack.

Ob Dein Container "net_admin" darf, mußt Du halt erfragen ...

Ansonsten ist "allocating SPI failed: Invalid argument (22)" etwas vage seitens strongSwan. Da das eine zweiseitige Verbindung ist und das Problem auch auf beiden Seiten liegen könnte ("invalid argument" kann ja auch ein falsch von der Box übermittelter Parameter sein, ich weiß es nicht), wäre jeweils ein Protokoll von beiden Seiten, das sich dann auch mal auf dieselbe Verbindung bezieht, vielleicht hilfreich.
 
Nachdem mein Beitrag von 11:02 Uhr (o.s.ä.) nach dem Bearbeiten um 11:47 Uhr bei mir doppelt angezeigt wurde (eben 1x 11:02 Uhr und einmal 11:47 Uhr, letzterer dann schon auf Seite 3), habe ich den von 11:02 Uhr löschen wollen und nun sind wundersamerweise beide weg.

Die beiden Mitstreiter hier sollten diesen per E-Mail-Benachrichtigung ggf. erhalten haben ... ich schreibe ihn nicht noch einmal und sein "Verschwinden" ist nur ein Unfall, kein absichtliches Zurückziehen.

Edit: Alles zurück auf Anfang, Beitrag wieder da ... Problem geklärt.
Ich lasse das hier der Vollständigkeit halber trotzdem stehen, ansonsten bitte administrativ löschen. Danke.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 829 (Mitglieder: 52, Gäste: 777)

Neueste Beiträge

Statistik des Forums

Themen
246,167
Beiträge
2,247,362
Mitglieder
373,712
Neuestes Mitglied
Bigtorsti
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück