VPN, 7390, 7270, 7170, StrongSwan

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
smart-gp

smart-gp

Mitglied
Mitglied seit
31 Mai 2006
Beiträge
318
Punkte für Reaktionen
1
Punkte
18
Ich habe einen VPN-Verbund von 4 Fritzboxen. Zusätzlich Zugriff von außen vom Notebook über Fritz!Fernzugang und auch mit nem Nokia E51.

Das klappt soweit alles sehr gut und zuverlässig.

Jetzt möchte ich noch einen Linux-Rootserver mit StrongSwan in den IPSec-Verbund mit aufnehmen. Hier hab' ich jetzt schon einige Zeit mit tüfteln, googeln und der Forensuche verbracht, komme im Moment aber nicht mehr weiter.

Was inzwischen klappt ist, wenn ich den Tunnel von einer der Boxen zum Strongswan hin aufbaue. Was nicht klappt ist, den Tunnel von der StrongSwan-Seite her aufzubauen.

Auszug aus dem relevanten Teil einer vpn.cfg einer der Boxen:

Code: 
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "host.domain.de";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 91.143.xx.yy;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "dyn.domain.de";
                }
                remoteid {
                        ipaddr = 91.143.xx.yy;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.69.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";
        }
Die ipsec.conf auf dem Rootserver sieht so aus:

Code: 
config setup
        # plutodebug=all
        # crlcheckinterval=600
        # strictcrlpolicy=yes
        # cachecrls=yes
        # nat_traversal=yes
        charonstart=no
        # plutostart=no

conn wb
        left=91.143.xx.yy
        leftsubnet=192.168.96.1/32
        #
        ike=aes256-sha-modp1024
        esp=aes256-sha1
        pfs=yes
        #
        right=dyn.domain.de
        [email protected]
        rightsubnet=192.168.69.0/24
        #
        ikelifetime=86400
        keylife=3600
        keyexchange=ike
        #
        authby=secret
        auto=add
Hat jemand einen Tipp woran es liegen könnte, daß sich der Tunnel nur einseitig aufbauen läßt? Wenn der Tunnel steht, funktioniert er auch.

Einzelheiten zu Firmwareständen, Softwareversionen siehe Sig.
 
smart-gp schrieb:
Code: 
(...)
        ikelifetime=86400
        keylife=3600
(...)
Zum Vergrößern anklicken....

Hi,

mir fällt zunächst mal die ikelifetime auf: die ist in den Fritz-Boxen genauso fest verdrahtet, wie die IPSec-Lifetime, in beiden Fällen nämlich 3600s - und nicht änderbar (zumindest, soweit ich weiß).
 
Danke für den Hinweis.

Hab' ich geändert, aber das Verhalten ist unverändert.
 
Hallo nochmal,

in der Annahme, dass sich StrongSWAN nicht anders verhält als OpenSWAN (welches die Astaro-Firewall nutzt und mit dem ich einige S2S-VPNs laufen habe, auch mit meiner FritzBox), würde ich es mit den folgenden IKE- und ESP-Proposals versuchen:

