VPN-Verbindung mit PPTP u. ipsec (Modem hangup)

a017886 · 26 Jan. 2011

Hallo Fans,

ich komme mir vor, wie der Seemann, der sein Ziel ereicht hat, aber am Ziel untergeht. Ich möchte gerne meinen SuSE 11.2 client über eine VPN-Verbindung (PPTP-Protokoll) mit einem anderen Netz verbinden.
client --> DSL-Router --> <INTERNET> --> VPN-Router --> Klasse C Netzwerk
In der Windows-Welt funktioniert die ganze Sache mittels VPN-Wählverbindung problemlos (deshalb muss erstmal PPTP bleiben).
Software:
SuSE 11.2
pptp, pptpd
KVPNC

Der VPN-Router hat eine öffentliche IP und wird auch erreicht. Solange ich in KVPNC oder mit

Code:

route add -net 192.168.11.0 netmask 255.255.255.0 dev ppp0

keine Routen eintrage, kann ich auf dem VPN-Router im Zielnetz bleiben, solange ich will (komme dann natürlich nicht weiter in's Netz).
Sowie geroutet wird, schmeißt mich der VPN-Router 'raus (Modem hangup).

Protokoll (=Ausschnitt logfile) DRAYTEK VIGOR (ip-Adressen geändert):

Code:

1582011-01-19 17:30:44Jan  1 00:01:42VigorPPP Start (PPPoE)
1582011-01-19 17:30:45Jan  1 00:01:42VigorCHAP Login OK (PPPoE)
1582011-01-19 17:30:45Jan  1 00:01:42VigorIPCP Opening (PPPoE); Own IP Address : 111.222.33.444  Peer IP Address : 11.22.3.199; Primary DNS : 111.55.44.333  Secondary DNS : 111.55.44.334
1582011-01-19 17:57:17Jan  1 00:28:14VigorPPP Start (VPN-0)
1582011-01-19 17:57:20Jan  1 00:28:17VigorCHAP Login OK (VPN-0)
1582011-01-19 17:57:23Jan  1 00:28:20VigorIPCP Opening (VPN-0); Own IP Address : 192.168.11.254  Peer IP Address : 192.168.11.232
1582011-01-19 17:58:59Jan  1 00:29:56VigorPPP Closed : LCP Time-out (VPN-0)

192.168.11.254: das ist die interne ip des VPN-Routers
192.168.11.232: diese ip kriege ich via DNS vom VPN-Router
192.168.11.109: DSL-Router

route -n vor Verbindungsaufbau:

Code:

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.11.109  0.0.0.0         UG    0      0        0 eth0

route -n nach Verbindungsaufbau:

Code:

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.11.254  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
188.111.93.235  192.168.11.109  255.255.255.255 UGH   0      0        0 eth0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.88.109  0.0.0.0         UG    0      0        0 eth0

Dürfen die beiden zu verbindenden Netze im gleichen Subnetz sein (192.168.11.XXX)?

Hat irgendjemand eine Idee?
Danke! - Gruß Torsten

spoensche · 28 Jan. 2011

Code:

1582011-01-19 17:30:45Jan  1 00:01:42VigorIPCP Opening (PPPoE); Own IP Address : 111.222.33.444

Diese IP gibt es nicht, genau so wie es die IP

Code:

111.55.44.334

nicht gibt.

Nutzt du OpenVPN oder IPsec? Poste mal deine Konfiguration

a017886 · 30 Jan. 2011

... stimmt. Hatte ich aber geschrieben:

(ip-Adressen geändert)

Die Adressen "Primary DNS : 111.55.44.333 Secondary DNS : 111.55.44.334 (=195.50.140.114, 195.50.140.252)" sagen mir nichts, sind außerhalb meines Netzes.
Die (geänderte) Adresse "Own IP Address : 111.222.33.444" ist die öffentliche IP-Adresse meines VPN-Routers, die konnte ich hier nicht posten! Ist aber auch nicht Teil des Problems, da ich ja bereits auf den VPN-Router draufkomme.

Mit Konfiguration posten meinst Du wahrscheinlich dieses komische collectNWData script, was mir sagt, ich soll doch lieber knetworkmanager nehmen!?

Code:

collectNWData.sh V0.6.5.1-7a (Rev: 1.276, Build: 2010/12/12 13:05:44 UTC)
--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (1) Kabelgebundene Verbindung
--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient
--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...

!!! CND0290E: Keine Netzwerkkonfiguration für Interface eth0:lnxc gefunden
!!! CND0310W: Klassische Netzwerkkonfiguration mit ifup wurde entdeckt. Die Konfiguration mit knetworkmanager ist wesentlich einfacher

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailiertere Hinweise 
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei collectNWData.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL) 
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/SuSE-release
openSUSE 11.2 (i586)
VERSION = 11.2
===== uname -a ===================================================================================================
Linux winclnt103 2.6.31.14-0.6-desktop #1 SMP PREEMPT 2010-12-10 11:18:32 +0100 i686 i686 i386 GNU/Linux
===== lspci ======================================================================================================
00:19.0 Ethernet controller [0200]: Intel Corporation 82578DM Gigabit Network Connection [8086:10ef] (rev 05)
	Subsystem: Hewlett-Packard Company Device [103c:304b]
	Kernel driver in use: e1000e
