pfSense an Stadtwerke NMS statt FritzBox

24unix

@jegr said in pfSense an Stadtwerke NMS statt FritzBox:

@24unix

Hallo Jens, erst mal danke für die Antwort.

Ich würde weils um IPv6 geht erstmal

Auf 2.5 Snapshots updaten. Wenn du eh noch am Experimentieren bist und noch kaum was fix eingerichtet hast, sollten auch die 2.5er kein Problem für dich sein. Die laufen eigentlich recht stabil

OK, das kann ich gerne gleich mal probieren sobald meine Frau Feierabend macht.

Die ganzen IPv6 Adv. Options weglassen, von denen du nur vermutest, dass sie irgendwas tun. Das macht keinen Sinn. Entweder man weiß es oder nicht, aber einfach auf verdacht die zu setzen weil ähnlich würde ich lassen, gerade bei IPv6.

Da habe ich halt gemacht, weil so ziemlich di einzige Ansage vn SWN ist, dass man RA verwenden muss.

Du fragst dich warum dein WAN keine v6 hast, hattest aber den Haken bei "Request only prefix" drin - macht also kein Sinn sich dann zu wundern ;)

Ich habe mittlerweile nahezu alle Kombinationen durch.
Sicher 20 mal mit und ohne das Häkchen getestet.

Do not wait for a RA IST rapid commit. Das dann via adv. options manuell reinzuschreiben, macht auch so keinen Sinn.

OK, danke, das ist eine sehr hilfreiche Info.

Ansonsten bei Änderungen am DHCP6 auf dem WAN macht es immer Sinn, kurz das Interface zu disablen und enablen also aus und an zu triggern, da ansonsten die Dienste wie radvd für v6 ggf. nicht neugestartet werden oder/und nur neu geladen. Das bringt dann gerade für den Refresh bei IPv6 nichts. Zudem MUSS mind. ein LAN Interface auf Track Interface WAN stehen, ansonsten wird die Config (zumindest bei 2.4.x noch) ggf. unvollständig geschrieben und kein Prefix angefordert, da keines benötigt wird.

OK, Track Interface ist bei LAN und DMZ gesetzt.

Hoffe das hilft dann erstmal weiter. Generell würde ich das genauso handhaben wie die anderen schon in den Tipps geschrieben haben: IPv6 mit so wenig Optionen wie möglich "Default" konfigurieren und nicht gleich weil ähnlich wie irgendwas gleich mit Optionen um mich werfen :) Gerade bei bspw. 2.5 neu installiert hatte ich an einer FB mit IP6 PD bspw. gar keine Änderungen benötigt um IPv6 auf dem WAN zu bekommen. Und solang dein Provider auch nichts sagt, dass du keine IP6 aufm WAN bekommst (unüblich) ist das auch nonsense, da keine Public IP6 zu haben.

Laut einer Mail habe ich eine statisches Prefix, mehr weiß ich leider nicht.

Auf dem Zettel mit den Zugangsdaten standen Nutzername und Passwort, die Zeile mit IPv4 war leer, obwohl eine statische IPv4 zum Vertrag gehört, von IPv6 stand da gar nichts.

Cheers
\jens

Vielen Dank schon mal für Deine Hilfe, ich probiere gleich die 2.5

24unix

OK, er ist jetzt auf 2.5.0-DEVELOPMENT (amd64).

Hat 2 Durchläufe gebraucht, aber das ist wohl normal. Einmal überhaupt von Release auf Dev und dann auf 2.5

Unter 2.5 scheint es den vlog Befehl nicht mehr zu geben. Scheinen jetzt plain ASCII files zu sein.

Ich habe jetzt alles an IPv6 deaktiviert was wohl nicht gebraucht wird.

Das WAN deaktiviert, neu aktiviert.

