LANCOM-Forum.de

Das inoffizielle Profi-Forum für LANCOM-User
Aktuelle Zeit: 25 Feb 2018, 15:14

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: 11 Feb 2018, 16:40 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
Hallo zusammen!

TL;DR:
Weiß jemand von Fällen in denen auf IPv6 aufbauende ESP Pakete vom Provider unter gewissen Umständen nicht zugestellt werden?

Hintergrund:

Setup:
  • 2 LANCOM 1781VA 10.12RU5
  • jeweils 1und1 VDSL Anschluss
  • IKEv2 Site2Site
  • IPv6 als Transport

Status:
  • VPN-Verbindung kommt zustande
  • Verbindungsaufbau benötigt oft mehrere Anläufe
  • VPN-Verbindung tunnelt IPv4 (funktioniert zeitweise)
  • Re-Keying führt zu Problemen
  • Nutzung von ESP auf IPv4: Keine Probleme!
  • Child-SA Lebenszeit auf 60s beschränken => Regelmäßig lange Ausfallzeiten nach Re-Keying

Analyse:
  • Manche ESP Pakete kommen nicht bei der Gegenstelle an (VDSL-LL Packet Capture)
  • Untersuchung mittels manueller Erzeugung von ESP Paketen (Source Code siehe Anhang)
  • Manipulation des SPI im ESP (restliche Werte im Paket unverändert)
  • Beginnt der SPI mit 0x00, 0x2bff (erstes Byte 43), 0x32ff (erstes Byte 50), 0x33ff (erstes Byte 51) oder 0x3cff (erstes Byte 60) so kommt das ESP Paket nicht am Ziel an
  • Weitere SPI-Werte gefunden, welche die Zustellung verhindern (z.B. 0xfffeffff, 0x2a070000)
  • Setzt man den Next-Header Wert im IPv6 Header auf 59 (no next header), dann werden alle Pakete zugestellt (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)

Ich sehe hier ein Softwareproblem (oder Konfigurationsproblem?) bei meinem ISP (1und1) oder gar anderer beteiligter Netzwerke.

Für mich sieht es sehr stark danach aus, als würde
  • mindestens ein Router versuchen den Header nach dem ESP Header zu finden
  • abhängig vom ersten Byte des ESP SPI (IPv6 header extenstion next header)
  • abhängig vom zweiten Byte des ESP SPI (IPv6 header extension length)
Dabei rastet dieser aus, weil er in den verschlüsselte Daten unerwartete Werte findet oder weil das Längenfeld suggeriert der nächste Header läge außerhalb der Nutzdaten.

ESP ist ein "IPv6 extended Header" (siehe Link oben), aber nur aus Sicht des Hosts, welcher das ESP entschlüsselt hat. Für jeden anderen Router sollten die Daten transparent sein. Versucht man den ESP Header zu behandeln wie sonst jeden anderen IPv6 extended Header, dann würde man versuchen in den ersten zwei Byte des SPI des ESP Paketes nach einem Next Header Byte und nach einer Header Länge zu suchen. Dabei kommt Unfug heraus. Das Verhalten, welches ich beobachte, suggeriert, dass genau das geschieht. Nicht umsonst sind ausgerechnet ESP Pakete mit SPI 0x2b, 0x32, 0x33 und 0x3c startend betroffen: Genau diese Werte suggerieren weitere IPv6 extension Header.

Heute habe ich bei 1und1 nachgefragt, aber Sonntags sind da nur die first-level Leute. Morgen würde ich gerne versuchen bei 1und1 jemanden zu erwischen der etwas darüber weiß, dass ESP Pakete mit bestimmten SPI im Nirvana landen.

Gruß


Dateianhänge:
Dateikommentar: ESP Sender Quellcode und Beispiel-tcpdumps
esp_packet_drop.zip [7.54 KiB]
7-mal heruntergeladen


Zuletzt geändert von beki am 12 Feb 2018, 22:07, insgesamt 1-mal geändert.
Dateianhang ergänzt
Nach oben
 Profil  
 
BeitragVerfasst: 11 Feb 2018, 19:49 
Offline