--
0d:01.0 Network controller [0280]: AVM GmbH Fritz!PCI v2.0 ISDN [1244:0e00] (rev 02)
	Subsystem: AVM GmbH Fritz!PCI v2.0 ISDN [1244:0e00]
===== lsusb | grep -v "root hub" =================================================================================
Bus 001 Device 002: ID 8087:0020  
Bus 001 Device 003: ID 04a9:2213 Canon, Inc. CanoScan LiDE 50/LiDE 35/LiDE 40
Bus 001 Device 004: ID 04b8:0007 Seiko Epson Corp. Printer
Bus 002 Device 002: ID 8087:0020  
Bus 002 Device 003: ID 0bda:0181 Realtek Semiconductor Corp. 
===== hwinfo (filtered) ==========================================================================================
18: PCI 19.0: 0200 Ethernet controller
  Model: "Intel 82578DM Gigabit Network Connection"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x10ef "82578DM Gigabit Network Connection"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x304b 
  Driver: "e1000e"
  Driver Modules: "e1000e"
  Device File: eth0
  Link detected: yes
    Driver Status: e1000e is active
    Driver Activation Cmd: "modprobe e1000e"
===== lsmod (filtered) ===========================================================================================
| aead            | af_packet       | arc4            | e1000e          | ecb              |
| ip_gre          | ip_tables       | jbd2            | pcompress       | ppp_generic      |
| ppp_mppe        | sg              | sha1_generic    | slhc            | speedstep_lib    |
| sr_mod          | tpm             | tpm_bios        | tpm_infineon    | tun              |
| usblp           | wmi             |
===== ifconfig (filtered for eth|wlan|ra|ath|dsl) ================================================================
eth0      Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet Adresse:192.168.11.103  Bcast:192.168.11.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1910 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:10 
          RX bytes:1512766 (1.4 Mb)  TX bytes:308375 (301.1 Kb)
          Speicher:f3000000-f3020000 
eth0:lnxc Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet Adresse:192.168.87.170  Bcast:192.168.87.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Speicher:f3000000-f3020000 
===== cat /etc/sysconfig/network/ifcfg-[earwd]* | grep -v "=''" ==================================================
--- /etc/sysconfig/network/ifcfg-dsl0
BOOTPROTO='none'
DEVICE='eth0'
MODEM_IP='111.222.33.444'
NAME='DSL-Verbindung'
PPPMODE='pptp'
PROVIDER='provider1'
STARTMODE='manual'
USERCONTROL='yes'
--- /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
IPADDR='192.168.11.103/24'
NAME='82578DM Gigabit Network Connection'
STARTMODE='auto'
USERCONTROL='yes'
PREFIXLEN='24'
IPADDR_0='192.168.87.170/24'
LABEL_0='lnxclnt170'
===== dhcpcd-test ================================================================================================
eth0: No DHCP server detected info, eth0: hardware address = ##:##:##:##:##:#1
info, eth0: broadcasting for a lease
debug, eth0: sending DHCP_DISCOVER with xid 0x2860a9ea
debug, eth0: waiting for 3 seconds
info, eth0: exiting
eth0:lnxc: No DHCP server detected info, eth0:lnxc: hardware address = ##:##:##:##:##:#1
info, eth0:lnxc: broadcasting for a lease
debug, eth0:lnxc: sending DHCP_DISCOVER with xid 0x3840f67e
debug, eth0:lnxc: waiting for 3 seconds
info, eth0:lnxc: exiting
===== ping tests =================================================================================================
Ping of 195.135.220.3 OK
Ping of www.suse.de OK
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 192.168.11.109
nameserver 192.168.11.254
===== cat /etc/hosts =============================================================================================
127.0.0.1       localhost
...
...
...
127.0.0.2       winclnt103.WORKGROUP winclnt103
192.168.11.103  winclnt103 winclnt103
===== route -n | egrep "(eth|ath|ra|wlan|dsl)" ===================================================================
192.168.87.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         192.168.88.109  0.0.0.0         UG    0      0        0 eth0
===== egrep 'eth|ath|wlan|ra' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ==============
/etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="##:##:##:##:##:#1", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
==================================================================================================================
*** NWElizaStates V0.6.5.1-7a
IF:eth0 IM:1 IF:eth0:lnxc IM:1 DI:2 FALON:1 NIC:0 cNiC:1:0 NIC:0 cNiC:2:0 NI:0 cNI:0 PNG:0 DNS:0 MTU:1 NISS:0 IP6:0 KM:0 WLW:0 RTDT:SuSE

