7100+ Wan Verbindungen

[blackeagle2002de]

Hallo,

wir müssen unsere Bandbreite erhöhen und planen mehrere VDSL Anschlüsse an unserem 7100+ zu nutzen. Ich hatte vor längerer Zeit hier mal gelesen, dass der Lancom maximal 8 Wan Verbindungen (durch VLAN getrennt) aufbauen kann, ist das korrekt? Wie müssen die Verbindungen dann auf die Ports verteilt werden? Kann jeder Port nur zwei Verbindungen aufbauen, oder kann ich theoretisch alle 8 Verbindungen einem Port zuweisen und den restlichen drei Ports andere Aufgaben zuweisen? Damit Qos richtig funktioniert, muss ich ja auch die Geschwindigkeit des Anschlusses angeben, diese kann ich jedoch pro Port nur einmal hinterlegen. Sollte ich deshalb besser alle Wan Verbindungen, die die gleiche Geschwindigkeit haben auf einen Port legen. Wir haben konkret 3 VDSL Leitungen mit der gleichen Geschwindigkeit, 2 Kabel Deutschland Leitungen mit der gleichen Geschwindigkeit und eine SDSL Leitung. Ich würde jetzt drei Ports für die Wan Verbindungen einrichten und die VDSL Leitungen auf Port 1 legen, die Kabel Leitungen auf Port 2 und die SDSL Leitung auf Port3, Port 4 wird für das LAN genutzt. Somit wäre theoretisch für alle Leitungen die Geschwindigkeitsangabe in den Interface-Einstellungen korrekt. Funktioniert das so?

Grüße
blackeagle2002de

[garfield0815]

Hmm nur so an rande gefragt

ihr habt 2 kde Anschlüsse

nach meiner technischem verstentniss

die laufen aber doch physikalisch über die gleiche leitung
oder habt ihr da 2 leitungen zum verteiler von kde ????

und eigendlich müse dann doch CSMA/CD greifen
und da kann ja immer nur einer auf der leitung sprechen

[blackeagle2002de]

Die beiden Kabel Deutschland Leitungen gehen natürlich beide über den gleichen Hausanschluss raus. Es ist aber bei beiden Anschlüssen die volle Bandbreite gegeben, d. h. wir haben 2 x 100 Mbit im Download und 2 x 6 Mbit im Upload (getestet und funktioniert).

[backslash]

Hi blackeagle2002de,

die 8 DSL-Verbindungen kannst du prinzipiel beliebig über die Ethernet-Ports verteilen... Nur bekommst du dann Probleme mit QoS, weil die Firewall meint, jeder Verbindung habe die konfigurierte Maximal-Bandbreite eines Ports für sich allein, während es sich auf dem Port selbst genau anders herum verhält, d.h. hier wird sich die konfigurierte Bandbreite geteilt... Wenn du also Dinge mit QoS machen willst, dann soltest du jeder DSL-Verbindung einen eigenen Ethernet-Port spendieren (OK, dann sind es halt maximal 4, aber das ist eher ein akademisches Problem). Außerdem mußt du dich dann nicht mit VLANs herumärgern

Gruß
Backslash

[blackeagle2002de]

Hallo Backslash,

vielen Dank für Deine Antwort. So ganz richtig verstanden habe ich das aber noch nicht. Ich habe z. B. zwei gleich schnelle VDSL Leitungen. Dann aktiviere ich unter Schnittstellen->Wan->Interface-Einstellungen->DSL-1 mit 50 Mbit im Download und 10 Mbit im Upload. Dann weise ich unter Schnittstellen->Lan dem Ethernet Port 1 die DSL-1 Schnittstelle zu. Unter Kommunikation-Gegenstellen lege ich dann die beiden VDSL Leitungen an, unter dem DSL-Port 1, getrennt nach VLAN-ID. Dann trifft die unter Schnittstellen eingetragenen Geschwindigkeit doch für beide Leitungen zu, oder habe ich da einen Denkfehler?


Wir nutzen QoS, aber noch wichtiger, wir nutzen für unsere VPN-Vernetzung ein Extranet-VPN mit PPTP Verbindungen im Loadbalancing Verfahren, dafür muss dem Router die Geschwindigkeit ja auch bekannt sein oder?

