IPv6 Prefix im LAN ohne RA vom ISP
-
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.
-
Danke für den Link. Von meinem Netz aus kann ich nun ohne Probleme auf Webserver am anderen Ende des Tunnels zugreifen. Andersrum funktioniert es allerdings nicht. Zum Beispiel ist es nicht möglich auf das WebUI der PfSense oder eines NAS hier vor Ort zu zugreifen.
Kann das sein, das das Clamping nur in eine Richtung funktioniert?
LG
-
Du mußt das schon bei beiden Seiten eintragen glaube ich. Hab ich bei mir jedenfalls gemacht.
-
Auf der anderen Seite kann ich es leider nicht eintragen. Bei meiner alten FW habe ich den VPN Tunnel an ein Interface gebunden und in den Einstellungen des Interfaces die MTU Size eingestellt. Das hat in beide Richtungen funktioniert. Mir fällt spontan auch keine andere Möglichkeit ein, bei der PfSense bzgl. MTU noch etwas einzustellen.
Wie schaut´s bei Dir aus?
LG
-
Ich setze wie gesagt kein IPSec ein. Bei OpenVPN hab ich halt bei beiden Seiten den Parametern über die erweiterte Konfiguration gesetzt.
Wieso geht das bei dir mit IpSec nicht?
-
Wieso geht das bei dir mit IpSec nicht?
Wie gesagt. Verbindungen die von meinem Netz in das Netz hinter dem IPSec VPN Tunnel initiiert werden funktionieren nun nachdem ich die von von Dir empfohlenen Einstellungen vorgenommen habe. Nur andersrum funktioniert es nicht. Auf der anderen Seite steht ein großer Firewall Cluster mit virtuellen Instanzen (was Hersteller eigenes … kein VMWare oder so). Die VPN Instanz, auf der alle VPN Verbindungen terminieren, ist ebenfalls virtuell. Das Problem ist nun, dass ich zwar die MTU bei Tunnel interfaces bei dem Firewall Cluster anpassen kann, allerdings nur dann wenn die Firewall nicht virtuell ist. Bestimmte Einstellungen lassen sich halt in den virtuellen Instanzen nicht vornehmen, sondern setzen eine "physikalische Instanz" voraus. Daher kann ich die MTU size nur auf meiner Seite einstellen.
LG
-
Na dann würde ich mich mal an den Anbieter wenden.
-
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 :-)