Wo dieses 87'er Subnetz noch steht ist mir rätselhaft, das war mal ein Versuch mit YAST/Netzwerkeinstellungen/Routing.

Zum Sicherheitsprotokoll:
Ist openvpn und ipsec Bestandteil von PPTP? Ich nutze (noch) MSCHAP und will mich Schritt für Schritt herantasten!

Gruß

drboe · 30 Jan. 2011

a017886 schrieb:
Dürfen die beiden zu verbindenden Netze im gleichen Subnetz sein (192.168.11.XXX)?

Ein Knoten im Netz prüft für jedes Datenpaket a) ist das Datenpaket für mich selbst? b) liegt der Empfänger im gleichen Subnetz? c) wenn nicht, kenne ich den zuständigen Router? oder ist das Paket d) über das Standard-Gateway weiter zu vermitteln? Haben beide Netze die gleiche Netzadresse, wird der Knoten Q1, der im Quellnetz Q sitzt und ein Paket am Z1 in Zielnetz Z weiterleiten soll, anhand der Netzadresse davon ausgehen, dass der Empfänger im eigenen Netz sitzt. Das Paket findet also nicht ans Ziel.

client --> DSL-Router --> <INTERNET> --> VPN-Router --> Klasse C Netzwerk

Nimm an, Dein LAN hat die IP-Adresse 192.168.0.0, der client darin die IP 1192.168.0.10. Wenn das Zielnetz auch die Netzadresse 192.168.0.0 hat und darin ein Knoten mit der Adresse 192.168.0.111 vorhanden ist, dem ein Paket zugestellt werden soll, dann wird 'client' davon ausgehen, dass das Paket nicht über den Router oder den Tunnel zu leiten ist, weil der Empfänger im eigenen Netz vermutet wird. Auch der Router wird Pakete, die für das Netz 192.168.0.0 bestimmt sind, nicht nicht an die WAN-Schnittstelle übergeben.

M. Boettcher

spoensche · 30 Jan. 2011

a017886 schrieb:
Code:

MODEM_IP='111.222.33.444'

Für die Modem-IP solltest du statt einer frei erfundenen IP eine reale und gültige IP verwenden. Wenn dein Router ein internes Modem hat, ist die Modemkonfiguration auf deinem Rechner vollkommen überflüssig.

a017886 schrieb:
Wo dieses 87'er Subnetz noch steht ist mir rätselhaft, das war mal ein Versuch mit YAST/Netzwerkeinstellungen/Routing.

Die Route wird angelegt, weil du in deiner /etc/hosts deinem Hostnamen eine IP aus diesem Netz zugewiesen hast. Ausserdem ist in der /etc/sysconfig/network/ifcfg-eth0 ein zweiter Eintrag IPADDR vorhanden, der eine 192.168.87.x als Wert hat.

a017886 schrieb:
Zum Sicherheitsprotokoll:
Ist openvpn und ipsec Bestandteil von PPTP? Ich nutze (noch) MSCHAP und will mich Schritt für Schritt herantasten!

Bei PPTP + MSCHAP ist Unsicherheitsprotokoll zutreffender und diesen Schritt kannst und solltest du überspringen.

OpenVPN verwendet SSL für den verschlüsselten Tunnel. IPSec setzt direk auf dem IP- Protokoll auf und verwendet L2TP (Layer 2 tunneling protocol).

a017886 · 30 Jan. 2011

Hallo Dr. Böttcher

Danke für die gute Erklärung. Das klingt plausibel.
Dazu muss ich mein gesamtes LAN umadressieren, was natürlich einige Geräte betrifft und nicht im tägl. Betrieb gemacht werden kann.
Ich melde mich an dieser Stelle bei Erfolg.

@spoensche,