Bleibt uns dann nur die Variante mit 4 Leitungen?

Ein LAN-Port des Lancom muss ja noch übrig bleiben für die Verbindung zum LAN. Kann ich über diesen Port trotzdem eine VDSL Verbindung aufbauen, wenn ich z. B. DSL-Port 4 aktiviere und die Geschwindigkeit eintrage, dem DSL-Port 4 aber keinen Ethernet-Port zuweise, sondern in den Gegenstellen einfach die VDSL Verbindung anlege mit DSL-Port 4 und VLAN-ID? Die VDSL Verbindung kommt also über VLAN auf dem gleichen Kabel zum Lancom wie das ungetaggte LAN.

Vielen Dank,
blackeagle2002de

[backslash]

Hi blackeagle2002de,

Unter Kommunikation-Gegenstellen lege ich dann die beiden VDSL Leitungen an, unter dem DSL-Port 1, getrennt nach VLAN-ID. Dann trifft die unter Schnittstellen eingetragenen Geschwindigkeit doch für beide Leitungen zu

ja, aber es wird im Interface und der Firewall anders interpretiert... Im Interface aus du nun einen "Summen-Upload" von 10 MBit/s, d.h. *beide* Verbindunegn *teilen* sich die 10 MBit/s, während die Firewall damit rechnet, daß jede Verbindung 10 MBit/s für sich hat...

Das ist ein lange bekanntes Poblem - die Gründe, warum das bisher nicht behoben wurde, sind nicht technischer Natur

Wir nutzen QoS, aber noch wichtiger, wir nutzen für unsere VPN-Vernetzung ein Extranet-VPN mit PPTP Verbindungen im Loadbalancing Verfahren, dafür muss dem Router die Geschwindigkeit ja auch bekannt sein oder?

für den Loadbalancer als solchen ist nur das Verhältnis der Bandbreiten wichtig, weil er die Sessions anhand dieser auf die Verbindungen verteilt. Auf dem Ethernet hingegen werden alle gesendeten Pakete auf die eingetragene Bandbreite limitiert (unabhängig vom VLAN). D.h. du könntest theoretisch bei zwei DSL-Verbindungen, die über einen Ethernet-Port gehen, die Doppelte Bandbreite eintragen - das führt im schlimmsten Fall aber dazu, daß eine Verbindung auch mit doppelt so vielen Paketen geflutet wird, welche dann vom davor liegenden (Kabel-)Modem verworfen werden...

Bleibt uns dann nur die Variante mit 4 Leitungen?

Wenn QoS sauber funktionieren soll, dann ja...

Kann ich über diesen Port trotzdem eine VDSL Verbindung aufbauen, wenn ich z. B. DSL-Port 4 aktiviere und die Geschwindigkeit eintrage, dem DSL-Port 4 aber keinen Ethernet-Port zuweise, sondern in den Gegenstellen einfach die VDSL Verbindung anlege mit DSL-Port 4 und VLAN-ID? Die VDSL Verbindung kommt also über VLAN auf dem gleichen Kabel zum Lancom wie das ungetaggte LAN.

nein, das geht nicht...

Gruß
Backslash

[blackeagle2002de]

Hallo Backslash,

vielen Dank für die erneuten Erklärungen. Unser Bandbreitenbedarf wird immer größer, gerade im Upload, insofern würde ich dazu tendieren auf QoS zu verzichten, wenn wir faktisch durch die neuen VDSL Leitungen eine wesentlich höhere Bandbreite bekommen. Wenn immer genug Bandbreite zur Verfügung steht, muss sie ja eigentlich auch nicht mehr priorisiert werden.

Wir haben zur Zeit eine 4 Mbit SDSL Leitung, zwei KD 100 Mbit Leitungen und eine VDSL 50 Mbit Leitung (es sollen nach unserer Planung ein, ggf. auch zwei weitere VDSL Leitungen mit 50 Mbit dazukommen, so dass wir in Summe 20 bzw. 30 Mbit im Upload über die VDSL Leitungen haben).