Leider, kein IPv6 :-(

So sieht die GUI aus:

Die config hat er generiert (obwohl ich den DNS vom Provider eh nicht nutzen will, aber das ist für den Moment egal)

 cat /var/etc/dhcp6c_wan.conf
interface pppoe0 {
	send ia-na 0;	# request stateful address
	send ia-pd 0;	# request prefix delegation
	request domain-name-servers;
	request domain-name;
	script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"; # we'd like nameservers and RTSOLD to do all the work
};
id-assoc na 0 { };
id-assoc pd 0 {
	prefix ::/56 infinity;
	prefix-interface igb0 {
		sla-id 153;
		sla-len 8;
	};
	prefix-interface igb2 {
		sla-id 9;
		sla-len 8;
	};
};

Und das sagt der dhcp6c:

Feb  1 17:47:04 heimdall dhcp6c[23201]: restarting
Feb  1 17:47:04 heimdall dhcp6c[23201]: reset a timer on pppoe0, state=INIT, timeo=0, retrans=256
Feb  1 17:47:05 heimdall dhcp6c[23201]: Sending Solicit
Feb  1 17:47:05 heimdall dhcp6c[23201]: a new XID (218a11) is generated
Feb  1 17:47:05 heimdall dhcp6c[23201]: set client ID (len 14)
Feb  1 17:47:05 heimdall dhcp6c[23201]: set identity association
Feb  1 17:47:05 heimdall dhcp6c[23201]: set elapsed time (len 2)
Feb  1 17:47:05 heimdall dhcp6c[23201]: set option request (len 4)
Feb  1 17:47:05 heimdall dhcp6c[23201]: set IA_PD prefix
Feb  1 17:47:05 heimdall dhcp6c[23201]: set IA_PD
Feb  1 17:47:05 heimdall dhcp6c[23201]: send solicit to ff02::1:2%pppoe0
Feb  1 17:47:05 heimdall dhcp6c[23201]: reset a timer on pppoe0, state=SOLICIT, timeo=0, retrans=1024
Feb  1 17:47:05 heimdall dhcp6c[23201]: receive advertise from fe80::d66d:50ff:fe4e:81d3%pppoe0 on pppoe0
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option server ID, len 10
Feb  1 17:47:05 heimdall dhcp6c[23201]:   DUID: 00:03:00:01:d4:6d:50:4e:86:d7
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option client ID, len 14
Feb  1 17:47:05 heimdall dhcp6c[23201]:   DUID: 00:01:00:01:21:b1:53:db:00:1a:8c:16:47:b0
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option identity association, len 18
Feb  1 17:47:05 heimdall dhcp6c[23201]:   IA_NA: ID=0, T1=0, T2=0
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option status code, len 2
Feb  1 17:47:05 heimdall dhcp6c[23201]:   status code: no addresses
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option IA_PD, len 41
Feb  1 17:47:05 heimdall dhcp6c[23201]:   IA_PD: ID=0, T1=172800, T2=276480
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option IA_PD prefix, len 25
Feb  1 17:47:05 heimdall dhcp6c[23201]:   IA_PD prefix: 2a03:7847:2252:100::/56 pltime=345600 vltime=345600
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option DNS, len 32
Feb  1 17:47:05 heimdall dhcp6c[23201]: get DHCP option domain search list, len 12
Feb  1 17:47:05 heimdall dhcp6c[23201]: server ID: 00:03:00:01:d4:6d:50:4e:86:d7, pref=-1
Feb  1 17:47:05 heimdall dhcp6c[23201]: reset timer for pppoe0 to 0.998135
Feb  1 17:47:06 heimdall dhcp6c[23201]: picked a server (ID: 00:03:00:01:d4:6d:50:4e:86:d7)
Feb  1 17:47:06 heimdall dhcp6c[23201]: Sending Request
Feb  1 17:47:06 heimdall dhcp6c[23201]: a new XID (3bed7b) is generated
Feb  1 17:47:06 heimdall dhcp6c[23201]: set client ID (len 14)
Feb  1 17:47:06 heimdall dhcp6c[23201]: set server ID (len 10)
Feb  1 17:47:06 heimdall dhcp6c[23201]: set status code
Feb  1 17:47:06 heimdall dhcp6c[23201]: set identity association
Feb  1 17:47:06 heimdall dhcp6c[23201]: set elapsed time (len 2)
Feb  1 17:47:06 heimdall dhcp6c[23201]: set option request (len 4)
Feb  1 17:47:06 heimdall dhcp6c[23201]: set IA_PD prefix
Feb  1 17:47:06 heimdall dhcp6c[23201]: set IA_PD
Feb  1 17:47:06 heimdall dhcp6c[23201]: send request to ff02::1:2%pppoe0
Feb  1 17:47:06 heimdall dhcp6c[23201]: reset a timer on pppoe0, state=REQUEST, timeo=0, retrans=955
Feb  1 17:47:06 heimdall dhcp6c[23201]: receive reply from fe80::d66d:50ff:fe4e:81d3%pppoe0 on pppoe0
Feb  1 17:47:06 heimdall dhcp6c[23201]: get DHCP option client ID, len 14
Feb  1 17:47:06 heimdall dhcp6c[23201]:   DUID: 00:01:00:01:21:b1:53:db:00:1a:8c:16:47:b0
Feb  1 17:47:06 heimdall dhcp6c[23201]: get DHCP option server ID, len 10
Feb  1 17:47:06 heimdall dhcp6c[23201]:   DUID: 00:03:00:01:d4:6d:50:4e:86:d7
Feb  1 17:47:06 heimdall dhcp6c[23201]: get DHCP option status code, len 2
Feb  1 17:47:06 heimdall dhcp6c[23201]:   status code: no binding
Feb  1 17:47:06 heimdall dhcp6c[23201]: dhcp6c Received REQUEST
Feb  1 17:47:06 heimdall dhcp6c[23201]: status code: no binding
Feb  1 17:47:06 heimdall dhcp6c[23201]: executes /var/etc/dhcp6c_wan_dhcp6withoutra_script.sh
Feb  1 17:47:08 heimdall dhcp6c[69487]: dhcp6c REQUEST on pppoe0 - running rtsold
Feb  1 17:47:08 heimdall dhcp6c[23201]: script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh" terminated
Feb  1 17:47:08 heimdall dhcp6c[23201]: removing an event on pppoe0, state=REQUEST
Feb  1 17:47:08 heimdall dhcp6c[23201]: removing server (ID: 00:03:00:01:d4:6d:50:4e:86:d7)
Feb  1 17:47:08 heimdall dhcp6c[23201]: got an expected reply, sleeping.

JeGr

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Unter 2.5 scheint es den vlog Befehl nicht mehr zu geben. Scheinen jetzt plain ASCII files zu sein.

clog. Und ja eines der Features - hurra - von 2.5 ist diese unnötigen zyklischen Logfiles abzuschaffen :)