wie gesagt, das Thema Modem IP ist zum Glück keines, da ich ja auf den VPN-Router mit der öffentlichen IP-Adresse (geändert) '111.222.33.444' draufkomme.
Ich kann das entfernte Gerät im anderen LAN auch administrieren. Bitte nicht verwechseln: der VPN-Router hat natürlich auch noch eine IP-Adresse für's interne (entfernte) LAN (192.168.x.x) und teilt mir per DNS (kann man ja einstellen) auch eine zu.
Das mit dem MSCHAP Protokoll habe ich auch schon gelesen, es ist aber nur eine Übergangslösung, wg. der funktionierenden Produktivumgebung in der Windows-Welt!
Die Roadmap wäre daher folgende:
1. Verbindung zum entfernten Netz herstellen (egal wie).
2. Tunnelprotokoll am VPN-Router ändern (evtl. ipsec).
3. Tunnelprotokoll am Windows-Client (im eigenen LAN) nach dem des VPN-Routers ändern (Produktivumgebung!) und nur wenn das alles funktioniert,
4. Tunnelprotokoll am Linux-Client ändern.

Danke für die Erklärung mit der IPADDR - die Datei /etc/sysconfig/network/ifcfg-eth0 kannte ich noch nicht.

Was ist mit dem Thema GRE? Spielt das evtl. eine Rolle?
Das Protokoll der VPN-Routers meldet ja

Code:

Closed : LCP Time-out (VPN-0)

Danke für Eure Hilfe!
<Problem noch nicht gelöst!>

spoensche · 30 Jan. 2011

a017886 schrieb:
Ich kann das entfernte Gerät im anderen LAN auch administrieren. Bitte nicht verwechseln: der VPN-Router hat natürlich auch noch eine IP-Adresse für's interne (entfernte) LAN (192.168.x.x) und teilt mir per DNS (kann man ja einstellen) auch eine zu.

Per DNS bekommt man keine IP zugewiesen. Du meinst bestimmt DHCP.

a017886 schrieb:
Das mit dem MSCHAP Protokoll habe ich auch schon gelesen, es ist aber nur eine Übergangslösung, wg. der funktionierenden Produktivumgebung in der Windows-Welt!

:schockiert: Das ist die schlechte Ausrede, die ich jemals gehört habe.

Du meldest dich per VPN- Client an deinem VPN- Router an, der dir nach erfolgreicher Anmeldung eine IP zuweisst und es dir ermöglicht mit den Rechnern im dahinterliegenden LAN zu kommunizieren. Wenn du jetzt das VPN umkonfigurierst, interessiert das die Rechner im LAN (hinter dem VPN- Router) wenig, da sie ihren Aufgaben trotzdem nachgehen und alle Mitarbeiter in diesem LAN mit den Rechnern ohne Probleme arbeiten können.
Wenn allerdings mehrere externe Mitarbeiter per VPN arbeiten, legst du einen Tag fest, an dem sie in die Firma kommen, dort arbeiten während du die Konfiguration des VPN Zugangs änderst und auf den Laptops einrichtest. Je nach Anzahl der externen Mitarbeiter und Laptops evtl. auch zwei Tage. Wenn das nicht machbar ist, dann wird es eben an einem Wochenende erledigt.
Das ist besser als mit einem angriffsanfälligen Protokol einen Tunnel über das Internet aufzubauen und darüber sensible Informationen zu übertragen.

a017886 schrieb:
Die Roadmap wäre daher folgende:
1. Verbindung zum entfernten Netz herstellen (egal wie).
2. Tunnelprotokoll am VPN-Router ändern (evtl. ipsec).
3. Tunnelprotokoll am Windows-Client (im eigenen LAN) nach dem des VPN-Routers ändern (Produktivumgebung!) und nur wenn das alles funktioniert,
4. Tunnelprotokoll am Linux-Client ändern.

Als aller erstest solltest du dich über die funktionsweise von IPSec und der damit verbundenen PKI, CA und Authentifizierungsmethoden und Verfahren informieren.

Zu Punkt 1: Nein, keine Verbindung zum entfernten Netz aufbauen, sondern vor Ort die Änderungen vornehmen und da führt kein Weg dran vorbei.

Zu Punkt 2: OpenVPN und IPSec nutzen Zertifikate für die Authentifizierung und Verschlüsselung.
Punkt 3: Testen des VPN´s, welchen Client du dazu verwendest bleibt dir überlassen.

a017886 schrieb:
Was ist mit dem Thema GRE? Spielt das evtl. eine Rolle?
Das Protokoll der VPN-Routers meldet ja

Code:

Closed : LCP Time-out (VPN-0)

LCP und GRE sind zwei verschiedene paar Schuhe. GRE kann deinen LCP- Timeout nicht verhindern.

GRE (Generic Routing Encapsulation Protocol) vereint IPv4/IPv6 Unicast und Multicast Verkehr und wird für dynamisch geroutete Netzwerke verwendet. D.h. es können mehrere verschiedene Routen verwendet werden.

