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!

Und ich kann für euch beide noch ergänzen: ;)

Wenn bspw. der DHCP Server währenddessen neu geladen/gestartet wird, liest er ggf. sein aktuelles Lease File wieder ein und bedient weiter. Ist aber ein Client aus dem Lease File raus, kann man damit durchaus provozieren, dass er eine andere Adresse bekommt.

Das Verhalten macht aus deshalb Sinn, da pfSense bzw. DHCP Server allgemein, diese dynamischen IPs trotzdem mit einem DNS Namen ausstatten können und bei gleicher Belegung der Eintrag im DNS Resolver nicht verändert werden muss.

Besser spät als nie:

Vielen Dank - hat prächtig funktioniert.

Vielen Dank. Dann sehe ich das:

root  21441  22.3  1.2 82728 24356 u0- R    Sun10PM  294:55.38 /usr/local/bin/php -f /usr/local/bin/3gstats.php cuaU0.2 opt3

Das ist ein teil meines 3G USB Sticks. Ich nutze für 3G jedoch cuaU0.0. Das cuaU0.2 sollte eigentlich inaktiv sein. Was kann ich machen?

In den RRD Logs sehe ich zudem, dass das Problem erst auftritt wenn in dne Syslogs folgendes steht:

php-fpm[28692]: /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.

Was sagt mir das? Vermutlich weil die IP des 3G Interface gewechselt hat und ich bei IPSec als Gateway meine Failover Group angegeben habe? Werde mal nur WAN auswählen und testen.

Hallo Andreas,

Du wirst in der pfSense wohl auch zwei Gateways haben und vermutlich WAN0 Default.

Du benötigst eine Firewall Regel auf der LAN Seite:
Alle Anfragen von 192.168.111.10 an !LAN_NET (192.168.111.0/24)
Weiter unten bei 'Advanced Features' kannst Du bei dem Eintrag Gateway WAN1 auswählen.
Somit sollten alle Anfragen von 192.168.111.10 über das Gateway WAN1 geschickt werden.

Gruß

Libor

Ist gelöst !

Einfach unter erweiterten IPsec Einstellungen entweder einfach nur speichern drücken oder die Loglevels einfach mal ändern, speichern und wieder auf silent stellen.

Danach bleibt mein Log leer.

Danke fürs lesen ;)

Habs jetzt auch über die GUI hinbekommen. Ich war anfangs etwas verwirrt, da man für jede Route ein Gateway (das es für das 2. Subnetz so eigentlich nicht gibt) angeben muss. Für meinen Fall muss ich einfach ein zusätzliches Gateway mit der IP des LAN-IF definieren, das dann als GW für das 2. Subnetz ausgewählt wird. So bleiben alle 6 IPs des 2. Subnetzes frei.