Die config hat er generiert (obwohl ich den DNS vom Provider eh nicht nutzen will, aber das ist für den Moment egal)

Die Konfiguration sieht aber nicht so verkehrt aus.

Aber:

Laut einer Mail habe ich eine statisches Prefix, mehr weiß ich leider nicht.

Kannst du das ggf. verifizieren lassen und dir das korrekte IPv6 Netz nennen lassen?

Denn aus deinen Logs taucht da ja immer wieder das 2a03:7847:2252:100::/56 auf. Wenn das EH statisch auf deinem Anschluß anliegt, dann wäre die Frage ob es nicht genügt auf dem WAN schlicht mal zum Test bspw.

2a03:7847:2252:100::1/64

als IP6 statisch zu konfigurieren und als Default Route (weil nichts anderes angegeben) einfach mal mit fe80::1 zu versuchen. Und dann versuchen, ob das nach draußen kommt bzw. man von außen aus die konfigurierte IP6 erreicht (bzw. die Pakete auf der Sense sehen kann).

24unix

@jegr said in pfSense an Stadtwerke NMS statt FritzBox:

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Unter 2.5 scheint es den vlog Befehl nicht mehr zu geben. Scheinen jetzt plain ASCII files zu sein.

clog. Und ja eines der Features - hurra - von 2.5 ist diese unnötigen zyklischen Logfiles abzuschaffen :)

Öh, ja, clog, habe es in den letzen Tagen oft genug getippt …

Die config hat er generiert (obwohl ich den DNS vom Provider eh nicht nutzen will, aber das ist für den Moment egal)

Die Konfiguration sieht aber nicht so verkehrt aus.

Aber:

Laut einer Mail habe ich eine statisches Prefix, mehr weiß ich leider nicht.

Kannst du das ggf. verifizieren lassen und dir das korrekte IPv6 Netz nennen lassen?

Leider sehr schwierig. Ich habe denen vor drei Tagen eine Mail an den Support geschickt, leider noch keine Antwort.
Bei der Hotline wartet man 30 bis 90 Minuten, 1x haben ich nach 2 Stunden 30 Minuten aufgegeben …
Und wenn man jemanden erreicht wissen die meistens gar nichts.

Denn aus deinen Logs taucht da ja immer wieder das 2a03:7847:2252:100::/56 auf. Wenn das EH statisch auf deinem Anschluß anliegt, dann wäre die Frage ob es nicht genügt auf dem WAN schlicht mal zum Test bspw.

2a03:7847:2252:100::1/64

als IP6 statisch zu konfigurieren und als Default Route (weil nichts anderes angegeben) einfach mal mit fe80::1 zu versuchen. Und dann versuchen, ob das nach draußen kommt bzw. man von außen aus die konfigurierte IP6 erreicht (bzw. die Pakete auf der Sense sehen kann).

Du wirst lachen, das habe ich schon probiert. Nach dem Motto, bei DHCPv4 würde es ja auch funktionieren wenn ich eine statische lease statisch statt per DHCP vergebe.

Nur an der Route bin ich wohl gescheitert, habe nicht wirklich viel Erfahrung mit FreeBSD, kann Du mir einen Hint geben, wie ich die Route setze? Dann probiere ich es gerne noch mal.