Ich würde dann QoS deaktivieren, der 4 Mbit SDSL Leitung DSL-Port 1 zuweisen, den beiden KD Leitungen mittels VLAN DSL-Port 2 (mit der Geschwindigkeitsangabe 200 Mbit Down, 12 Mbit Up) und die drei VDSL Leitungen mittels VLAN DSL-Port 3 zuweisen (mit der Geschwindigkeitsangabe 150 Mbit Down, 30 Mbit Up).

Wäre das die richtige Lösung, wenn wir auf QoS verzichten? Das wichtigste ist für uns, dass das Loadbalancing der PPTP Verbindungen richtig funktioniert. Hauptanwendung der VPN (bzw. PPTP) Anbindung ist die Bereitstellung unserer RDP Terminalserver. Wir stellen gerade auf Server 2012 um, der schnelle Bildaufbau ist sehr gut im Vergleich zu älteren Versionen, funktioniert jedoch leider nur bei entsprechend höherer Bandbreite, deshalb ist uns die Erhöhung des Uploads so wichtig. Entsprechende Downloadkapazität in den Außenstellen ist vorhanden.

Vielen Dank,

blackeagle2002de

[00Schneider]

Nur zur Info:

KD hat den Upload bei Business 100 auf 12 Mbit/s erhöht. Damit hast Du allein von KD schon 24 Mbit/s.

00

[blackeagle2002de]

Hallo Backslash,

könntest Du mir freundlicherweise noch eine kurze Antwort geben, ob die Schlussfolgerungen, die ich in meinem letzten Beitrag geschlossen habe, so richtig sind?

Vielen Dank und viele Grüße

blackeagle2002de

[backslash]

Hi blackeagle2002de.

Ich würde dann QoS deaktivieren, der 4 Mbit SDSL Leitung DSL-Port 1 zuweisen, den beiden KD Leitungen mittels VLAN DSL-Port 2 (mit der Geschwindigkeitsangabe 200 Mbit Down, 12 Mbit Up) und die drei VDSL Leitungen mittels VLAN DSL-Port 3 zuweisen (mit der Geschwindigkeitsangabe 150 Mbit Down, 30 Mbit Up).

das verhindert aber nicht, daß die einzelnen Leitungen nicht doch mit z.B. abgehendem UDP-Traffic überrannt werden können, denn du mußt ja auf dem Interface bei n genutzten VLANs auch die n-Fache Uploadrate eintragen... Solange du nur mit TCP arbeitest, ist das alles kein Problem, da sich TCP automatisch an die verfügbare Bandbreite anpaßt.

Wäre das die richtige Lösung, wenn wir auf QoS verzichten? Das wichtigste ist für uns, dass das Loadbalancing der PPTP Verbindungen richtig funktioniert.

Der Loadbalancer denkt hier zunächst aber, er hätte nun pro Kanal die vollen 12 bzw. 30MBit zur Verfügung. - Da die Kanäle heir zu maximal 50% bzw. 30% ausgelastet werden und der Loadbalancer immer den am wenigsten ausgelasteten Kanal wählt, wird sich an der Sessionzuweisung nicht viel ändern...

Hauptanwendung der VPN (bzw. PPTP) Anbindung ist die Bereitstellung unserer RDP Terminalserver. Wir stellen gerade auf Server 2012 um, der schnelle Bildaufbau ist sehr gut im Vergleich zu älteren Versionen, funktioniert jedoch leider nur bei entsprechend höherer Bandbreite, deshalb ist uns die Erhöhung des Uploads so wichtig. Entsprechende Downloadkapazität in den Außenstellen ist vorhanden.

letztendlich gilt immer probieren geht über studieren...

Gruß
Backslash

[blackeagle2002de]

Hi Backslash,

vielen Dank für Deine Antwort. Das ist dann ein Problem. Unter Server 2012 wird für die RDP Verbindung UDP verwendet, und zwar für alles. Auch die Druckauftrage werden über das RDP Protokoll, also dann über UDP übertragen. Das heißt ca. 90% wird UDP-Traffic sein. Fällt Dir dazu irgendeine Lösung ein?