Code: 
[FONT="Courier New"](...)
phase1ss = "alt/all/all";      [COLOR="Green"]/*alt = alternative DH-Group[/COLOR]
phase2ss = "esp-all-all/[COLOR="#008000"]ah-all[/COLOR]/comp-all/pfs";
(...)[/FONT]

Code: 
[FONT="Courier New"](...)
auth=ah                        [COLOR="#008000"]/*Authentication Header nutzen...[/COLOR]
ike=aes256-sha-modp1024!       [COLOR="#008000"]/*! = strict policy = nur diese Cipher-Kombi[/COLOR]
esp=aes256-sha1!
pfs=yes
pfsgroup=modp1024              [COLOR="#008000"]/*alternative DH-Group für Phase 2[/COLOR]
dpdaction=hold                 [COLOR="#008000"]/*aktiviert [URL="http://www.strongswan.org/docs/readme4.htm#section_14.3"]Dead Peer Detection[/URL]
                               (in der vpn.cfg: always_renew = yes;)[/COLOR]
dpddelay=60
dpdtimeout=500
(...)[/FONT]

Ich habe jedenfalls keine andere AES-Kombi als diese zum laufen bekommen...

Aber noch 'ne andere Frage: wieso soll nur der einzelne Peer 192.168.96.1 in den Tunnel?
 
Dein Konfigvorschlag bringt das gleiche Ergebnis.

Nur einseitiger Tunnelaufbau von den Boxen aus.

Hab' auch schon das Astaro-Beispiel aus dem AVM-Portal probiert, da komme ich nur bis Phase 1.

Warum nur ein einzelner Peer: Es ist ein Rootserver, hinter dem weiter nichts hängt.
 
Was sagen denn die StrongSWAN-Logs, wenn du sie aktivierst und einen Tunnel zu einer Box aufbauen willst?

Zwei Ideen noch:

1. bei meiner Verbindung zu einer Astaro/OpenSWAN müssen die jeweiligen VPN-IDs der IKE-Phase vom selben Typ sein:

Code: 
(...)                
localid {
     ipaddr = 169.254.1.1;
     }
remoteid {
     ipaddr = 91.143.xx.yy;
     }
(...)

...und...
Code: 
(...)
[email protected];    [COLOR="Red"][I]...wobei ich hier nicht weiß, ob der Klammeraffe vor die IP gehört...[/I][/COLOR]
(...)

Linklocal-Address, weil die sich ja nicht ändert ;)

Und das bringt mich zu Punkt 2, welchen ich da eher in der Pflicht sehe:
sieht dein Schwan bzw. sein IPSec denn auch die korrekte DynDNS-IP, wenn er sich zu verbinden versucht?

Daher auch die Frage nach den Logs... schau mal hier .°click°.
 
Gut, daß Du nach den Logs fragst, Martin.

Erst jetzt ist mir aufgefallen, daß die Fehlermeldung unterschiedlich ist, ob ich meine Konfiguration aus #1 verwende oder Deine aus #4.

Phase 1 wird nach meinem Verständnis jeweils aufgebaut. Somit können eigentlich weder 1. noch 2. in frage kommen.

Die Problematik bzgl. 2. bei dyndns ist bekannt. Ich starte IPSEC aber nach jeder Konfigurationsänderung neu.

Ich meine auch schon was über Probleme bei AH gelesen zu haben, finde das aber im Moment nicht mehr.

So, aber nun zu den Logs. Hier das mit Deiner Konfig nach #4:

Code: 
Dec  8 15:53:21 jen1 pluto[17375]: "heu" #1: initiating Main Mode
Dec  8 15:53:21 jen1 pluto[17375]: "heu" #1: received Vendor ID payload [XAUTH]
Dec  8 15:53:21 jen1 pluto[17375]: "heu" #1: received Vendor ID payload [Dead Peer Detection]
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: Peer ID is ID_FQDN: '@aaaa.mine.nu'
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: ISAKMP SA established
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #2: initiating Quick Mode PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+UP {using isakmp#1}
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:53:32 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:53:52 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:54:32 jen1 pluto[17375]: "heu" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Dec  8 15:54:32 jen1 pluto[17375]: "heu" #2: starting keying attempt 2 of at most 3, but releasing whack
Dec  8 15:54:32 jen1 pluto[17375]: "heu" #3: initiating Quick Mode PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+UP to replace #2 {using isakmp#1}
Dec  8 15:54:32 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:54:42 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:55:02 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:55:42 jen1 pluto[17375]: "heu" #3: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Dec  8 15:55:42 jen1 pluto[17375]: "heu" #3: starting keying attempt 3 of at most 3
Dec  8 15:55:42 jen1 pluto[17375]: "heu" #4: initiating Quick Mode PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+UP to replace #3 {using isakmp#1}
Dec  8 15:55:42 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:55:52 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:56:12 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec  8 15:56:52 jen1 pluto[17375]: "heu" #4: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Und hier eine Verbindung mit meiner Konfig nach #1:

Code: 
Dec  8 16:09:26 jen1 pluto[17375]: "wb" #5: initiating Main Mode
Dec  8 16:09:26 jen1 pluto[17375]: "wb" #5: received Vendor ID payload [XAUTH]
Dec  8 16:09:26 jen1 pluto[17375]: "wb" #5: received Vendor ID payload [Dead Peer Detection]
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: Peer ID is ID_FQDN: '@bbbbb.mine.nu'
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: ISAKMP SA established
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #6: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#5}
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Dec  8 16:09:37 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Dec  8 16:09:57 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Dec  8 16:10:37 jen1 pluto[17375]: "wb" #6: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Dec  8 16:10:37 jen1 pluto[17375]: "wb" #6: starting keying attempt 2 of at most 3, but releasing whack
Dec  8 16:10:37 jen1 pluto[17375]: "wb" #7: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #6 {using isakmp#5}
Dec  8 16:10:37 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Dec  8 16:10:47 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Dec  8 16:11:07 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
Die Fritze zeigen dabei in der Übersicht jeweils den Zustand "Verbindung wird aufgebaut". Im Log steht bei den Boxen gar nichts.

So wie ich das verstehe, wird der Verbindungsaufbau aber jeweils von der Fritzbox abgelehnt. Richtig?
 
smart-gp schrieb:
Code: 
(...)
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: Peer ID is ID_FQDN: '@aaaa.mine.nu'
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: ISAKMP SA established
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #2: initiating Quick Mode PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+UP {using isakmp#1}
Dec  8 15:53:22 jen1 pluto[17375]: "heu" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
(...)
Dec  8 15:54:32 jen1 pluto[17375]: "heu" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Zum Vergrößern anklicken....

Hier sieht's erstmal so aus, als hätte der IKEv1 (pluto) die Verbindungsanfrage anhand der übergebenen ID akzeptiert und versucht nun mit der eingestellten Verschlüsselung den Keyexchange zu fahren, um danach die Phase2 einzuläuten zu können.
Klappt aber nicht, weil sich die Peers nicht wegen der zu verwendenden Crypto-Policy einig werden (NO_PROPOSAL_CHOSEN)...
Also dürfte hier erstmal noch etwas mit den eingestellten Verschlüsselungen nicht stimmen.


smart-gp schrieb:
Code: 
(...)
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: ISAKMP SA established
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #6: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#5}
Dec  8 16:09:27 jen1 pluto[17375]: "wb" #5: ignoring informational payload, type INVALID_ID_INFORMATION
(...)
Dec  8 16:10:37 jen1 pluto[17375]: "wb" #6: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Zum Vergrößern anklicken....

Auch hier wird die Verbindungsanfrage zunächst akzeptiert, allerdings schafft er die Phase 1 nicht, weil pluto schon die VPN-ID nicht akzeptiert (INVALID_ID_INFORMATION), es kommt also noch nicht einmal zum Versuch, die Crypto-Policy auszutauschen.

smart-gp schrieb:
So wie ich das verstehe, wird der Verbindungsaufbau aber jeweils von der Fritzbox abgelehnt.
Zum Vergrößern anklicken....

Naja, im Grunde ist es "einfach" so, dass sich Fritz und der Schwan einfach nicht darüber einig sind, wie sie ihren Tunnel aufbauen sollen:
  • beide müssen die VPN-ID zum Zeitpunkt des Verbindungsaufbaus kennen und akzeptieren, wobei die ID hier eher als Username zu verstehen ist und keinen echten Bezug zur aktuellen WAN-IP haben muss
  • beide müssen sich mit derselben Crypto-Policy melden; bei mir klappt's mit AES und der Fritte ausschließlich so
    • IKE: AES256, SHA1, IKE-DH: DH-Group 2 (MODP 1024), Lifetime 3600 s
    • IPSec: AES256, SHA1, IPSec-PFS: DH-Group 2 (MODP 1024), Lifetime 3600 s
    • zusätzlich Authentication Header (AH) für Phase 2

Bin gespannt auf deine nächsten Versuche :fecht:
 
...hm...

Ich glaube, ich muss mich korrigieren: nach etwas Lektüre scheint mir die Reihenfolge genau andersrum zu sein:
  • erst werden die Crypto-Policies angeboten und ausgewählt (PROPOSALs)
  • erst dann wird die ID gecheckt (mittels VPN-ID und PSK)

Also scheint es mir eher so, dass du mit deiner Variante weiter "spielen" solltest, und zwar primär mit der VPN-ID (FQDN oder IP?)...

Und wenn möglich: mehr Logs ;)
 
Und?

Konntest du das Problem lösen?
Ich stehe vor dem gleichen Problem, wie sieht deine Lösung aus?
Danke & Gruss
 
smart-gp schrieb:
Ich bin nach dieser Anleitung vorgegangen: http://layer9.wordpress.com/2010/07/28/ipsec-vpn-mit-strongswan-und-fritzbox-fon-wlan-7270-v3/
Zum Vergrößern anklicken....

Hallo SmartGP
Layer9 habe ich auch als Basis benutzt. Einen Tunnel zu meinem ubuntu strongSwan(5.0.0) habe ich bereits. Fritzbox meldet GRÜN. Aber wie leite ich """alles""" aus 192.168.177.0 nach 192.168.179.0 ?

Die Fritzbox leitet nur Traffic für einzelne Rechner im 179er-netz durch den Tunnel. Wie bringe ich ihr bei, dass der gesamte Traffic durch den Tunnel soll? (ich möchte den Internetzugang im entfernten Netz nutzen)

Danke & Gruss
 
Mußt mal suchen. Es gibt hier eine Anleitung dazu wie die .cfg-Datei dafür zu modifizieren ist.

Die aktuellen Version von "Fritzfernzugang einrichten" bietet das als Option für einzelne Benutzer an. Auch da kannst Du mal in die .cfg schauen, was da dann an zusätzlichen Einträgen drin ist.

PS: Es wird hier nicht gern gesehen, wenn Du Dein Problem auf x Threads verteilst und überall die gleichen Fragen stellst.
 
Hat das jemand auf einem Vserver ausprobiert?
Was ich bisher hinbekommen habe ist es, dass der vserver mit vpnc sich als VPN-Client bei der Fritzbox einloggt.
Ich würde es gerne umgekehrt haben: die Fritzbox soll sich beim vserver einwählen.
Ich habe jetzt einfach die ipsec.conf aus dem ersten Post kopiert und leicht editiert, aber das Ergebnis sieht schlecht aus:
Code: 
root@asterisk:~# /etc/init.d/ipsec start
Starting strongSwan 4.5.2 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!

Hat da vielleicht jemand eine Idee?
 
Google liefert dazu:

The above warnings are fine, ignore them.

Ich habe 2 Vserver laufen, die untereinander und mit 3 Fritzboxen per VPN verbunden sind.

Auszug aus meiner ipsec.conf:

Code: 
config setup
        # plutodebug=all
        # crlcheckinterval=600
        # strictcrlpolicy=yes
        # cachecrls=yes
        # nat_traversal=yes
        # charonstart=no
        # plutostart=no
        # plutodebug=control
        plutodebug=none
        crlcheckinterval=180
        strictcrlpolicy=no
        charonstart=no

# Add connections here.

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1

conn fra1-es
        left=158.255.xxx.yyy
        leftsubnet=192.168.99.1/32
        #
        ike=aes128-sha-modp1024
        esp=aes128-sha1
        #
        right=%zzzz.homedns.org
        [email protected]
        rightsubnet=192.168.67.0/24
        #
        ikelifetime=4h
        keylife=1h
        #
        authby=secret
        auto=start
 
Danke für diese Info.
Hast du noch ein paar weiterführende Links, wo man sich belesen kann? Ich verstehe bisher noch nicht die Sache mit dem right/rightsubnet und left/leftsubnet? Und außerdem müsste da doch irgendwo noch das Passwort (key) hin.
 
Schau Dir mal den Link in #11 an. Sonst einfach mal nach ipsec(.conf) googeln.

left = lokale externe IP
leftsubnet = lokales VPN-Subnetz
right = externe IP der Gegenstelle
rightsubnet = VPN-Subnetz der Gegenstelle

Passwort kommt in die ipsec.secrets, z.B. so:

Code: 
#
# ipsec.secrets
#
# This file holds the RSA private keys or the PSK preshared secrets for
# the IKE/IPsec authentication. See the ipsec.secrets(5) manual page.
#
: PSK "mein preshared key"
 
OK. Eine Sache verstehe ich noch nicht: wenn ich ipsec-daemon starte, was soll danach außer der schon oben erwähnten Fehlermeldung passieren? Müsste da nicht ein tun0 oder so was unter ifconfig zu sehen sein? Zumindest war das bei openvpn so als ich den openvpn-server gestartet habe.
 
Nein, bei ipsec gibt es keine neuen Interfaces in ifconfig.

Schau halt mal in die Logfiles, versuche zu pingen, gib mal "ipsec statusall" oder "ipsec --help" help ein.

Bei konkreten Fragen müsstest Du auch mal deine ipsec.conf und Logauszüge zeigen.
 
So. Habe jetzt paar Stunden rumprobiert, komme aber nicht weiter.
Die Fritzbox 7390er sagt im Log nur: "VPN-Fehler: 84.200.77.111, IKE-Error 0x2027"
Hier meine ipsec.conf auf dem VServer:
Code: 
config setup

        plutodebug=none
        crlcheckinterval=180
        strictcrlpolicy=no
        charonstart=no

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1

conn fra1-es
        left=84.200.77.111
        leftsubnet=192.168.150.0/24
        #
        ike=aes128-sha-modp1024
        esp=aes128-sha1
        #
        right=%meinefbf.selfhost.tv
        [email protected]
        rightsubnet=192.168.178.0/24
        #
        ikelifetime=4h
        keylife=1h
        #
        authby=secret
        auto=start

Meine /etc/ipsec.secrets sieht so aus:
Code: 
: PSK 'Dh9tgxD8p9CPhQedKfiDoA93'

Und hier meine test.cfg, die ich in die fritzbox importiere.

Code: 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "84.200.77.111";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "84.200.77.111";
                localid {
                        fqdn = "meinefbf.selfhost.tv";
                }
                remoteid {
                        fqdn = "84.200.77.111";
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "Dh9tgxD8p9CPhQedKfiDoA93";
                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 = 192.168.150.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.150.0 255.255.255.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";
}


// EOF

ipsec lässt sich beenden, starten, zeigt aber unter statusall nix an:
Code: 
root@asterisk:~# ipsec stop
Stopping strongSwan IPsec...
root@asterisk:~# ipsec start
Starting strongSwan 4.5.2 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!
root@asterisk:~# ipsec statusall
root@asterisk:~#
Sieht vielleicht jemand einen Fehler oder gibt es sonstige Ideen, warum sich bei mir keine VPN-Verbindung aufbauen lässt?
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 849 (Mitglieder: 57, Gäste: 792)

Neueste Beiträge

Statistik des Forums

Themen
246,167
Beiträge
2,247,354
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