24unix

Der erste Versuch war ein griff ins Klo, er bekam nicht mal mehr IPv4, keine Erregung mehr beim PPP.

Backup eingespielt, das klappte zum Glück, aber, als Zwischenbaustelle habe ich vor dem Neustart gesehen, dass ein FS überläuft.

Auch nach dem Neustart noch, auch in der GUI zu sehen:

Dem /var sollte ich wohl dringend etwas mehr Luft verpassen, aber wie?

~~In der fstab taucht das nicht auf.~~

Habe es in der GUI gefunden, System -> Advanced -> Misc

Habe /tmp und /var nun je 256MB gegeben.

So sieht es nun aus:

Aber, ich von aussen komme ich nicht drauf.

╰─➤  traceroute -6 2a03:7847:2252:100:1::1
traceroute to 2a03:7847:2252:100:1::1 (2a03:7847:2252:100:1::1), 30 hops max, 80 byte packets
 1  2a01:4f8:161:12cd::2 (2a01:4f8:161:12cd::2)  0.102 ms  0.119 ms  0.121 ms
 2  ex9k1.dc7.fsn1.hetzner.com (2a01:4f8::a:16:a)  0.400 ms  0.421 ms  0.430 ms
 3  core23.fsn1.hetzner.com (2a01:4f8:0:3::271)  24.925 ms  24.899 ms *
 4  core4.fra.hetzner.com (2a01:4f8:0:3::1b9)  20.762 ms core4.fra.hetzner.com (2a01:4f8:0:3::365)  5.051 ms *
 5  * * *
 6  * * *

das geht so weiter bis 30 …

24unix

So, ein Update.

Ich habe heute erneut eine Mail an den Support geschrieben, ohne wirklich Hoffnung auf eine zeitnahe Antwort, da meine Mail vom 28.1 noch nicht beantwortet wurde.

Jetzt klingelte gerade meine Telefon (obwohl ich es immer auf bitte nicht stören habe, er hat es wohl 2x hintereinander versucht, dann geht es durch).

Sie verwenden DHCP6, aber mit einen /64 und einem /56 Präfix.

2a03:7847:2252:100::/64
2a03:7847:2252::/56

Nur, wie mache ich das nun der pfSense klar?

24unix

Bin aus dem Edit-fenster raus, sorry.

Das habe ich im Moment:

Ping auf Gateway geht:

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::d66d:50ff:fe4e:81d3%pppoe0 UGS   pppoe0
::1                               link#5                        UH          lo0
fe80::%igb0/64                    link#1                        U          igb0
fe80::1:1%igb0                    link#1                        UHS         lo0
fe80::20d:b9ff:fe4c:5324%igb0     link#1                        UHS         lo0
fe80::%igb1/64                    link#2                        U          igb1
fe80::20d:b9ff:fe4c:5325%igb1     link#2                        UHS         lo0
fe80::%igb2/64                    link#3                        U          igb2
fe80::20d:b9ff:fe4c:5326%igb2     link#3                        UHS         lo0
fe80::%lo0/64                     link#5                        U           lo0
fe80::1%lo0                       link#5                        UHS         lo0
fe80::%pppoe0/64                  link#8                        U        pppoe0
fe80::185:12:88:130%pppoe0        link#8                        UHS         lo0
fe80::20d:b9ff:fe4c:5324%pppoe0   link#8                        UHS         lo0
[2.5.0-DEVELOPMENT][admin@heimdall.lab.24unix.net]/root: ping6 fe80::d66d:50ff:fe4e:81d3
PING6(56=40+8+8 bytes) fe80::20d:b9ff:fe4c:5324%pppoe0 --> fe80::d66d:50ff:fe4e:81d3
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=0 hlim=64 time=1.108 ms
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=1 hlim=64 time=1.423 ms
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=2 hlim=64 time=1.068 ms
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=3 hlim=64 time=0.932 ms
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=4 hlim=64 time=0.902 ms
16 bytes from fe80::d66d:50ff:fe4e:81d3%pppoe0, icmp_seq=5 hlim=64 time=0.681 ms
^C
--- fe80::d66d:50ff:fe4e:81d3 ping6 statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.681/1.019/1.423/0.227 ms
[2.5.0-DEVELOPMENT][admin@heimdall.lab.24unix.net]/root: ping6 google.com
PING6(56=40+8+8 bytes) fe80::20d:b9ff:fe4c:5324%pppoe0 --> 2a00:1450:4005:803::200e

Aber mehr auch nicht, und LAN holt sich keine IP.

Das kommt, wenn ich in dem Zustand LAN neustarte:

Feb  3 18:25:17 heimdall dhcp6c[44306]: Sending Request
Feb  3 18:25:17 heimdall dhcp6c[44306]: dhcp6c Received REQUEST
Feb  3 18:25:17 heimdall dhcp6c[44306]: status code: no binding

24unix

Die Schildkröte paddelt :)

Ich dokumentiere das noch …

Aber erst mal tun sich für morgen noch ein paar Fragen auf.

JeGr

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Habe /tmp und /var nun je 256MB gegeben.

Warum hast du denn RAM Disk überhaupt angemacht?

Sie verwenden DHCP6, aber mit einen /64 und einem /56 Präfix.

2a03:7847:2252:/64

2a03:7847:2252::/56

Hö? Die nehmen sich selbst bzw. dir einfach nen /64 aus deinem Netz raus und nutzen das für die Verbindung? Was haben die denn geraucht? Narf

OK du hast jetzt mit fe80:: ne Verbindung hinbekommen? Geht da tatsächlich was drüber? Oder nur bis zum Gateway und dann ist vorbei?

Wenn du dir jetzt einfach mal als Test 2a03:7847:2252:100::1/64 als Virtual IP Alias auf das WAN klebst, kannst du dann ggf. was raussenden bzw. von außen die 2a03:7847:2252:100::1 erreichen (dass es zumindest als Block im Log auftaucht)?

Ansonsten wenn man mit fe80:: Methode nicht weiterkommt, weil die sonst das Routing nicht hinbekommen: Eventuell DHCP6 mit /56er PD testen, dann müsstest du ggf. auf dem WAN ja mal irgendwann eine 2a03:7847:2252:100:xyz bekommen und dann sollte zumindest ein Ping6 vom WAN aus gehen. Wenn man so weit ist, könnte man ggf. weitersehen, ob sie es dann hinbekommen, dass der Rest des /56 automatisch zu dir geroutet wird. Wenn ja, müsstest du ab dem Zeitpunkt theoretisch von außen auch Blocks für andere Prefixbereiche sehen und wenn das statisch ist, müsste man sie theoretisch intern einfach auflegen können.

24unix

@jegr said in pfSense an Stadtwerke NMS statt FritzBox:

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Habe /tmp und /var nun je 256MB gegeben.

Warum hast du denn RAM Disk überhaupt angemacht?

Wurde mir wahrscheinlich bei der Erstinstallation angeboten, finde ich aber OK, schont die SSD.

Ich habe 4GB RAM, da kann ich die ja auch ruhig nutzen.

Ich finde, das sieht OK aus:

Sie verwenden DHCP6, aber mit einen /64 und einem /56 Präfix.

2a03:7847:2252:/64

2a03:7847:2252::/56

Hö? Die nehmen sich selbst bzw. dir einfach nen /64 aus deinem Netz raus und nutzen das für die Verbindung? Was haben die denn geraucht? Narf

Tja, keine Ahnung, war bei der Telekom ähnlich, nur war das /64 aus einem anderem Bereich.

OK du hast jetzt mit fe80:: ne Verbindung hinbekommen? Geht da tatsächlich was drüber? Oder nur bis zum Gateway und dann ist vorbei?

Ja, das klappt, wie geschrieben die Schildkröte paddelt (Kame), ipv6-test 19/20 Punkten (Mein Hostname hat noch kein DNS Eintrag).

Wenn du dir jetzt einfach mal als Test 2a03:7847:2252:100::1/64 als Virtual IP Alias auf das WAN klebst, kannst du dann ggf. was raussenden bzw. von außen die 2a03:7847:2252:100::1 erreichen (dass es zumindest als Block im Log auftaucht)?

Ansonsten wenn man mit fe80:: Methode nicht weiterkommt, weil die sonst das Routing nicht hinbekommen: Eventuell DHCP6 mit /56er PD testen, dann müsstest du ggf. auf dem WAN ja mal irgendwann eine 2a03:7847:2252:100:xyz bekommen und dann sollte zumindest ein Ping6 vom WAN aus gehen. Wenn man so weit ist, könnte man ggf. weitersehen, ob sie es dann hinbekommen, dass der Rest des /56 automatisch zu dir geroutet wird. Wenn ja, müsstest du ab dem Zeitpunkt theoretisch von außen auch Blocks für andere Prefixbereiche sehen und wenn das statisch ist, müsste man sie theoretisch intern einfach auflegen können.

Also, surfen geht, das sieht soweit alles gut aus, was mich wundert:
Einstellung für LAN IPv6:

aber:

Müsste der nicht 2252:99 statt 199 haben?