Registriert: 14 Mär 2012, 13:36
Beiträge: 388
Sieht das Problem vergleichbar aus, wenn du den Tunnel über IPv4 aufbaust?

_________________
LCS NC/WLAN


Nach oben
 Profil  
 
BeitragVerfasst: 11 Feb 2018, 22:03 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
5624 hat geschrieben:
Sieht das Problem vergleichbar aus, wenn du den Tunnel über IPv4 aufbaust?

Das Problem tritt mit IPv4 nicht auf (wie oben erwähnt).


Nach oben
 Profil  
 
BeitragVerfasst: 11 Feb 2018, 22:19 
Offline

Registriert: 14 Mär 2012, 13:36
Beiträge: 388
Sorry, dreimal gelesen und doch übersehen.

Jetzt wäre noch interessant, über welche Provider die Anschlüsse realisiert werden, 1&1 hat ja nur sehr wenig eigenes Netz, das meiste ist zugekauft. Nicht, dass die Anschlüsse von zwei Providern kommt und es da Probleme beim Interconnect gibt.

Wenn IPv4 läuft, würde ich erstmal auf die Antwort vom Provider warten. Wenn die negativ ist, registriere mal bei Hurricane Electric einen IPv6-Tunnel und nutz den auf einer Seite, die andere Seite bleibt bei 1&1.

_________________
LCS NC/WLAN


Nach oben
 Profil  
 
BeitragVerfasst: 11 Feb 2018, 23:06 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
5624 hat geschrieben:
registriere mal bei Hurricane Electric einen IPv6-Tunnel und nutz den auf einer Seite, die andere Seite bleibt bei 1&1.

Wow, das war ja eigentlich nur eine Fingerübung!

Geil! Vielen Dank für den Tipp! Das bekräftigt meinen Standpunkt sehr, denn:

Wenn ich am lokalen LANCOM den 6in4 Tunnel anlege und alles fein einrichte, sodass mein IPv6 Verkehr über diesen Tunnel läuft, dann erreichen alle Test-ESP-Pakete das Ziel bei meinem Eltern.

Sobald ich das zurückbaue und wieder die 1und1 Route nehme, kommen von den gleichen (Ausnahme Quell-IPv6-Adresse) 32 Paketen nur 9 Stück an.



EDIT: War: "Aber offenbar nur für Testzwecke brauchbar, denn ich habe keine feste IPv4 Adresse..." Nice! Ich sichere mir mein festes IPv6 Präfix! genial! https://forums.he.net/index.php?topic=1994.0


Nach oben
 Profil  
 
BeitragVerfasst: 12 Feb 2018, 00:16 
Offline

Registriert: 14 Mär 2012, 13:36
Beiträge: 388
Ich hab mein Prefix seit ich glaube 10 Jahren bzw. sogar zwei Prefixe. Einmal das normale /56er und dann noch ein geroutetes /48er dazu. Durch die Tunneltechnik und weil Amsterdam überlastet ist, merkt man schon Performanceeinbußen, aber als Unitymediakunde ist man Schmerz gewöhnt.

Dann hau Aans´n´aans mal auf die Finger.

_________________
LCS NC/WLAN


Nach oben
 Profil  
 
BeitragVerfasst: 12 Feb 2018, 16:56 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
Habe heute mit drei Menschen bei 1und1 telefoniert und ne Dreiviertelstunde Zeit investiert. Keiner von den Menschen am anderen Ende war in der Lage mein Problem zu verstehen oder mich mit einem Experten in Kontakt zu bringen.

In der Hoffnung, dass jemand angemessen darauf eingeht, habe ich einen ausführlichen Beitrag im 1und1 Kundenforum geleistet und den "an Support weiterleiten" Knopf aktiviert.

Mal sehen, ob dabei etwas rauskommt.


Nach oben
 Profil  
 
BeitragVerfasst: 12 Feb 2018, 21:36 
Offline

Registriert: 19 Aug 2014, 22:41
Beiträge: 295
Nicht das erste Mal wo sich jemand über VPN-Tunnelprobleme beim Einsatz von IPv6 beklagt. Deshalb sollte die Fehlereingrenzung systematisch und gründlich erfolgen. Ich empfehle folgendes Vorgehen:

1.) Überprüfung der LANCOM-VPN-Konfiguration:
http://www.lancom-forum.de/fragen-zum-thema-vpn-f14/sitetosite-vpn-lancom-pfsense-t16213.html#p91268

Den aktuellen Konfigurationswert des Anti-Replay-Schutz hier veröffentlichen:
Code:
Setup/VPN/Anti-Replay-Window-Size

2.) Die Netzwerkverbindung zwischen den beiden LANCOM-Geräten mit IPerf2/IPerf3 ausmessen (UDP-Messungen mit dem LANCOM-internen IPerf2). Messungen einmal für IPv4 und einmal für IPv6 durchführen. Messresultate der UDP-Messungen hier vollständig veröffentlichen.
http://www.lancom-forum.de/lancom-allgemeine-fragen-f23/teilweise-uber-600ms-pink-an-vdsl-obwohl-leitung-in-ordnung-t16579.html

3.) Mit der "Packet Capture"-Funktion den Netzwerkverkehr auf der VDSL-Schnittstelle (WAN) für 2 Minuten aufzeichnen ("Child SA"-Rekeying muss enthalten sein). Einmal für jeden VPN-Endpunkt. Dann beide Aufzeichnungen (*.pcap) in ein ZIP-Archiv verpacken und hier zur Wireshark-Analyse hochladen.
https://www2.lancom.de/kb.nsf/bf0ed2a4d2a4419ac125721b00471d85/1cf7e923dd5623c2c1257ad7003f3d69

4.) Mit Ping und dem Parameter "Don't fragment" die MTU der Netzwerkverbindung zwischen den beiden LANCOM-Routern herausfinden (ausserhalb des VPN-Tunnels!). Die relevanten Ping-Messresultate inklusive Ping-Parameter hier veröffentlichen.
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit#Beispiel_Ethernet


Nach oben
 Profil  
 
BeitragVerfasst: 12 Feb 2018, 22:06 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
GrandDixence hat geschrieben:
Deshalb sollte die Fehlereingrenzung systematisch und gründlich erfolgen.
Die Fehlereingrenzung wurde bereits systematisch und extrem gründlich durchgeführt. Sie führte, wie im Anfangsposting beschrieben, zu der Erkenntnis, dass das Problem darin besteht, dass offensichtlich der Provider manche ESP Pakete nicht zustellt. Abhängig vom SPI. Es besteht kein Problem mit der Konfiguration.

GrandDixence hat geschrieben:
Ich empfehle folgendes Vorgehen:
Nein.



Ich habe versäumt, den Dateianhang mit dem Quellcode für das Test-Tool anzuhängen. Das werde ich jetzt nachholen. Wäre toll, wenn jemand das an seinen Anschluss ausprobiert (Quell-, Ziel- und Next-Hop MAC müssen manuell angepasst werden) und zu ähnlichen Erkenntnissen kommt!


Nach oben
 Profil  
 
BeitragVerfasst: 13 Feb 2018, 00:34 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
Ohje, das Spielchen kann man nicht symmetrisch Spielen, wie es scheint:
Code:
received 9/32:
sudo tcpdump -vv -n -i eth-nuc -w /tmp/esp.cap esp
tcpdump: listening on eth-nuc, link-type EN10MB (Ethernet), capture size 262144 bytes
[...]
tcpdump -n -r /tmp/esp.cap
reading from file /tmp/esp.cap, link-type EN10MB (Ethernet)
23:24:32.678822 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x00040000,seq=0x12), length 120
23:24:32.742324 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x01000000,seq=0x18), length 120
23:24:32.750059 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x02000000,seq=0x19), length 120
23:24:32.760071 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x04000000,seq=0x1a), length 120
23:24:32.770312 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x08000000,seq=0x1b), length 120
23:24:32.780315 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x10000000,seq=0x1c), length 120
23:24:32.790564 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x20000000,seq=0x1d), length 120
23:24:32.800578 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x40000000,seq=0x1e), length 120
23:24:32.811249 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x80000000,seq=0x1f), length 120
Code:
received 11/32:
sudo tcpdump -vv -n -i eth-nuc -w /tmp/esp.cap esp
tcpdump: listening on eth-nuc, link-type EN10MB (Ethernet), capture size 262144 bytes
[...]
tcpdump -n -r /tmp/esp.cap
reading from file /tmp/esp.cap, link-type EN10MB (Ethernet)
23:20:29.150732 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00020000,seq=0x11), length 120
23:20:29.160786 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00040000,seq=0x12), length 120
23:20:29.170919 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00080000,seq=0x13), length 120
23:20:29.221145 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x01000000,seq=0x18), length 120
23:20:29.231016 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x02000000,seq=0x19), length 120
23:20:29.241402 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x04000000,seq=0x1a), length 120
23:20:29.250783 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x08000000,seq=0x1b), length 120
23:20:29.260932 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x10000000,seq=0x1c), length 120
23:20:29.270920 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x20000000,seq=0x1d), length 120
23:20:29.280798 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x40000000,seq=0x1e), length 120
23:20:29.290862 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x80000000,seq=0x1f), length 120