Könnte ich nicht mittels der Firewall den Upload entsprechend beschränken? Also in der Schnittstelle trage ich die n-fachen Down- und Uploadwerte ein. In der Routingtabelle sind die Leitungen per Routing-Tag differenziert. In der Firewall lege ich dann für jede Leitung (bzw. Routing Tag) eine Regel an, die den Upload auf die wirkliche Bandbreite begrenzt und dass der Lancom die darüber hinaus gehenden Pakete zurückweist (dann werden die Pakete ja nicht verworfen, funktioniert das mit UDP?)


Viele Grüße
blackeagle2002de

[backslash]

Hi blackeagle2002de,

Könnte ich nicht mittels der Firewall den Upload entsprechend beschränken? Also in der Schnittstelle trage ich die n-fachen Down- und Uploadwerte ein. In der Routingtabelle sind die Leitungen per Routing-Tag differenziert. In der Firewall lege ich dann für jede Leitung (bzw. Routing Tag) eine Regel an, die den Upload auf die wirkliche Bandbreite begrenzt und dass der Lancom die darüber hinaus gehenden Pakete zurückweist (dann werden die Pakete ja nicht verworfen, funktioniert das mit UDP?)

ja, das würde funktionieren. Du solltest in der Regel aber nicht "zurückweisen" einstellen, denn dann werden auch knapp überzählige Pakete verworfen (und mit einem ICMP host unreachable beantwortet) und auch der Sessioneintrag gekillt... Hier ist "verwerfen" die richtige Einstellung - die führt bei Maximalbandbreiten dazu, daß die überzähligen Pakete zwischengespeichert und in der nächsten Sekunde erneut gesendet werden.

Aber ich hoffe doch, daß MS da irgendeinen Mechanismus eingebaut hat, um festzustellen, daß die Bandbreite überschritten wurde, um daraufhin die Datenrate zu senken...

Gruß
Backslash

[blackeagle2002de]

Hallo Backslash,

leider hat sich bei uns nun nach Inbetriebnahme ein neues, sonderbares Problem ergeben. Nachdem ich die fünfte Leitung in Betrieb genommen habe musste ich feststellen, dass sich über diese Leitung keine PPTP Verbindung aufbauen können. VPN funktioniert, nur der PPTP Tunnel darüber nicht. Es ist auch egal welche Leitung ich nehme, wenn ich z. B. von den 5 Leitungen zwei lösche und dann zuerst die ehemals "5 Leitung" im Lancom einrichte funktioniert der PPTP Aufbau über diese Leitung, während die ehemals "4. Leitung" über die der PPTP Aufbau vorher geklappt hat dann nicht mehr funktioniert, wenn ich sie als neue 5. Leitung einrichte. Ich kann mir das nicht erklären, es kommt also nicht darauf an welche Leitung es ist, sondern welche zuletzt am Lancom eingerichtet wurde.

Der PPP trace über die nicht funktionierende Leitung sind dann folgendermaßen aus:

[PPP] 2014/04/11 11:43:00,742

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 04 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 04 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:00,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 07 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:00,790
PPTP call control: ack missing for packet # 12 on KRUEHAN-PPTP-3, call id 2126 -
correct acknowledged sequence number
PPTP call control: set remote window to 2 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:00,832

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 07 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:03,744

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 06 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 06 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:03,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 09 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:03,832

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 09 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:06,743

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 08 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 08 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:06,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0b and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:06,833
PPTP call control: set remote window to 3 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:06,833

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0b and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:09,743

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0a and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0a and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:09,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0d and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:09,832

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0d and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:12,743

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0c and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0c and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:12,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0f and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:12,832

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0f and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:15,741

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0e and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0e and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:15,790
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 11 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:15,831
PPTP call control: set remote window to 4 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:15,831

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 11 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:16,115
selecting next remote gateway using strategy eFirst for KRUEHAN-PPTP-3
=> no remote gateway selected

[PPP] 2014/04/11 11:43:16,115
selecting first remote gateway using strategy eFirst for KRUEHAN-PPTP-3
=> CurrIdx=0, IpStr=>10.0.3.3<, IpAddr=10.0.3.3, IpTtl=0s