DMZ (eigentlich ein Bastion Host) bekommt keine IPv6, obwohl identisch konfiguriert wie LAN, nur mit anderer Prefix ID.

JeGr

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Wurde mir wahrscheinlich bei der Erstinstallation angeboten, finde ich aber OK, schont die SSD.

Hmm wüsste nicht dass das im Installer irgendwo noch angeboten wird. Die SSD schont das auch nur marginal. Ich hab bei halbwegs normalgroßen SSDs (also 32-64GB und größer) in 4-5 Jahren jetzt auch noch keine einzige verloren weil sie "kaputtgeschrieben" wurde. Das ist IMHO ein ziemlicher Mythos, da pfSense so "klein" ist auf der SSD, dass - wenn man kein anderes Monster Package installiert hat, das entsprechenden Platz oder Logplatz braucht - es nicht vorkommt, dass die SSD aufgibt. Mit ~2-3GB "use" bei 32GB schafft es jedes wear-leveling da in Jahren nicht an die Grenzen zu kommen :)

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Tja, keine Ahnung, war bei der Telekom ähnlich, nur war das /64 aus einem anderem Bereich.

Genau das ist der Punkt. Normalerweise nimmt der Provider ein anderes /64er und routet da dann das /56er drauf. Aber aus dem /56er selbst einen Range schon "auszuschneiden" und dem Kunden damit das Prefixing kaputt zu machen, finde ich schon sehr fragwürdig. Wenn schon - und es auch noch statisch ist - hätte ich den Kunden dann wenigstens gefragt wo man es draufrouten soll, damit ich ihm die Netzplanung nicht kaputt mache.

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Müsste der nicht 2252:99 statt 199 haben?

Ich denke nicht, denn es wird sich wohl an der doofen :0100: vom Provider orientiert. Aber wie das Tracking rechnet ist mir da auch nicht ganz klar, das kommt immer drauf an, was man vom ISP per DHCP bekommt.

Ist denn das WAN jetzt auf DHCP6 oder einfach nur statisch mit fe80:: konfiguriert?

Ist die DMZ ein anderer NIC oder eine schlechte Verbindung? Weil da 100 steht und nicht 1000? Eventuell könnte sonst das NIC o.ä. ein Problem haben.

Ist wie gesagt dann nur mit statischem Prefix dann schade trotzdem Tracking nutzen zu müssen und nicht einfach ordentlich auflegen zu können, deshalb würde ich ggf. versuchen ob man da ggf. was reißen kann.

Bei Telekom Static IP6 prefix ists IMHO so, dass man per DHCP6 dann ein fixes statisches /64er bekommt und man dann dort drauf automatisch auch das /56er Prefix hingeroutet bekommt. Funktioniert bei einem unserer Kunden so. Man kann dann testweise Adressen des /56er als Alias auf die Firewall binden und bekommt auch sofort eine Anwort von außen. Die routen also wirklich tatsächlich sauber das Prefix durch auf die Adresse die man sich per DHCP6 holt.

Wäre schön wenn das in deinem Fall auch so wäre (oder man den ISP dahingehend bringen kann), damit könntest du dann auf LAN/DMZ einfach das Prefix statisch konfigurieren und es müsste gleich funktionieren :)

24unix

@jegr said in pfSense an Stadtwerke NMS statt FritzBox:

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Wurde mir wahrscheinlich bei der Erstinstallation angeboten, finde ich aber OK, schont die SSD.

Hmm wüsste nicht dass das im Installer irgendwo noch angeboten wird. Die SSD schont das auch nur marginal. Ich hab bei halbwegs normalgroßen SSDs (also 32-64GB und größer) in 4-5 Jahren jetzt auch noch keine einzige verloren weil sie "kaputtgeschrieben" wurde. Das ist IMHO ein ziemlicher Mythos, da pfSense so "klein" ist auf der SSD, dass - wenn man kein anderes Monster Package installiert hat, das entsprechenden Platz oder Logplatz braucht - es nicht vorkommt, dass die SSD aufgibt. Mit ~2-3GB "use" bei 32GB schafft es jedes wear-leveling da in Jahren nicht an die Grenzen zu kommen :)

Ja, aber schädlich ist es nun doch auch nicht, oder?

Großes kommt nicht drauf, wireguard haue ich auf einen Xen DomU in meinem LAN.

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Tja, keine Ahnung, war bei der Telekom ähnlich, nur war das /64 aus einem anderem Bereich.