Warum kommt SPI 0x00020000 bei Host sutter an, aber nicht bei Host ritchie? Das gleiche für 0x00080000...

Spricht das gegen meinen Erklärungversuch (Next-Header Fehlinterpretation)? Was könnte die Ursache dafür sein, dass die beiden Pakete nur in eine Richtung verloren gehen?

Kann ich irgendwie herausfinden, welche Route die Pakete jeweils nehmen (traceroute scheint mir unzureichend)?


Zuletzt geändert von beki am 21 Feb 2018, 21:19, insgesamt 1-mal geändert.
typo


Nach oben
 Profil  
 
BeitragVerfasst: 21 Feb 2018, 21:22 
Offline
Moderator
Moderator

Registriert: 16 Jan 2017, 14:09
Beiträge: 83
Wohnort: SHA/BW/DE
Ein gewissen Jörg von 1und1 hat sich im Kundenforum auf meinen Beitrag gemeldet. Natürlich hat er mich gefragt, ob das Problem auch mit Fritzboxen auftritt. Also habe ich mir die Mühe gemacht und lokal als auch bei meinem Eltern eine FB als CPE eingeklemmt.

Das Problem besteht genau so wie mit den LANCOMs als CPEs. IMHO ein klarer Freispruch für die LANCOMs.

Jetzt bin ich gespannt, ob nochmal jemand reagiert.

Als Anhang die Paketmitschnitte der Fritzboxen, welche das Verhalten verdeutlichen sollen.


Dateianhänge:
Dateikommentar: Fritzbox Paketmitschnitte
2018-02-21_fritzbox_esp_packet_drops.zip [3.05 KiB]
6-mal heruntergeladen
Nach oben
 Profil  
 
BeitragVerfasst: 21 Feb 2018, 23:04 
Offline

Registriert: 12 Jan 2010, 15:10
Beiträge: 1774
Wohnort: Berlin
Hi beki,

da 1und1 doch kein eigenes Backbone im eigentlichen Sinne hat, wird es eh ein Problem bei Vodafone, Telekom oder wem auch immer sein, bzw. da bei einem der Routerhersteller / Firmwareversionen.

Gruß Dr.Einstein


Nach oben
 Profil  
 
BeitragVerfasst: 22 Feb 2018, 00:23 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 3826
Wohnort: Ex-OPAL-Gebiet
Hallo beki,

beki hat geschrieben:
Also habe ich mir die Mühe gemacht und lokal als auch bei meinem Eltern eine FB als CPE eingeklemmt.

ich hoffe das war jetzt kein so extrem großer Aufwand. Alternativ hätte man auch ZYXEL VMG1312-B30A vorsetzen können als blöde Modems. Da kann man dann auf Ethernet-Ebene wunderbar monitoren (LANCOM: Monitor-Port, oder, wenn man dem LANCOM gar nicht traut, dann mit entsprechender Switch dazwischen).

Ansonsten schön geschrieben da im 1&1-Kundenforum, auch wenn Du Deine eigene Mutmaßung im Verlauf in Frage stellst (ich kann das gut nachempfinden).