[PPP] 2014/04/11 11:43:16,115
PPTP call control: connect timeout for call id 2126
PPTP call control: closing call for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:16,117
PPTP call control: call destroyed for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:19,110
PPTP control channel: connecting to KRUEHAN-PPTP-3 (10.0.3.3)
PPTP control channel: waiting for TCP connect for KRUEHAN-PPTP-3 (10.0.3.3)
PPTP control channel: use local port: 11219 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:19,250
Change phase to ESTABLISH for KRUEHAN-PPTP-3
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds


[PPP] 2014/04/11 11:43:19,250
PPTP call control: received OutgoingCallReply from 10.0.3.3 for call id 8830: pe
er call id 5312
PPTP call control: SetLinkInfo sent for call id 8830 to 10.0.3.3 with SendACCM=0
x00000000 and ReceiveACCM=0x00000000
PPTP call control: set remote window to 32 for KRUEHAN-PPTP-3
PPTP call control: connect request for PPP sent
PPTP call control: received SetLinkInfo from 10.0.3.3 for call id 8830 with Send
ACCM=0x00000000, ReceiveACCM=0x00000000


[PPP] 2014/04/11 11:43:19,450
Positive Restart-Timeout event for LCP
Stop waiting for connection
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer KRUEHAN-PPTP-3
Inserting local MRU 1352
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number 043264c6
Sending LCP configure-request with ID 00 and length 19 to peer KRUEHAN-PPTP-3 (c
hannel 0)
Starting LCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:19,491

Received LCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number caeef346 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer KRUEHAN-PPTP-3 (chann
el 0)


[PPP] 2014/04/11 11:43:19,593

Received LCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for KRUEHAN-PPTP-3
Stopping LCP restart timer


[PPP] 2014/04/11 11:43:19,599

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Challenge from peer KRUEHAN-PPTP-3
Challenge = 22 bf ef 3e 8c 20 bb df ca 2b a3 7b d5 69 34 40
Found peer-id KRUEHAN-PPTP-3 in PPP table
Sending CHAP-response to peer KRUEHAN-PPTP-3 (channel 0), length = 16


[PPP] 2014/04/11 11:43:22,590

Tx-Authentication retry timeout for peer KRUEHAN-PPTP-3

Sending CHAP-response to peer KRUEHAN-PPTP-3 (channel 0), length = 16


[PPP] 2014/04/11 11:43:22,598
PPTP call control: ack missing for packet # 2 on KRUEHAN-PPTP-3, call id 8830 -
correct acknowledged sequence number
PPTP call control: set remote window to 16 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:22,632

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Success from peer KRUEHAN-PPTP-3
restart own authentication

Sending CHAP-Challenge to peer KRUEHAN-PPTP-3 (channel 0)
Challenge = e7 77 f1 d0 73 4d f9 63 da 3f 76 25 5b fa a3 10


[PPP] 2014/04/11 11:43:25,630
PPTP call control: ack missing for packet # 4 on KRUEHAN-PPTP-3, call id 8830 -
correct acknowledged sequence number
PPTP call control: set remote window to 8 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:27,630

Rx-Authentication retry timeout for peer KRUEHAN-PPTP-3

Sending CHAP-Challenge to peer KRUEHAN-PPTP-3 (channel 0)
Challenge = 07 03 b2 ba d7 c8 d2 64 38 bf 8a 72 61 c4 9a 76


