Strangely enough, http://test-ipv6.com/ auf einem Linux host (Ubuntu 14.04) auf dem selben Netzwerk funktioniert problemlos. Ich habe auch jumbo frames auf dem Windows-System abgestellt, hat nichts gebracht.

Was ist das Problem mit pfSense hinter der Fritzbox? Mein WAN2 ist auf 192.168.178.2 und die 7362 SL Fritte unter 192.168.178.1 hat die pfSense als exposed Host. Welche Probleme gibt es mit diesem setup? An FRITZ!Box angeschlossene Computer sind sicher vor unerwünschten Zugriffen aus dem Internet. Für einige Anwendungen wie z.B. Online-Spiele oder das Filesharing-Programm eMule muss Ihr Computer jedoch für andere Teilnehmer des Internets erreichbar sein. Durch Portfreigaben erlauben Sie solche Verbindungen. Liste der Portfreigaben Aktiv Bezeichnung Protokoll Port an Computer an Port Exposed Host alle anderen Ports PC-192-168-178-2 Bearbeiten Löschen Neue Portfreigabe Achtung: Die Firewall Ihrer FRITZ!Box ist deaktiviert. Der als "Exposed Host" angegebene Computer ist ungeschützt im Internet sichtbar und erreichbar. Ausgenommen sind Portfreigaben zu anderen Computern in der Liste der Portfreigaben, welche nur an diese weiter geleitet werden. Änderungen der Sicherheitseinstellungen über UPnP gestatten Geräte und Anwendungen mit UPnP-Unterstützung können im Heimnetz Sicherheitseinstellungen wie die Portfreigaberegeln der FRITZ!Box automatisch verändern. Aktivieren Sie diese Option aus Sicherheitsgründen nur, wenn Sie tatsächlich eingehende Verbindungen aus dem Internet gestatten möchten. Die aktuelle Konfiguration Ihrer FRITZ!Box gestattet die Änderung der Sicherheitseinstellungen über UPnP. Anwendungen mit UPnP-Unterstützung können somit automatisch weitere Ports öffnen. Liste der UPnP geöffneten Ports Protokoll Port an Rechnername an IP-Adresse an Port Es sind keine UPnP-Portfreigaben eingerichtet.

Super, freut uns :)

Eine relativ simple Antwort ist das es mein Mail Provider so vorgibt. Warum die das so machen kann ich nicht beantworten. OK dann eine dumme Frage: Was gibt der vor? Dass man sich per SSH einloggen und Mails übertragen soll? Das wäre der erste Mailprovider der solche Macken macht. Denn das ist hinten wie vorne nicht standardkonform und gibt garantiert irgendwo Probleme beim Einliefern. Kein seriöser Mailprovider weicht von den Default Ports ohne Grund ab. Deshalb gibt es festgelegte Service Ports und nicht bei Provider A 2525 und bei B 25 aber bei C 4981. Das macht für mich gerade gar keinen Sinn. Grüße

Hallo! Wenn du rausgefunden hast, wie man auf der pfSense Zertifikate verlängert, post es bitte hier, würd mich auch interessieren. ;) Die Möglichkeit einer Verlängerung gibt es wohl nur mit einem externen Generator. Sicherheitstechnisch und im Hinblick auf den Arbeitsaufwand ist es egal, ob du ein Zertifikat verlängerst oder ein neues erstellst. In beiden Fällen erhältst du ein neues Zertifikat, es muss von derselben CA stammen wie das des VPN-Servers, muss es dem User auf der pfSense hinzugefügt und im Client ersetzt werden. Das alte kann dann gelöscht werden, verliert aber ohnehin mit Ablauf seine Gültigkeit. Grüße

Ich teste es die nächsten Wochen mal ausgiebig. Bin sehr auf das Ergebnis gespannt.

Na dann würde ich mich mal an den Anbieter wenden. Das habe ich heute gemacht. Unitymedia wird mich in den nächsten Tagen auf natives IPv4 umstellen (laut deren Aussage). Dann sollte das Problem ja nicht mehr auftreten. Rein auf Grund meiner technischen Neugierde hätte ich gerne gewusst ob es eine andere Lösung gibt :-)

Mit einfachem Portforwarding ist es vermutlich nicht getan. Daher besser entweder sipproxd benutzen (läßt sich über Packages installieren) oder NAT abschalten. …da musst Du schon noch hinzufügen, das Du VoIP meinst.

