Beiträge von fcc123

Zitat von ::1

Dein Paket-Mitschnitt enthält ja nicht ein einziges RA. Wenn du den Ansichtsfilter in Wireshark mal lediglich auf icmpv6 setzt, siehst du dann noch andere ICMPv6-Pakete wie NS, NA, oder RS? Wenn die DG-Gegenstelle weder RA (wie beobachtet) noch NA oder NS sendet, würde ich sagen, dass die DG-Gegenstelle IPv6-mäßig mausetot ist.

Das gabs mit icmpv6 als Filter. Nichts mit Source von DG...

Ich checke nochmal morgen da ipv6 ja jetzt wieder geht.

Dann weiss ich wie der Erfolgsfall aussehen muss

Danke für die ausführliche Beschreibung - ich werde das mal durchgehen!

Wie der Zufall es will, um 12:15 habe ich eine Mail von meinem dyndns bekommen, dass der Router sich bei ihm mit einer ipv6 Adresse gemeldet hat. Hurra - nach 2 Wochen wieder ipv6

Mal sehen ob noch eine Antwort von DG kommt.

Zitat von frank_m

Diese Werte findest du im Paketmitschnitt bei der Auswertung in Wireshark. Ich muss meine Beiträge noch mal durchforsten, ich hab hier bereits bei mehreren Gelegenheiten Screenshots einer erfolgreichen IPv6 Adressvergabe bei der DG gepostet. Meistens ging es darum, die DHCP Parameter für andere Router (Unify, Microtik, Asus) zu optimieren, damit sie kein Problem mit der DG haben.

Danke.

Das war mein erster Gedanke - konnte aber nichts entsprechendes finden. Sind die in den dhcpv6 Paketen?

Ich suche mal nach Deinen Postings.

Zitat von ::1

- Absende-Adresse die eben erwähnte linklokale Adresse. Diese verwendet die Fritzbox als IPv6-Standardgateway, sofern
- "Router lifetime" größer als 0 ist - bei DG sollte sie 1800 s betragen
- Flags=0x80, d.h. das M-Flag "Managed Address configuration" muss gesetzt (=1) sein.
- MTU=1500
- PIO (Prefix Information Option) ist nicht enthalten.

Hi ::1 - wie kann ich prüfen, dass das bei mir so eingestellt ist?

MTU habe ich gefunden und angepasst, die anderen Parameter finde ich nicht bei der FB Config.

Im Config-Export finde ich "AdvDefaultLifetime = 1800" bei ipv6, aber die anderen Parameter findet ich nicht.

Hier das gleiche Problem seit ca. 10 Tagen - in der Vergangenheit, seit Vertragsbeginn Oktober 2023, gabs das Problem 3-4 mal für 1-2 Tage. Dann habe ich Tickets aufgemacht und dann gings irgendwann wieder.

Dump für Wireshark ist fertig - ich habe ihn mal über Nacht laufen lassen:

Ich sehe die oben beschriebenen Pakete, die die FB verschickt - erst in Minutenabständen, später in ~1h Abstand.

Edit: Screenshot hinzugefügt

Antworten von DG sehe ich nicht... und im Eventlog der FB kommt: Keine Antwort vom DHCPv6-Server (SOL)

Auf meine letzte Nachricht an DG habe ich die Antwort bekommen, dass ich Geduld habe soll, ein Team von Spezialisten arbeit daran.

btw: Die ganzen Tipps, die DG empfiehlt, und was ich hier finde habe ich auch schon durch.

Mal ne Frage zu dem Fritzbox-Mesh da ich seit bald 10 Jahren raus war aus dem Fritzbox-Thema

Meshen geht nicht mit Geräten anderer Hersteller nehme ich an, oder?

satellite - Die erste echte Mobilfunk-App

Warum ist deine Handynummer eigentlich immer an eine SIM-Karte gebunden? Und was könntest du machen, wenn das nicht so wäre? satellite macht es einfach möglich…

www.satellite.me