Genau das ist der Punkt. Normalerweise nimmt der Provider ein anderes /64er und routet da dann das /56er drauf. Aber aus dem /56er selbst einen Range schon "auszuschneiden" und dem Kunden damit das Prefixing kaputt zu machen, finde ich schon sehr fragwürdig. Wenn schon - und es auch noch statisch ist - hätte ich den Kunden dann wenigstens gefragt wo man es draufrouten soll, damit ich ihm die Netzplanung nicht kaputt mache.

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Müsste der nicht 2252:99 statt 199 haben?

Ich denke nicht, denn es wird sich wohl an der doofen :0100: vom Provider orientiert. Aber wie das Tracking rechnet ist mir da auch nicht ganz klar, das kommt immer drauf an, was man vom ISP per DHCP bekommt.

Ah, OK; da kann ich ja noch mal rumprobieren.
Ich bin froh, dass es erst einmal läuft, aber ich will es halt auch so sauber wie möglich machen.

Ist denn das WAN jetzt auf DHCP6 oder einfach nur statisch mit fe80:: konfiguriert?

DHCP6

Ist die DMZ ein anderer NIC oder eine schlechte Verbindung? Weil da 100 steht und nicht 1000? Eventuell könnte sonst das NIC o.ä. ein Problem haben.

Auf der Gegenseite ist nur ein Raspi.

Ist wie gesagt dann nur mit statischem Prefix dann schade trotzdem Tracking nutzen zu müssen und nicht einfach ordentlich auflegen zu können, deshalb würde ich ggf. versuchen ob man da ggf. was reißen kann.

Ich kann versuchen, dass dem Support noch mal zu schildern.

Bei Telekom Static IP6 prefix ists IMHO so, dass man per DHCP6 dann ein fixes statisches /64er bekommt und man dann dort drauf automatisch auch das /56er Prefix hingeroutet bekommt. Funktioniert bei einem unserer Kunden so. Man kann dann testweise Adressen des /56er als Alias auf die Firewall binden und bekommt auch sofort eine Anwort von außen. Die routen also wirklich tatsächlich sauber das Prefix durch auf die Adresse die man sich per DHCP6 holt.

Ich bin mir auch nicht ganz sicher, was die bei SWN zaubern.

Von aussen (Hetzner) kann ich per IPv4 und IPv6 auf die pfSense pingen, aber traceroute hört bei beiden Protokollen nach 6 Hops auf.

╰─➤  traceroute 89.57.34.82
traceroute to 89.57.34.82 (89.57.34.82), 30 hops max, 60 byte packets
 1  dreadnought.24unix.net (5.9.30.194)  0.096 ms  0.100 ms  0.080 ms
 2  static.193.30.9.5.clients.your-server.de (5.9.30.193)  0.424 ms  0.360 ms  0.329 ms
 3  * * core24.fsn1.hetzner.com (213.239.229.237)  5.520 ms
 4  core4.fra.hetzner.com (213.239.229.73)  5.107 ms core4.fra.hetzner.com (213.239.203.149)  4.843 ms core4.fra.hetzner.com (213.239.229.73)  5.044 ms
 5  ipv4.de-cix.fra.de.as207790.stadtwerke-neumuenster.de (80.81.193.74)  13.571 ms  13.544 ms  13.513 ms
 6  185.12.88.210 (185.12.88.210)  14.926 ms  14.897 ms  14.865 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *

╰─➤  traceroute 2a03:7847:2252:199:20d:b9ff:fe4c:5324                                                                      130 ↵
traceroute to 2a03:7847:2252:199:20d:b9ff:fe4c:5324 (2a03:7847:2252:199:20d:b9ff:fe4c:5324), 30 hops max, 80 byte packets
 1  2a01:4f8:161:12cd::2 (2a01:4f8:161:12cd::2)  0.384 ms  0.348 ms  0.306 ms
 2  ex9k1.dc7.fsn1.hetzner.com (2a01:4f8::a:16:a)  0.349 ms  0.453 ms  0.418 ms
 3  * core23.fsn1.hetzner.com (2a01:4f8:0:3::271)  17.384 ms *
 4  core4.fra.hetzner.com (2a01:4f8:0:3::1b9)  26.732 ms core0.fra.hetzner.com (2a01:4f8:0:3::361)  4.980 ms core4.fra.hetzner.com (2a01:4f8:0:3::1b9)  4.895 ms
 5  ipv6.de-cix.fra.de.as207790.stadtwerke-neumuenster.de (2001:7f8::3:2bae:0:1)  14.113 ms  14.637 ms  14.609 ms
 6  2a03:7840:1fc:30::1 (2a03:7840:1fc:30::1)  15.830 ms  15.898 ms  15.873 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
1

Wäre schön wenn das in deinem Fall auch so wäre (oder man den ISP dahingehend bringen kann), damit könntest du dann auf LAN/DMZ einfach das Prefix statisch konfigurieren und es müsste gleich funktionieren :)