[PPP] 2014/04/11 11:43:27,672

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Response from peer KRUEHAN-PPTP-3, length = 16
Searching peer KRUEHAN-PPTP-3 in PPP table...peer found
Checking response...response valid
Sending CHAP-Success for peer KRUEHAN-PPTP-3
This-Layer-Up action for LCP
Change phase to CALLBACK for KRUEHAN-PPTP-3
This-Layer-Up action for LCP
Change phase to NETWORK for KRUEHAN-PPTP-3
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Inserting secondary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 34 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:27,715

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 00 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 00 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:27,722

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-reject with ID 00 and size 16
Peer rejects secondary DNS address , discard local option
Peer rejects secondary NBNS address , discard local option
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 02 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:30,712

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 02 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 02 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:30,720
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 04 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:30,720
PPTP call control: ack missing for packet # 8 on KRUEHAN-PPTP-3, call id 8830 -
correct acknowledged sequence number
PPTP call control: set remote window to 4 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:30,761

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-nak with ID 04 and size 16
Peer NAKs primary DNS address 169.254.76.1, accepted
Peer NAKs primary NBNS address 169.254.76.1, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 05 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:33,713

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 04 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 04 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:33,759
PPTP call control: ack missing for packet # 12 on KRUEHAN-PPTP-3, call id 8830 -
correct acknowledged sequence number
PPTP call control: set remote window to 2 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:33,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 07 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:33,802

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 07 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:36,712

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 06 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 06 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:36,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 09 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:36,803

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 09 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:39,712

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 08 and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 08 and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:39,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0b and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:39,803
PPTP call control: set remote window to 3 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:39,803

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0b and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:42,711

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0a and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0a and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:42,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0d and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:42,802

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0d and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:45,711

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0c and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0c and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:45,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 0f and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:45,802

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 0f and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:48,710

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 0e and size 34
Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250
Peer requests secondary DNS address 0.0.0.0, rejected
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 0e and length 22 to peer KRUEHAN-PPTP-3 (c
hannel 0)


[PPP] 2014/04/11 11:43:48,760
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 169.254.76.1
Inserting primary NBNS address 169.254.76.1
Sending IPCP configure-request with ID 11 and length 22 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:48,803
PPTP call control: set remote window to 4 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:48,803

Received IPCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 11 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds


[PPP] 2014/04/11 11:43:49,087
selecting next remote gateway using strategy eFirst for KRUEHAN-PPTP-3
=> no remote gateway selected

[PPP] 2014/04/11 11:43:49,087
selecting first remote gateway using strategy eFirst for KRUEHAN-PPTP-3
=> CurrIdx=0, IpStr=>10.0.3.3<, IpAddr=10.0.3.3, IpTtl=0s

[PPP] 2014/04/11 11:43:49,087
PPTP call control: connect timeout for call id 8830
PPTP call control: closing call for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:49,089
PPTP call control: call destroyed for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:52,080
PPTP control channel: connecting to KRUEHAN-PPTP-3 (10.0.3.3)
PPTP control channel: waiting for TCP connect for KRUEHAN-PPTP-3 (10.0.3.3)
PPTP control channel: use local port: 9411 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:52,222
Change phase to ESTABLISH for KRUEHAN-PPTP-3
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds


[PPP] 2014/04/11 11:43:52,222
PPTP call control: received OutgoingCallReply from 10.0.3.3 for call id 13216: p
eer call id 10848
PPTP call control: SetLinkInfo sent for call id 13216 to 10.0.3.3 with SendACCM=
0x00000000 and ReceiveACCM=0x00000000
PPTP call control: set remote window to 32 for KRUEHAN-PPTP-3
PPTP call control: connect request for PPP sent
PPTP call control: received SetLinkInfo from 10.0.3.3 for call id 13216 with Sen
dACCM=0x00000000, ReceiveACCM=0x00000000


[PPP] 2014/04/11 11:43:52,420
Positive Restart-Timeout event for LCP
Stop waiting for connection
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer KRUEHAN-PPTP-3
Inserting local MRU 1352
Inserting local authentication protocol CHAP with MD5 encryption
Inserting local magic number 52b8e3e5
Sending LCP configure-request with ID 00 and length 19 to peer KRUEHAN-PPTP-3 (c
hannel 0)
Starting LCP restart timer with 3000 milliseconds


[PPP] 2014/04/11 11:43:52,462

Received LCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-request with ID 00 and size 19
Peer MRU 1352 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 411c8e6c accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 19 to peer KRUEHAN-PPTP-3 (chann
el 0)


[PPP] 2014/04/11 11:43:52,563

Received LCP frame from peer KRUEHAN-PPTP-3 (channel 0)
Evaluate configure-ack with ID 00 and size 19
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for KRUEHAN-PPTP-3
Stopping LCP restart timer