Ich hoffe, Du bekommst da wieder eine Antwort.

Dr.Einstein hat geschrieben:
da 1und1 doch kein eigenes Backbone im eigentlichen Sinne hat, wird es eh ein Problem bei Vodafone, Telekom oder wem auch immer sein, bzw. da bei einem der Routerhersteller / Firmwareversionen.

Genau: Telekom, Telefónica, QSC, ...? Bei wem seid Ihr denn in Wirklichkeit, beki? Weißt Du das? VLAN-ID und IP-Adresse können da weiterhelfen. Das wurde im Thread übrigens schon mal gefragt.
Dr. Einstein, hälst Du es damit für möglich, dass das an Telekom-Anschlüssen auch ist?

Viele Grüße,
Jirka

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 22 Feb 2018, 19:29 
Offline

Registriert: 12 Jan 2010, 15:10
Beiträge: 1774
Wohnort: Berlin
Jirka hat geschrieben:
Dr. Einstein, hälst Du es damit für möglich, dass das an Telekom-Anschlüssen auch ist?


Ersten Tests nach ja ... aber jetzt fällt mir nur ein passendes Wort dazu ein: 'tja' ... und weiter ;) ? Ohne Connections kommst du bei Telefonica, QSC, Telekom oder wem auch immer niemals bis zum Coreteam durch. Und selbst dann muss noch jemand in der Lage dazu sein, das Problem zu verstehen und selbst auch zu analysieren. Coreteams kümmern sich doch vor allem um Routing, Auslastungen etc also musst du auch da den "1st" Level im Core passieren und zum 2nd Level weiter.

Könnte mir höchstens vorstellen, dass z.B. bei Lancom, AVM, Zyxel jeweils zwei drei Leute existieren, die gute Verbindungen zu den Providern in Deutschland haben. Die haben Chancen.

Gruß Dr.Einstein


Nach oben
 Profil  
 
BeitragVerfasst: 23 Feb 2018, 00:06 
Offline

Registriert: 19 Aug 2014, 22:41
Beiträge: 295
Im Fritzbox Paketmitschnitt ""2018-02-21_19-35_7412_sender.pcap" beanstandet die Fritzbox 7490 (korrekterweise) in Frame 18 per ICMP das IPv6-Paket mit dem ESP-Paket mit der Sequenznummer 17, dass dieses IPv6-Paket im Header einen nicht korrekten Wert für "unrecognized next header type" enthält. Das ESP-Paket mit der Sequenznummer 17 ist in den Wireshark-Aufzeichnungen von Fritzbox 7412 nicht sichtbar, jedoch wird dieses ESP-Paket von der Fritzbox 7490 empfangen und korrekterweise beanstandet!

a) Es werden von der Fritzbox 7412 IPv6-Pakete versendet, die einen nicht korrekten IPv6-Header enthalten (next header type).
b) Die Wireshark-Aufzeichnungen sind lückenlos. Zwischen Frame 4 und Frame 5 fehlen einige (per ICMP nachweislich) von der Fritzbox 7412 versendete IPv6-Pakete! Eine seriöse Fehlersuche sieht anders aus...

Ich denke, die Probleme liegen vor der Tastatur...

https://de.wikipedia.org/wiki/Wireshark


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]



Ähnliche Themen
 Themen   Autor   Antworten   Zugriffe   Letzter Beitrag 
Es gibt keine neuen ungelesenen Beiträge in diesem Thema. Paketverluste

goermet

0

1060

28 Mär 2006, 14:58

goermet Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. VPN über IPV6 (Mac OSX)

AlexS

3

569

01 Jan 2017, 12:16

AlexS Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. [Gelöst] VPN Verbindung über IPv6/DSl lite

isn0gud

5

896

07 Apr 2016, 16:48

isn0gud Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. 1und1 Root-Ubuntu Server per VPN an Lancom

supreme

5

839

26 Jun 2013, 16:29

MariusP Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. VPN: IPv4 -> Portmapper -> IPv6 (TCP only VPN)

launacorp

4

755

01 Aug 2016, 11:27

launacorp Neuester Beitrag

 


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group