IPv6 Prefix im LAN ohne RA vom ISP
-
Aber zurück zum Thema. Am liebsten wäre mir natürlich eine Umstellung auf IPv4 only obwohl ich es ähnlich wie einige der Forumuser hier sehe, dass IPv6 die Zukunft ist und man sich dieser auch nicht verschließen sollte. Ich hätte auch mit IPv6 Dualstack kein Problem nur sollte die Technik dann auch vernünftig funktionieren.
Ich hatte mit dem Dualstack bislang kein Problem, ich nutze nur den v6 Teil nicht, da er mit einer FB nicht ordentlich funktioniert und ich keine Lust habe, ständig wechselnde Netze zu haben. Privacy hin oder her, es kann mir heute keiner erzählen, dass er sich auf wechselnde IP Adressen als Privacy verlässt. Wäre das so, wäre Snowden wahrscheinlich bereits verschwunden statt im Exil.
Am liebsten wäre mir natürlich eine Umstellung auf IPv4 only
Letzte Aussagen von UM in BW waren (sehr seltsamer Weise), dass momentan nur auf explizite Anfrage v6 geschaltet wird. Warum auch immer. Totaler Unfug aber angeblich gäbe es mit diesem neuen Protokoll ja nur Probleme etc. (…) da bleibt mir mitunter schon manches Mal der Mund offen. Mein Kollege bspw. bekommt es ums Verrecken kein IPv6 geschaltet.
Ein Tunnel bei HE konnte ich nicht beantragen, da der Tunnel Endpunkt (das AFTR Gateway bei UM) mittels ICMP nicht erreichbar ist. Wenn nicht jemand von euch noch eine gute Idee hat, bleibt nur auf die Antwort meiner Beschwerde zu warten.
Warum wo ist das Problem? Es muss ja nur der "Träger" der öffentlichen IP per Ping erreichbar sein. Das ist im Normalfall der Router/die Fritzbox/etc. - also einfach dort Ping/ICMP incoming von HE.net erlauben und gut ist.
Hast Du einen Tipp für mich wie ich UM gegenüber am besten für ein reines Modem argumentieren kann?
Wenn das unbedingt sein muss, könnte man da gut Remote Einwahl / VPN angeben, viele Firmen wollen heute ihre Mitarbeiter extern angebunden haben, damit die auch von zu Hause aus arbeiten können. Da sollte das Internet dann eben mitspielen. Ich habe da recht gute Erfahrungen mit UM/KBW in BW gemacht, allerdings habe ich auch einen recht guten Service Partner der den Anschluß betreut erwischt, mit dem ich ordentlich Technik reden kann und der dann auch kein Bullshit Bingo spielt.
Gruß Jens
-
Warum wo ist das Problem? Es muss ja nur der "Träger" der öffentlichen IP per Ping erreichbar sein. Das ist im Normalfall der Router/die Fritzbox/etc. - also einfach dort Ping/ICMP incoming von HE.net erlauben und gut ist.
Ich habe DS-Lite von UM und das AFTR Gateway ist mittels ICMP nicht erreichbar. Das ist allerdings meine externe IPv4 Adesse. Da hilft doch eine Aktivierung von ICMP-Reply auf dem WAN IF meines Routers/Modems doch auch nicht.
Wenn das unbedingt sein muss, könnte man da gut Remote Einwahl / VPN angeben, viele Firmen wollen heute ihre Mitarbeiter extern angebunden haben, damit die auch von zu Hause aus arbeiten können.
Dieses Argument habe ich bereits in meiner ersten Beschwerde Anfang 2013 angegeben. Seit dem bin ich bei UM Kunde und habe direkt einen DS-Lite Anschluss erhalten. UM bietet hier ein "Fairsprechen" an. D.h. ich kann meinen Vertrag innerhalb von 14 Tagen nach Aktivierung kündigen. Die Kündigung habe ich schriftlich angedroht, da mein IPSec und SSL VPN zu meinem Arbeitgeber nicht sauber mit DS-Lite funktioniert. UM ist überhaupt nicht drauf eingegangen und hat den Vertrag direkt gekündigt. Es war nur ein Versuch meinerseits. Daher habe ich eine Stornierung der Kündigung erwirkt.
Trotzdem besten Dank für den Tipp.
P.S.: Bei UM hier in NRW bekommt man als Privatkunde mittlerweile nur noch IPv6 Anschlüsse geschaltet. IPv4 gibt es nur noch bei Business Anschlüssen.
-
Interessant wie stark sich das regional unterscheidet. KabelBW (UM BW) ist hier gerade auf "Kurs zurück" gegangen weil die Klagen bei Endkunden die sich mit v6 nicht wirklich auskennen ausgeartet sind. Davor war KabelBW aber eh generell recht gut mit v4 Adressen bestückt gewesen. In NRW bei UM und bei KD (Kabel Deutschland) ist die Lage wohl auch anders, da man kaum wirklich v4 Adressen hat und deshalb nur DS-Lite anbieten kann und CGN & IPFT Gateways betreibt. Sehr vertrackt… Da wird dann auch die Argumentation recht fad ausfallen.
-
Wenn ich ehrlich bin wäre ich schon glücklich wenn IPv6 wieder sauber laufen würde. Um dieser ganzen IPv6 Thematik etwas die Schärfe zu nehmen, habe ich von Anfang an einen Server in FFM gemietet, der sowohl über ein IPv4 und auch ein IPv6 Beinchen verfügt. Diesen habe ich dann mittels VPN angebunden bzw. einen Reverse Proxy aufgesetzt mit dem ich auf einige Services @ Home zugreife. Das funktioniert nur leider nicht sauber ohne IPv6 RA bzw. öffentliche IPv6 Adressen im LAN.
-
Und mit DS-Lite auch keine wirklich einfache Möglichkeit einen Tunnel anzubinden… :/
-
Und mit DS-Lite auch keine wirklich einfache Möglichkeit einen Tunnel anzubinden… :/
Stimmt! Nicht einfach aber machbar. Aber auch hier war immer wieder das Problem das die IPv6 Suffixe bei mir häufig (in unregelmäßigen Abständen) gewechselt haben. Davon mal abgesehen hat UM wohl an irgend einem Punkt bemerkt, dass ein /56 ein wenig groß für Heimanwender ist. Naja ... das aktuelle /59 ist immer noch recht groß für Heimanwender ... besonders wenn man bedenkt, dass man alle Hosts der 32 /64 Netze an den TC7200 Router anschließen muss, da dieser ja keine RAs sendet ;-)
-
/59? Echt? Also /60 kann ich verstehen. /56 auch. Aber /59? Bist du da sicher? Das würde so überhaupt in kein Schema passen und sich auch in Hardware so nicht gut abbilden lassen.
-
/59? Echt? Also /60 kann ich verstehen. /56 auch. Aber /59? Bist du da sicher? Das würde so überhaupt in kein Schema passen und sich auch in Hardware so nicht gut abbilden lassen.
Jau, so ist es. Hab eben nochmal kontrolliert. Das war aber am Ende schon bei meiner Fritzbox so. Anfangs gab´s ein /56 dann funktionierte irgendwann mein VPN/Reverse Konstrukt einen Morgen nicht mehr und siehe da … UM hat den IP Bereich gewechselt und auch das Präfix verkleinert.
Falls Du es nicht glaubst, schicke ich Dir gerne einen Screenshot ;)
-
Es scheint ja doch noch Wunder zu geben. Da stehe ich heute auf und bekomme von meinem Rechner mitgeteilt, dass er eine 2a02:908:AAAA:BBBB::/64 Adresse bekommen hat. Weder mein TC7200 Router noch meine pfSense FW wurde neu gestartet.
Nun habe ich aber ein anderes Problem. Im Logfile der pfSense bekomme ich zwei Fehlermeldungungen unter Status > System Logs > Routing angezeigt. Eine der beiden Fehler ist "pfsense IPv6 forwarding setting is: 0, should be 1". Von meiner IPv6 Adresse meines Rechner kann ich IPv6 Ziele im Internet (z.B. Google) nicht anpingen. FW Regeln und Routing stimmt.
Hat irgendwer ne Idee was das für ein Fehler sein kann und wie man ihn los wird?
Frohes Neues!
LG
-
Falls Du es nicht glaubst, schicke ich Dir gerne einen Screenshot ;)
Mein Unglauben bestand lediglich in der Größe der Maske die eben für die Verteilung absolut keinen Sinn macht ;) Aber naja… Provider eben :)
Nun habe ich aber ein anderes Problem. Im Logfile der pfSense bekomme ich zwei Fehlermeldungungen unter Status > System Logs > Routing angezeigt. Eine der beiden Fehler ist "pfsense IPv6 forwarding setting is: 0, should be 1".
Hast du in den Advanced Settings der pfSense generell IPv6 auf aktiv geschaltet? Und auch ein ordentliches v6 Gateway? Sonst routet da nichts :)
-
Hi JeGr,
wir chatten ja schon fast miteinander hier im Forum :-)
Hast du in den Advanced Settings der pfSense generell IPv6 auf aktiv geschaltet? Und auch ein ordentliches v6 Gateway? Sonst routet da nichts :)
Die IPv6 Settings sind an. Allerdings steht das WAN Interface derzeit bei IPv4 und IPv6 auf DHCP. Das WAN IF hat eine öffentliche IPv6 Adresse, im Routing ist aber zu sehen, dass die IPv6 Default Route zu der Autoconfig IP des TC7200 zeigt (fe80::8af7:c7ff:AAAA:BBBB). Kann das Problem an der DHCP Einstellung des WAN IFs liegen? Ich habe nämlich ebenfalls bemerkt, dass sich alle paar Minuten meine VPN Tunnel (IPSec und OpenVPN) neu aufbauen. Im Log ist dann folgendes zu sehen:
Jan 2 23:58:19 php: rc.newwanipv6: pfSense package system has detected an ip change -> 2a02:908:e882:6fe0:20d:AAAA:BBBB:CCCC … Restarting packages.
Jan 2 23:58:19 php: rc.start_packages: Restarting/Starting all packages.
Jan 2 23:58:25 kernel: ovpnc1: link state changed to UP
Jan 2 23:58:25 check_reload_status: rc.newwanip starting ovpnc1
Jan 2 23:58:28 php: rc.newwanip: rc.newwanip: Informational is starting ovpnc1.
Jan 2 23:58:28 php: rc.newwanip: rc.newwanip: on (IP address: 10.XXX.XXX.XXX) (interface: OV_OFFICE[opt1]) (real interface: ovpnc1).
Jan 2 23:58:28 php: rc.newwanip: Removing static route for monitor fe80::8af7:c7ff:AAAA:BBBB%re2 and adding a new route through fe80::8af7:c7ff:AAAA:BBBB
Jan 2 23:58:28 php: rc.newwanip: Ignoring IPsec racoon daemon reload since there are no tunnels on interface opt1
Jan 2 23:58:28 php: rc.newwanip: Creating rrd update script
Jan 2 23:58:30 php: rc.newwanip: pfSense package system has detected an ip change 10.XXX.XXX.5 -> 10.XXX.XXX.5 … Restarting packages.Interessant ist, dass pfSense ein IP change von IP A zu IP A feststellt. Es gibt also keinen IP change. Ich habe irgendwie im Gefühl, dass dieser Fehler mit den Lease times des DHCP zu tun hat, oder?
-
Interessant ist, dass pfSense ein IP change von IP A zu IP A feststellt. Es gibt also keinen IP change. Ich habe irgendwie im Gefühl, dass dieser Fehler mit den Lease times des DHCP zu tun hat, oder?
Nein, die pfSense hat mehrere Mechanismen, die einen Reconnect auslösen. Bspw. auch die Gateway Detection. Es könnte also auch sein, dass du im Log bei APinger (Gateways) ein GW down hast/hattest, dann wird bspw. auch das rc.newwanip ausgelöst. Ansonsten ist das allerdings schwer zu sagen, was genau das Ganze ausgelöst hat. Meistens war es in der Vergangenheit so - wenn sich die IP nicht geändert hat - dass es am Gateway Ping oder an Latenz lag. Dabei muss sich die IP nicht ändern (bspw. Kabelanschluß), trotzdem verliert er kurz das GW und macht dann sicherheitshalber ein State Kill. Da müsstest du erstmal genau eruieren, woher der Reconnect kommt.
Grüße
-
Ich glaube, Du hast recht. Der APinger Dienst hat immer irgendwas gemeldet:
apinger: Could not bind socket on address(10.XXX.XXX.2) for monitoring address 10.XXX.XXX.1(OV_OFFICE_VPNV4) with error Can't assign requested address
Ich habe den Monitoring Dienst nun auf allen Gateways deaktivert. Geholfen hat es leider nicht, da alle 15 Minuten der Tunnel immernoch down geht. Hast Du vielleicht noch eine Idee?
LG
-
Ich habe den Monitoring Dienst nun auf allen Gateways deaktivert.
Das meldende Organ zu deaktivieren, wenn es ein Problem gibt, bringt dann vielleicht nicht ganz so viel ;) Da apinger anscheinend ein Problem mit dem Binding hat, ggf. einfach mal neustarten. Sollte so nicht vorkommen. Da scheint eine Route/Gateway zu einem VPN mucken zu machen und nicht sauber zu antworten.
Grüße Jens
-
Das meldende Organ zu deaktivieren, wenn es ein Problem gibt, bringt dann vielleicht nicht ganz so viel ;)
Hab ich auch bemerkt ;) Das Problem gelöst habe ich noch nicht, aber weiter eingekreist habe ich es. Da UM mir mittlerweile eine Umstellung auf native IPv4 angeboten hat, habe ich IPv6 in der WebUI wieder deaktiviert und das Problem mit den VPNs ist weg.
Nun ist mir aber was anderes aufgefallen. (Ich weiß, ich bin anstrengend)
Ich mache über OpenVPN und IPSec u.a. DNS, RDP, HTTP, HTTPS, und noch ein paar andere Sachen. Ich kann keine HTTPS Services von meinem Rechner durch den VPN Tunnel (ob OpenVPN oder IPSec ist egal) erreichen. Genauso kann ich z.B. einen Webserver mittels HTTP erreichen, ein Download von diesem Server ist aber nicht möglich. Entsprechende FW Regeln sind vorhanden.
Hast Du auch hierzu eine Lösung parat? :-)
LG
Nachtrag 18:26:
Mittels Packet Capture habe ich gesehen, dass nach der Initiierung der Verbindung nur noch TCP Retransmissions folgen. Ich habe hier im Forum einmal gesucht und habe festgestellt, dass wohl mehrere User das gleiche Problem haben. :(
-
Das kommt mir bekannt vor. Hast du die MTU angepaßt?
https://forum.pfsense.org/index.php?topic=82781.msg453215#msg453215
-
Hi,
Das kommt mir bekannt vor. Hast du die MTU angepaßt?
Ja, das war das erste was ich gemacht hab. Runter bis 1300. Nichts hat geholfen. Zumindest beim OpenVPN konnte ich das machen. Bei meinem IPSec Tunnel, der den selben Fehler aufweist habe ich bis jetzt keine Möglichkeit gefunden die MTU size einzustellen.
Vielleicht habe ich aber auch etwas übersehen. Welche MTU size hast Du denn wo eingestellt?
LG
-
Ich hab bei OpenVPN "link-mtu 1432;" gesetzt, IpSec nutze ich nicht. Da dein Wert erheblich niedriger ist, wird es dann wohl vermutlich daran leider nicht liegen.
-
Hi iam,
Ich hab bei OpenVPN "link-mtu 1432;" gesetzt, IpSec nutze ich nicht.
Ich glaube ich hatte da einen Denkfehler. Ich habe die MTU Size auf dem OpenVPN Interface gesetzt und auch den Parameter tun-mtu benutzt. Dem Parameter link-mtu habe ich weniger Aufmerksamkeit geschenkt.
Auf jeden Fall funktioniert der Zugriff nun mit Deinen Werten. Vielen Dank! Jetzt müsste ich nur noch in Erfahrung bringen, wie man die MTU size bei IPSec Tunnel ändern kann.
LG
-
Hm das ist seltsam. Der Unterschied zwischen den Parametern ist ja eigentlich nur, daß OpenVPN den Overhead des Tunnels bei link-mtu selbst berechnet. Und so groß sollte der ja eigentlich nicht sein. Aber freut mich, daß es jetzt klappt.
Wegen IpSec schau mal hier.