LCP = Link Control Protocol und wird in Verbindung mit PPP verwendet und dient der Verbindungskonfiguration. Der LCP- Timeout wird bei dir evtl. durch Inaktivität ausgelöst. D.h. dass der VPN- Router die Verbindung beendet, wenn du einen gewissen Zeitraum inaktiv bist.

a017886 · 1 Feb. 2011

ps: Ja stimmt, ich meinte DHCP. Ich werd' schon irre vom stundenlangen probieren mit dem Gelumpe.

Erfolgsmeldung 1:
Der Tipp von drboe mit den unterschiedlichen Netzen hat geklappt (bereits beim MSCHAP Protokoll). Ich verstehe allerdings überhaupt nicht, warum das Windows alles egal ist. Ich konnte mich von dort immer einwählen und auf die clients im Zielnetzwerk zugreifen, egal ob die beiden LANs im gleichen oder unterschiedlichen Teilnetzen liegen. :???:
Teilerfolg 2:
Die Verbindung ist auf ipsec umgestellt, kvpnc meldet: "Policy wurde erfolgreich aufgebaut. Daemon (racoon) läuft und der Tunnel ist aktiv."
Nun müßte ich nur noch auf die dahinter liegenden clients zugreifen können ..... ?????? Ich komme mit ping nur bis auf den VPN-Router. Die Verbindung steht allerdings und bricht nicht mehr zusammen (kvpnc kann ja selber pingen).
Zur Fehlereingrenzung mal die Routen:

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.xx.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.yy.0    192.168.yy.254  255.255.255.0   UG    0      0        0 eth0
192.168.yy.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.xx.109  0.0.0.0         UG    0      0        0 eth0

xx = mein LAN
yy = Ziel - LAN

spoensche · 3 Feb. 2011

a017886 schrieb:
warum das Windows alles egal ist.

Das wissen die bei M... wohl selbst nicht, sonst würden die das ja mal ändern.

a017886" Wenn man das [b schrieb:
Teilerfolg 2:[/b]
Die Verbindung ist auf ipsec umgestellt, kvpnc meldet: "Policy wurde erfolgreich aufgebaut. Daemon (racoon) läuft und der Tunnel ist aktiv."
Nun müßte ich nur noch auf die dahinter liegenden clients zugreifen können ..... ?????? Ich komme mit ping nur bis auf den VPN-Router. Die Verbindung steht allerdings und bricht nicht mehr zusammen (kvpnc kann ja selber pingen).

Meldungen von kvpnc? (ggf. mal per Konsole die Verbindung aufbauen)
Überprüfe auch mal die Konfiguration des VPN- Routers.

a017886 · 10 Feb. 2011

:???: ... ich habe z.Zt. keine Idee wie's weitergehen soll.
KVPNC meldet nur gelbe Statusmeldungen. Nach Erhöhung des debuglevels (von 2 auf 3) kommt höchstens noch hinzu:

Code:

Debug: route (racoon): route add -net 192.168.yy.0/24 eth0
Fehler: [route err] SIOCADDRT: File exists

Ich habe am VPN-Router nochmals das Protokoll laufen lassen -> keine Fehlermelungen. Verbindung mittels ipsec hergestellt.
Die Kommandozeilenbefehle kenne ich nicht, da muss ich mich erst einarbeiten (das dauert ...).
:???:
Ich muss mir jetzt leider professionelle Hilfe holen.
Gruß Torsten

spoensche · 10 Feb. 2011

Die Route existiert doch schon und du musst sie nicht noch mal anlegen. Hast du dir mal die Router Konfiguration angesehen? Hast du an NAT-T (NAT Traversall) gedacht?

Bevor du kvpnc startest, überprüfst du mal, ob die Route schon existierts und löschst sie ggf. Wie sieht den deine kvpnc Konfiguration aus? Der Router muss doch irgendwelche Logs haben, wo du mal nachsehen kannst, was er sagt. Hast du eine CA aufgesetzt? Hast du dir eine notwendiges Zertifkat erstellt und verwendest dies auch mit kvpnc?

Nicht so schnell aufgeben. Einsatzwille ist angesagt.

Mehr Informationen sind hilfreich,z.B. die Router Logs.

VPN-Verbindung mit PPTP u. ipsec (Modem hangup)

a017886

Newbie

spoensche

Moderator

a017886

Newbie

drboe

Member

spoensche

Moderator

a017886

Newbie

spoensche

Moderator

a017886

Newbie

spoensche

Moderator

a017886

Newbie

spoensche

Moderator