Ich werde die noch mal anschreiben.

Dir auf jeden Fall vielen Dank für deine Hilfe, ich war schon kurz davor das Handtuch zu werfen und wieder Tunnelbroker zu nutzen.

JeGr

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

Ja, aber schädlich ist es nun doch auch nicht, oder?
Großes kommt nicht drauf, wireguard haue ich auf einen Xen DomU in meinem LAN.

Nein sicher nicht, aber man läuft dann nur unnötig in solche Probleme mit volllaufendem RAM. Und bei einigen RAMlastigen Paketen ist man vielleicht über mehr RAM froh wenn man den nicht für ne TmpDisc abgezweigt hat :)

Von aussen (Hetzner) kann ich per IPv4 und IPv6 auf die pfSense pingen, aber traceroute hört bei beiden Protokollen nach 6 Hops auf.

Ist auf dem WAN denn ICMP4/6 echo reply von außen erlaubt? Sonst ist es klar dass es keine Antwort gibt :)

Dir auf jeden Fall vielen Dank für deine Hilfe, ich war schon kurz davor das Handtuch zu werfen und wieder Tunnelbroker zu nutzen.

Ich bin tatsächlich wieder auf Tunnelbroker umgestiegen bzw. habe nie aufgehört ;) Grund ist da einfach, denn 2x business Anschlüsse zu Hause fürs Lab kann ich mir ernsthaft nicht leisten und sehe ich nicht wirklich ein. Und mit dynamischen Prefixen MultiWAN zu machen ist einfach ein Unding und Chaos. Ich könnte hier dann nur VLANs splitten und einen Teil von A und einen Teil von B beziehen lassen. Aber beide gleichzeitig nutzen wäre nicht drin. NPt hilft dann auch nicht, da NPt mit ändernden Prefixen nicht klar kommt und so geht es weiter. Die ganze verfahrene Situation mit dynamischen Prefixen behindert derart stark die sinnvollen Nutzung und Einführung von IPv6 dass man wirklich nur dauerhaft den Kopf schütteln kann :(

24unix

@jegr Heute nur eine kurze Antwort, sorry, hatte andere Baustellen, antworte morgen in Ruhe.

Wollte auf jeden Fall "mal kurz" den Tipp mit statischem IPv6 ausprobieren, plötzlich kam der unbound nicht mehr hoch.

Also "mal eben" wieder PDNS und PDNS Resolver aktiviert, bin wieder online, Frau kann weiter TV streamen, muss das morgen mal aufräumen, aber ich denke, ich schmeiße DNS und DHCP (v4) von der pfSense runter.

Hatte vorher die Kombi PDNS/PDNS-Resolver und KEA, werde ich wieder machen, auf die Firewall so wenig wie möglich, ist ja keine Fritte :)

JeGr

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

@jegr Heute nur eine kurze Antwort, sorry, hatte andere Baustellen, antworte morgen in Ruhe.

Kein Problem, musste auch heute den ganzen Tag ackern :)

Wollte auf jeden Fall "mal kurz" den Tipp mit statischem IPv6 ausprobieren, plötzlich kam der unbound nicht mehr hoch.

Nanü?
Das ist extrem merkwürdig. Gabs keine Logs?

24unix

@jegr said in pfSense an Stadtwerke NMS statt FritzBox:

@24unix said in pfSense an Stadtwerke NMS statt FritzBox:

@jegr Heute nur eine kurze Antwort, sorry, hatte andere Baustellen, antworte morgen in Ruhe.

Kein Problem, musste auch heute den ganzen Tag ackern :)

:-)

Weiter geht's.

Wollte auf jeden Fall "mal kurz" den Tipp mit statischem IPv6 ausprobieren, plötzlich kam der unbound nicht mehr hoch.

Nanü?
Das ist extrem merkwürdig. Gabs keine Logs?

Ne, gar nichts, keine Bewegung in den Logs, auch ein Neustart brachte nichts.

Egal, unbound deaktiviert.

Ich habe dann heute mal versucht, statisch was zu erreichen, aber die 0100 schiesst da wohl wirklich quer.

Ich werde jetzt mit den Netz leben, meine Clients alle anpassen, den Linux-Kisten via systemd-networkd reproduzierbare configs geben und DNS anpassen, die Macs kommen einfach auf auto.

Auf jeden Fall bin ich mit der Performance zufrieden, der Umstieg von dem Wackel-DSL auf Glasfaser hat sich gelohnt, und der kleinste Business Tarif ist immer noch günstiger als der kleinste bei der Telekom mit statischer IP.