Vielleicht auch ne interessante Alternative für Handynutzer - 5€ Flatrate in 61 Länder (Fest- und Mobilfunk) oder 100 min/Monat kostenlos (reicht mir locker )

Gerne poste ich die funktionierende Config aus meinen Hilfethread.

Hier meine funktionierende Konfiguration mit Openwrt 22.03.5 (Archer C7 v5) / Server (Debian & podman):

OpenWRT:

/etc/config/network:

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fd86:3ad6:232c::/48'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth0.1'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'

config device
    option name 'eth0.2'

config interface 'wan'
    option device 'eth0.2'
    option proto 'dhcp'

config interface 'wan6'
    option device 'eth0.2'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '1'
    option ports '0t 3 4 5'
    option description 'LAN'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0t 1'
    option vid '2'
    option description 'WAN'

config device
    option name 'eth0'
    option macaddr 'xx:xx:xx:xx:xx:xx'

config device
    option name 'eth0.1'
    option type '8021q'
    option ifname 'eth0'
    option vid '1'
    option macaddr 'xx:xx:xx:xx:xx:xx'

/etc/config/firewall:

config defaults
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option synflood_protect '1'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    list network 'lan'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'
    list network 'wan'
    list network 'wan6'

config forwarding
    option src 'lan'
    option dest 'wan'

config rule
    option family 'ipv6'
    option src 'wan'
    option dest 'lan'
    option target 'ACCEPT'
    option name 'srv'
    list proto 'tcp'
    list proto 'udp'
    list dest_ip '::xxx/-64'
    option dest_port '22 25 80 110 143 443 465 587 993 995 51820'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-MLD'
    option src 'wan'
    option proto 'icmp'
    option src_ip 'fe80::/10'
    list icmp_type '130/0'
    list icmp_type '131/0'
    list icmp_type '132/0'
    list icmp_type '143/0'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-IPSec-ESP'
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'

config rule
    option name 'Allow-ISAKMP'
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'

/etc/config/dhcp:

config dnsmasq
    option domainneeded '1'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
    option localservice '1'
    option ednspacket_max '1232'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv4 'server'
    option dhcpv6 'server'
    option ra 'server'
    list ra_flags 'managed-config'
    list ra_flags 'other-config'
    list dhcp_option '6,192.168.1.2'
    option ra_mininterval '200'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'
    option loglevel '4'

Der Knackpunkt bei meinem Scenario war die Config von podman da man die podman Netzwerke ipV6-fähig machen muss. Dazu am besten der Anleitung hier folgen: Podman Networking ipV6

Aardvark DNS habe ich auch installiert und dann sieht meine Netzwerk-Config so aus:

{
     "name": "default_network",
     "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "driver": "bridge",
     "network_interface": "podman2",
     "created": "2023-10-08T20:23:34.192362397+02:00",
     "subnets": [
          {
               "subnet": "fd00::1:10:0/112",
               "gateway": "fd00::1:10:1"
          },
          {
               "subnet": "10.11.12.0/16",
               "gateway": "10.11.12.1"
          }
     ],
     "ipv6_enabled": true,
     "internal": false,
     "dns_enabled": true,
     "ipam_options": {
          "driver": "host-local"
     }
}

Damit waren meine podman Dienste via OpenWrt freigegeben.

Ich muss anfügen, dass der Archer C7 einfach zu langsam ist für die Glasfaserleitung. Ich habe max. 250mbit down hinbekommen. Als Freifunk Node ist er aber ausreichend.

Deshalb läuft bei mir seit eben wieder eine Fritzbox (4060). Eigentlich wollte ich keine Fritzbox mehr, es war aber vom Preis her einigermaßen interessant da ich die alten Fritzfon-Teile noch weiter verwenden kann.

Wichtig: DNS-Rebind Schutz muss bei der Fritzbox ggf. konfiguriert werden. Bei mir gabs da Probleme bei dem Kontakt zum Server aus dem lokalen Netzwerk.

Des weiteren habe ich den Mailserver auf einen VPS in die Cloud umgezogen. Ein Mailserver via ipV6 ist noch nicht überall gerne gesehen