Wie du schon geschrieben hast ist das völliger Müll ( milde ausgedrückt ). So fies wäre ich jetzt nicht gewesen, aber du hast recht. Mit v6 sollte niemand mehr Krücken bauen wie NAT oder ähnliches sondern genau diese vermeiden. inzwischen haben wir aus dem externen /64 subnet,  weitere /80 subnetze direkt auf die Wan Schnittstelle geroutet und eines den Internen Lan übergeben. jetzt läuft das auch vernünftig. Autsch. Das geht sicher, solltet ihr aber nicht wirklich tun. Spezifikation, RIPE und RFCs schreiben hier konkret vor, dass kein Netz kleiner als /64 vergeben werden sollte. Allerhöchste Ausnahme ist ein Transfernetz wo ggf. noch /112 oder /127 vergeben werden "dürfte", allerdings soll dann das komplette /64er abgeschrieben und weggelassen werden. Das hat sowohl mit Hardware zu tun (einige Operationen werden gerne in ASICs gegossen um sie schneller zu machen) als auch mit den Mechanismen von IPv6 wie bspw. SLAAC und Co. die NUR bei Netzen bis max. /64 funktionieren (nicht kleiner). Schneidet ihr die also jetzt in /80 funktioniert "die Hälfte der Funktionen" nicht mehr (grob gesagt). Deshalb wird hier auch normalerweise immer mehr als ein /64 an einen Endkunden vergeben (häufig /60, /56 oder /48) damit dieser seine Netze damit konfigurieren kann. Solltet ihr also nur ein /64er bekommen haben, solltet ihr da nochmal nachhaken und Druck machen, das ist eigentlich nicht normal. Selbst Telekom IP Anschlüsse oder Kabel-Kunden haben /56 oder /60 am Anschluß. Nun macht das auch Richtig Spaß mit der PFSense. Freut mich zu hören :) Was wir jetzt noch gerne hätten das wir ein weiteres /80 subnet durch zb einen Tunnel Routen um dieses  einer zweigstelle ohne IPv6 zur Verfügung stellen könnten. S.o. - ganz böse gerade beim Routing. Lieber alles auf /64er Netze umstellen, dann hat man für Clients auch die Möglichkeit ordentlich SLAAC zu nutzen und muss sich nur um Server mit fester IP kümmern. Grüße zurück Jens

Nach nunmehr 14 Tagen nochmals eine Rückmeldung meinerseits und ein grosses Dankeschön - die VOIP-Telefone funktionieren nun einwandfrei, seitdem die "State-Killing"-Einstellung angepasst wurde! :)

Hallo Kastor, da kann ich ggf. auf Golems Report vom August verweisen: http://www.golem.de/news/ipv6-der-holperige-weg-zu-neuen-ip-adressen-1408-108615-2.html Zitat: http://forum.golem.de/kommentare/internet/ipv6-der-holprige-weg-zu-neuen-ip-adressen/mussten-wir-6to4-..-auswaehlen-damit-wir-ueber-die-telekom-ipv6-nutzen-konnten/85579,3849109,3849109,read.html#msg-3849109 "Oder anders gesagt: Telekom kann bei euch kein IPv6 und man muss halt IPv6 ueber IPv4-Pakete versenden. Eine v6 Verbindung bekamen wir nur bei Auswahl eines 6to4 Tunnels zustande." Es scheint also, als wäre da ggf. kein ordentliches v6 geschaltet, ggf. musst dus auch einfach nochmal antriggern und dort anfragen, dass dein Anschluß das machen soll. Grüße Jens

Moin, Du hast mich fast richtig verstanden ;D DHCP geht nicht da Client fest konfiguriert. 2 gleiche Netze am Router = schlechte Idee Deshalb wollte ich das per Bridge mit Regeln lösen: Absender hat falsche IP –> block Absender will ins Lan –> block Absender will ins Wan –> OK

Das würde auch dem klassische "Out of Bounds Management" Stil entsprechen, womit du die Maschinen noch erreichen und managen kannst, selbst wenn ihr Haupt-Interface abgeschnitten wurde oder du sicherheitshalber ihr WAN abgeschaltet oder geblockt hast, damit nichts mehr raus oder rein geht. :) Viele Grüße

Hallo, ja - hast du natürlich recht :-) Dachte man könnte das vielleicht noch als angrenzendes Gebiet betrachten. Ich habe es mittlerweile gelöst. Für die Allgemeinheit wie Versprochen: iptables -t nat -I PREROUTING -i tun11 -p tcp –dport 9100 -j DNAT --to-destination 192.168.1.240 Das war die Lösung. Alles was vom VPN Netz an Port 9100 sendet, wird an 192.168.1.240 weitergeleitet. Die Konfiguration unter Portforwarding in der Tomatofirmware hat keinen Einfluss darauf! Habe diese wieder gelöscht liebe Grüße und Danke für die Unterstützung bei den anderen Fragen!

Setze mal bei den Systemeinstellungen "Allow default gateway switching".

So, ich habe einfach mal alles neu installiert. Geht schneller, als ewig nach dem Fehler zu suchen

Servus, ich habe vermutlich die Lösung gefunden, zumindest ist jetzt Ruhe: Gateway-Monitoring deaktivert. Seither ist der Tunnel stabil  ::) Vielen Dank, meine Herren!