[PPP] 2014/04/11 11:43:52,569

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Challenge from peer KRUEHAN-PPTP-3
Challenge = 73 1c 25 c5 e7 5c 26 b0 9e 3b 74 70 b3 53 64 d6
Found peer-id KRUEHAN-PPTP-3 in PPP table
Sending CHAP-response to peer KRUEHAN-PPTP-3 (channel 0), length = 16


[PPP] 2014/04/11 11:43:55,560

Tx-Authentication retry timeout for peer KRUEHAN-PPTP-3

Sending CHAP-response to peer KRUEHAN-PPTP-3 (channel 0), length = 16


[PPP] 2014/04/11 11:43:55,566
PPTP call control: ack missing for packet # 2 on KRUEHAN-PPTP-3, call id 13216 -
correct acknowledged sequence number
PPTP call control: set remote window to 16 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:43:55,602

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Success from peer KRUEHAN-PPTP-3
restart own authentication

Sending CHAP-Challenge to peer KRUEHAN-PPTP-3 (channel 0)
Challenge = ad da d5 25 ba 0e 45 66 1b 56 b3 91 34 d2 6e 76


[PPP] 2014/04/11 11:43:58,599
PPTP call control: ack missing for packet # 4 on KRUEHAN-PPTP-3, call id 13216 -
correct acknowledged sequence number
PPTP call control: set remote window to 8 for KRUEHAN-PPTP-3


[PPP] 2014/04/11 11:44:00,600

Rx-Authentication retry timeout for peer KRUEHAN-PPTP-3

Sending CHAP-Challenge to peer KRUEHAN-PPTP-3 (channel 0)
Challenge = dc ef 84 f8 c1 d1 69 19 f2 e9 83 54 3a bd d9 7e


[PPP] 2014/04/11 11:44:00,642

Received CHAP frame from peer KRUEHAN-PPTP-3 (channel 0)
Got CHAP-Response from peer KRUEHAN-PPTP-3, length = 16
Searching peer KRUEHAN-PPTP-3 in PPP table...peer found
Checking response...response valid
Sending CHAP-Success for peer KRUEHAN-PPTP-3
This-Layer-Up action for LCP
Change phase to CALLBACK for KRUEHAN-PPTP-3
This-Layer-Up action for LCP
Change phase to NETWORK for KRUEHAN-PPTP-3
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer KRUEHAN-PPTP-3
Inserting IP address 10.24.56.250
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Inserting secondary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 34 to peer KRUEHAN-PPTP-3 (
channel 0)
Starting IPCP restart timer with 3000 milliseconds

Irgendeine Ahnung woran das liegen könnte? Vielen Dank und viele Grüße

blackeagle2002de

[backslash]

Hi blackeagle2002de


da akzeptiert die Gegenseite nicht, daß ihm ein DNS-Server zugewiesen wird:

Code: Alles auswählen

Peer requests IP address 169.254.76.1, accepted
Peer requests primary DNS address 0.0.0.0, NAK with 10.24.56.250

Die Anfrage wird solange wiederholt, bis der Teimeout für den Verbindungsaufbau zuschlägt:

[PPP] 2014/04/11 11:43:16,115
PPTP call control: connect timeout for call id 2126
PPTP call control: closing call for KRUEHAN-PPTP-3

Die Frage ist nun: Wieso wird die Anfrage ständig wiederholt? OK, die triviale Antwort ist einfach: Weil die Zuweisung des DNS-Servers nicht ankommt...
Die Frage lautet also: Wo geht das betreffende Paket verloren und warum geht genau dieses Paket zuverlässig verloren...

Da bin ich momentan auch überfragt

Gruß
Backslash

[langewiesche]

du kannst auch das neue RDP per TCP Fahren ... kann am Server einstellen ... dann ist der UDP verlust nicht so hoch ...
Ber ich denke nicht das ein 7100+ das mit seinen 4 interface hin bekommt. gerade da rpd je massiv keineste paket groessen verwendet da macht der cpu auch zu. (50 mbit mit so kleinen paketen ist schon sportlich)