Und so sieht die Bastelecke in natura aus:

Das Ding da unten ist übrigens nicht der Server um den es ging, das ist der Mini-PC im Schrank.

Die große Kiste ist mein NAS.

Hier mal ein Update:

Mit eurer Hilfe und mache Key-Wörter, die mich zum Nachdenken brachten, läuft jetzt fast alles

Allerdings habe ich mich entschieden meinen Mailserver nach Netcup/VPS zu verschieben.

Mailserver mit ipV6 scheint keine so gute Idee zu sein.

Jetzt habe ich noch 2 größere Probleme auf der Platte:

• Gäste-Wlan (die alte Config geht nicht - scheint DG ein Problem zu haben (2 x VLAN).
• Die alte Fritzbox im Netz soll wieder SIP machen

Vielen Dank an die Helfer für den 24/7 Support - Ihr seit wirklich sehr umsichtig mit mir gewesen!!

OMG - wie doof von mir:

config rule
        option name 'ssh'
        option family 'ipv6'
        list proto 'tcp'
        option src 'wan'
        option dest 'lan'
        option dest_port '22'
        option target 'ACCEPT'

src_port weglassen - dann gehts.

Ich habe einen neuen Router aufgesetzt (gleiches Model, neueres OpenWRT).

Alles auf Default gelassen.

In dem Scenario gehen Ping (ICMP6) Pakete durch und kommen auch wieder zurück.

Zitat von frank_m

Kann der Server grundsätzlich per IPv6 ausgehend kommunizieren?

Das habe ich ausprobiert - nachdem ich eine default Route gesetzt habe geht das jetzt auch - ich dacht das setzt der Router via RA...

Ich konnte ssh auf den VPS machen.

Leider funktioniert der umgekehrte Weg noch nicht.

Auf dem Server kommt nichts auf port 22 an, die Pakete werden im Router geblock so wie ich tcpdump interpretiere.

13:40:53.037396 IP6 mein.vpsbeinetcup.de.56402 > xxxx:xxxx:xxxx:xxxx::130.22: Flags [S], seq 306380445, win 43200, options [mss 1440,sackOK,TS val 91153059 ecr 0,nop,wscale 11], length 0
13:40:53.037576 IP6 xxxx:xxxx:xxxx:xxxx::130.22 > mein.vpsbeinetcup.de.56402: Flags [R.], seq 0, ack 306380446, win 0, length 0

In der Firewall habe ich darauf eine Regel angelegt um Daten auf Port 22 durchzulassen - will aber noch nicht.

config rule
        option name 'ssh'
        option family 'ipv6'
        list proto 'tcp'
        option src 'wan'
        option src_port '22'
        option dest 'lan'
        option dest_port '22'
        option target 'ACCEPT'

Ich habe jetzt die Sache mal mit tcpdump analysiert:

Wenn ich auf meinem VPS bei Netcup eine ssh Session auf den Server initiiere (mit IPv6 Adresse)

wandert das IP6 Paket durch den Router auf den Server und der Server schickt ein IP6 Paket zurück zum

VPS. Dort kommt es aber nicht an.

Im Router sehe ich das Paket zum VPS noch auf eth0 allerdings nicht auf eth0.2 (WAN,WAN6).

Das ist zumindest mal die Erklärung warum von "Aussen" meine Dienste nicht erreichbar sind.

Jetzt ist die Frage warum?

So, tcpdump zeigt mit ssh Pakete, die am Router und auf dem Server ankommen.

D.h. das ist dann wohl kein DG Problem sondern mein Config-Fehler

Zitat von frank_m

Von wo testest du den Zugriff von außen? Ist das ein VPS bei Netcup?

Ansonsten geh Schritt für Schritt vor. Greife zunächst auf die IP Adressen zu, später dann per dyndns. Mache auf dem VPS einen tcpdump vom Zugriffsversuch, um ggf. ICMP Antworten zu sehen und von wem diese Antworten kommen (OpenWRT Router?). Mache gleichzeitig einen tcpdump auf deinem Router, um dort zu beobachten, was an Traffic ankommt und wie damit verfahren wird. Nicht zuletzt beobachte auf dem Server ebenfalls mit tcpdump, was passiert. So bekommst du ein Bild davon, wie weit die Pakete kommen.

Neben den eigentlichen Port Rules musst du ja auch die Firewall grundsätzlich so einrichten, dass Zugriffe von außen möglich werden (Policies etc). Ich weiß nicht, wie das bei OpenWRT geht, aber hast du das bedacht?

Ja, vps bei netcup

Ich versuche mal tcpdump.

Grundsätzlich hatte bis gestern morgen alles noch via DSL funktioniert, allerdings hatte ich da noch eine dynamische ipv4 Adresse.

Die Zonen in Openwrt sind für ipv4 und ipv6 konfiguriert, von daher gehe ich davon aus, dass ich da sauber bin.

Aber wenn das kein DG Problem ist, dann liegt bei der Firewall der Hase im Pfeffer

Zitat von Thomas1978

Wenn du von Container schreibst dann meinst du damit doch Docker Container, richtig?

Ich habe früher auch viel mit Freigaben in meinem Router gearbeitet, bin mittlerweile aber komplett auf einen Reverse Proxy umgestiegen. Bei mir läuft der NGINX Reverse Proxy in einem Docker auf meinem Unraid Server. Das ist jetzt nur noch der einzige Docker, der bei mir von außen erreichbar sein muss (über Port 80 und 443!).

Wichtig ist, dass du entweder eine eigene Domaine hast, oder eine DynDNS Adresse mit Subdomains einrichtest. Für jedes Gerät aus deinem Netzwerk, das du von außen erreichen willst, legst du eine Subdomain an. Bei einer eigenen Domain reicht dafür ein cname Eintrag aus, der auf die IP-Adresse (v4 via NAT und/oder v6 direkt) des Dockers verweist. Beim Aufruf der Subdomain geht die Anfrage direkt an den Reverse Proxy Docker und der leitet ab da intern auf das verknüpfte Gerät weiter. Das Ganze lässt sich auch mit SSL absichern.

Ja, so habe ich es für http/https auch implementiert via npm (nginx proxy manager) und podman statt docker.

Aber es laufen noch diverse andere Dienste auf dem Server, d.h. ich habe noch einige andere Ports offen.

Hast Du die Docker Netzwerke konfiguriert, oder nur ipv4?

Zitat von HubeBube

Die Container würde ich erst einmal außen vor lassen, da können sich weitere Baustellen ergeben.

Es reicht aus sich auf SSH via IPv6 zu beschränken, alles andere ist analog dazu einzurichten.

Wichtig an dieser Stelle, sofern die Authentifizierung nicht über Zertifikate erfolgt, es dürfen keine erratbaren Accounts mit Standardpasswörtern verwenden werden. Am besten DenyUsers und/oder AllowUsers verwenden.

Auch sollten DynDNS Einträge noch nicht verwendet werden, sondern die IPv6-Adressen. Dazu ist noch zu sagen, dass sich natürlich der Server und nicht der OpenWRT Router in den DynDNS Eintragen muss.

Noch eine Sache, die mir einfällt: Dein Router teilt dem Server seine IPv6 Adresse auch aus dem 56er Netz zu, das Du als Präfix von DG erhälst?

Ja, für den Test lasse ich es mal offen, aber Du hast Recht - normalerweise habe ich den Port nicht offen.

Ja, der Server hat einen dyn dns Eintrag.

Der Server bekommt von Openwrt den öffentlichen Prefix mit und auch den ULA-Prefix.

D.h. das sieht dann so aus:

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.100  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2a00:6020:pref:pref:xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        inet6 fd00:yyyy:yyyy:0:xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x0<global>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 17897  bytes 24240326 (23.1 MiB)
        RX errors 0  dropped 22  overruns 0  frame 0
        TX packets 6171  bytes 565279 (552.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf000000-df020000

intern meine ich Rechner und Mobile Devices die mit ipv4/v6 am Router hängen.

Bsp: ssh user@2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx von meinem Windows PC auf die Linux-Box funktioniert.

Ich kann jetzt ipv4 auf dem PC noch ausschalten, aber ich denke das macht keinen Unterschied.

Die Nameserverauflösung löst auch korrekt auf (dyn dns auf IPV6 der Servers) und Ping etc. funktionieren wenn ich in meinem lokalen (physischem) Netzwerk bin.

Edit:

sshd läuft direkt auf dem Server, nicht in einem Container und der Rechner hört auch auf dem Port:

tcp6       0      0 :::22                   :::*                    LISTEN

Die anderen Dienste laufen fast alle als Container mit ipv4 Netzwerk - d.h. hier ist ggf. ein Problem was ich noch lösen muss, aber ssh sollte zumindest von aussen errreichbar sein.

Dienste laufen via Podman/Linux und sind von Intern zu erreichen.

net.ipv6.conf.all.use_tempaddr = 0

Noch als Nachtrag: Der Router läuft noch mit OpenWrt 19.07.7

Hallo HubeBube, und Danke für die Willkommensgrüße

Ja, der interne Rechner hat auch eine öffentliche IPV6 IP.

Zur Freigabe habe ich die Rules in Openwrt angelegt - ich dachte das sollte so passen.

Aber scheinbar doch nicht...

Hallo Zusammen,

ich habe heute einen DG-Anschluss bekommen (Wechsel von Inexio DSL).

Normales Surfen etc. funktioniert nachdem ich einfach den WAN Port auf DHCP und einen WAN6 mit dhcpv6 angelegt habe,

Dann wollte ich meine diversen Dienste wieder nach Aussen freigeben.

Bei Inexio hatte ich eine IPv4 Adresse, d.h. dort konnte ich "Port Forwards" anlegen jetzt bei DG gibts keine dyn. IPV4 Adresse mehr also habe ich rules angelegt analog diesem Beispiel (https://openwrt.org/docs/guide-use…ipv6_examples):

config rule
	option src 'wan'
	option proto 'tcp'
	option dest 'lan'
	option dest_ip '2001:db8:42::1337'
	option dest_port '80'
	option family 'ipv6'
	option target 'ACCEPT'

Ich habe mal die aktuelle komplette IPV6 Adresse als Ziel angeben zum Testen (dest_ip).

Allerdings ohne Erfolg - ich komme von Aussen nicht drauf.

Dann habe ich mal alles umgeleitet - auch ohne Erfolg.

config rule
        option src 'wan'
        option family 'ipv6'
        option target 'ACCEPT'
        option dest 'lan'
        option name 'Forward to Server'
        list dest_ip '2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx'
        list proto 'all'

Dann habe ich mal einen traceroute versucht um zu sehen wie weit er kommt:

traceroute to srv.example.net (2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx), 30 hops max, 80 byte packets
 1  2a03:4000:60::2 (2a03:4000:60::2)  0.550 ms  0.506 ms  0.504 ms
 2  2a00:11c0:47:8::e (2a00:11c0:47:8::e)  4.338 ms  0.603 ms  4.289 ms
 3  2a00:11c0:47:1:47::139 (2a00:11c0:47:1:47::139)  11.235 ms  11.217 ms 2a00:11c0:47:1:47::212 (2a00:11c0:47:1:47::212)  36.809 ms
 4  * * 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141)  5.513 ms
 5  * 2a00:6020:0:b::2 (2a00:6020:0:b::2)  28.361 ms *
 6  2a00:6020:0:c::2 (2a00:6020:0:c::2)  4.382 ms  4.085 ms 2a00:6020:ffff:ffff::e (2a00:6020:ffff:ffff::e)  19.799 ms
 7  * * 2a00:6020:ffff:ffff::e (2a00:6020:ffff:ffff::e)  4.712 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *

Traceroute bleibt scheinbar vorher schon hängen.

Liegt das Problem bei meiner Config, oder bei DG?

Viele Dank schonmal fürs Lesen