[Frage] IPv6 Freigabe auf die Box

andiling

IPPF-Promi
Mitglied seit
19 Jun 2013
Beiträge
5,975
Punkte für Reaktionen
2
Punkte
0
Wie kann ich eigentlich eine IPv6 Freigabe auf die Box einrichten?

Bei meiner 3490 mit freetz scheinen die Einträge unter AVM-Forwarding wohl nur IPv4 zu betreffen. IPv6 Ports bleiben alle geschlossen.

Danke...
 
Moins

Für IPv4 hab ich mal geguckt wie/ob das mit dem ctlmgr_ctl gehen könnte.
Dabei ist dieses CGI/SHELL Skript rausgekommen...
fb_fw.cgi
Code:
#!/bin/sh
echo 'Content-Type: text/plain
'
local FW_IP=${1}
local FW_PORT=${2}
local FW_PORT_ST=${3}
local FW_PORT_EN=${4}
local FW_PRT=${5}
local FW_DESCR=${6}
local FW_ACT=${7}
local NEWRULE=$(ctlmgr_ctl r forwardrules settings/rule/count)
fw_activate () {
if [ $# -eq 2 ] ; then
ctlmgr_ctl w forwardrules settings/rule${1}/activated ${2}
fi
}
fw_delete () {
if [ $# -eq 1 ] ; then
ctlmgr_ctl w forwardrules settings/rule${1}/fwip 0
fi
}
fw_status () {
local maxcount=$(ctlmgr_ctl r forwardrules settings/rule/count)
if [ ${maxcount} -gt 0 ] ; then
local count=0
while [ ${count} -lt ${maxcount} ] ; do
local FW_IP=$(ctlmgr_ctl r forwardrules settings/rule${count}/fwip)
local FW_PORT=$(ctlmgr_ctl r forwardrules settings/rule${count}/port)
local FW_PORT_ST=$(ctlmgr_ctl r forwardrules settings/rule${count}/fwport)
local FW_PORT_EN=$(ctlmgr_ctl r forwardrules settings/rule${count}/endport)
local FW_PRT=$(ctlmgr_ctl r forwardrules settings/rule${count}/protocol)
local FW_DESCR=$(ctlmgr_ctl r forwardrules settings/rule${count}/description)
local FW_ACT=$(ctlmgr_ctl r forwardrules settings/rule${count}/activated)
echo ${FW_IP}\
', '\
${FW_PORT}\
' an '\
${FW_PORT_ST}\
' - '\
${FW_PORT_EN}\
', '\
${FW_PRT}\
', '\
${FW_DESCR}\
', '\
${FW_ACT}
: $((count++))
done
else
echo 'No rules present!'
fi
}
if [ $# -eq 7 ] ; then
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/fwip ${FW_IP}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/port ${FW_PORT}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/fwport ${FW_PORT_ST}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/endport ${FW_PORT_EN}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/protocol ${FW_PRT}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/description ${FW_DESCR}
fw_activate ${NEWRULE} ${FW_ACT}
else
case ${QUERY_STRING} in
disable) fw_activate ${2} 0;;
enable) fw_activate ${2} 1;;
delete) fw_delete ${2};;
help) echo $(basename ${0})
echo -e ': Need 7 arguments!\n'
echo -e '[fwip] [port] [fwport] [endport] [protocol] [description] [activated]\n'
echo -e 'status for entries\n'
echo -e 'disable number or enable number enables or disable entry number\n'
echo -e '(first entry is 0)\n'
echo -e 'and delete number is deleting entry number\n';;
status) echo 'Rules:'
fw_status ;;
*) echo $(basename ${0})': try help';;
esac
fi
#EOF
Der Vorteil dabei ist, dass dies AVM Konform während der Laufzeit funktioniert.
Alle nötigen Schritte werden vom ctlmgr/multid sofort ausgeführt/übernommen.
Kein Neustart notwendig.

Ich denke, dass sowas auch mit IPv6 gehen könnte.
...müsste sich mal genauer angeguckt werden.

Können wir ja zusammen entwickeln, falls das so geht wie ich mir das vorstelle.

Verbessern wäre auch eine Massnahme.
Als CGI (wegen der blöden QUERY_STRING Auswertung) geht nur: help oder status
Als Shellskript: Anzeigen/Anlegen/Löschen/Aktivieren/Deaktivieren

Vater des Gedankens war: Freigaben zeitgesteuert mit dem crond Anlegen/Aktivieren/Deaktivieren/Löschen

Die Freigabeninfo für IPv6 holt die Fritz!Box auf dem IPv6 Reiter so...
Code:
MQUERIES = {  ["ipv6firewall:settings/rule/list(enabled,neighbour_name,ifaceid)"] = {
...hier stehen die Daten...
}
}
 
Zuletzt bearbeitet:
Hallo koyaanisqatsi ,

Danke für Deine Mühe und ich werde mich damit mal im Laufe des Tages beschäftigen... nur geht es mir um eine Freigabe auf die Box selbst. In der ar7.cfg habe ich zwar voip_ip6_forwardrules gefunden, nur wenn ich da die Ports mit eintrage klappt das leider nicht.
 
Moins

Na, klar, wie dumm von mir.

Das Problem hatte ich auch mal.
Gelöst hab ich das, indem ich beide Freigaben (IPv4 & 6) in die Rules für VoIP (ar7.cfg) eingetragen habe.
Muss mal den Thread rauskramen, moment...

Hier: [Problem] Port Freigabe für OpenVPN
 
Zuletzt bearbeitet:
Den Thread hatte ich zwischenzeitlich auch gesehen, nur habe ich darin keinerlei Hinweis gefunden, dass es auch mit IPv6 klappt bzw. bei mir tut es das eben nicht.
 
Diese Art der Freigabe verhält sich genauso wie die für den Port 5060, ausser das für den auch UDP freigegeben ist.
Genauer..
Code:
[B]voip_ip6_forwardrules = "udp 5060,7078-7109", "tcp 5060,[COLOR=#ff0000]8088[/COLOR]";[/B]
...macht dies.

Knifflig ist nur, die Box entfernt das unter Umständen wieder.
...welche das sind weiss ich nicht.
Hatte die aber auch schon erfolgreich über Monate drinne.

Aber durch ein Sichern der Einstellungen und Import bei Bedarf hast du sie wieder.
Wobei das Editieren der ar7.cfg wesentlich flotter geht. ;)

Vorteil dabei ist, das du diese Freigabe unter Diagnose/Sicherheit jederzeit überprüfen kannst.
Und dort wird sie auch als IPv4 oder IPv6 angezeigt, je nachdem.
 
Genau so hatte ich es... kann es sein, dass die Regeln da gar nicht abgearbeitet werden wenn die Telefonie auf der 3490 nicht aktiviert ist?
 
Wen die Freigabe gültig ist, steht das unter Diagnose/Sicherheit.
Ich kenne keinen Menüpunkt der bewirkt, dass SIP TCP/UDP 5060 oder die RTP UDP 7078+32 nicht dort erscheinen und gültig sind.
 
So sieht es bei mir aus:

Code:
        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", 
                            "tcp 0.0.0.0:5060 0.0.0.0:5060", 
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";
        voip_ip6_forwardrules = "udp 500,1701,4500,5060,7078-7109", 
                                "tcp 5060";
        tr069_ip6_forwardrules = "tcp 8089";
        internet_in_nat_rules_enabled = yes;
        internet_out_nat_rules_enabled = yes;
        internet_forwardrules = "udp 0.0.0.0:500 0.0.0.0:500 0", 
                                "udp 0.0.0.0:4500 0.0.0.0:4500 0", 
                                "udp 0.0.0.0:1701 0.0.0.0:1701 0";

Und das zeigt die Box unter Sicherheit an:

Screenshot - 12.08.2015 , 10_12_30.jpg
 
@andiling:
Hast Du mal einen Eintrag in der ar7.cfg unter "ipv6->firewall->rules" versucht zu erstellen?
 
Jetzt habe ich es versucht. ;)
Code:
rules = "udp 500, 1701, 4500";

Unter Diagnose - Sicherheit werden alle drei Ports als für IPv6 offen angezeigt, nur nmap zeigt mir lediglich 500 und 4500 als offen an, nicht jedoch 1701.
 
nur nmap zeigt mir lediglich 500 und 4500 als offen an, nicht jedoch 1701.
Neustart gemacht?

EDIT: 500 / 4500 haben da nichts zu suchen, bringen höchstens zusätzliches Durcheinander, darum kümmert sich die Box selbst - und das Format ist vermutlich auch noch falsch. Ich weiß nicht, ob da mehrere Ports mit einer "TCP"- oder "UDP"-Anweisung machbar sind ... warum versuchst Du es nicht mit rules = "UDP 1701", "TCP 1234", "TCP 2345"; usw.?
 
Zuletzt bearbeitet:
Neustart gemacht und 500, 4500 kommen auch am SoftEther VPN Server an (das FB VPN ist deaktiviert bzw. auch durch freetz entfernt), nur die anschließende L2TP Verbindung über udp 1701 wird nicht initiiert weil der Client wohl gar nicht durchkommt. Wenn ich die 500 und 4500 rausnehme, sind die Ports nicht mehr offen und wenn ich nur rules = "UDP 1701"; mache ist der Port auch nicht erreichbar.

Kleinen Test gemacht.

Screenshot - 12.08.2015 , 11_43_09_ver001.jpg

Trotz Angabe sind nur die Ports offen, die die Fritzbox als eigene Dienste kennt, egal ob die gestartet sind oder nicht. Die angezeigten Ports 7, 13, 1701 sind geschlossen, 500, 4500 und 5060 offen.

Es macht übrigens keinen Unterschied ob ich "UDP x", "UDP y", "UDP z" oder "UDP x,y,z" eingebe.
 
Zuletzt bearbeitet:
das FB VPN ist deaktiviert bzw. auch durch freetz entfernt
Das ist dann natürlich etwas anderes ... davon stand ja noch nichts da.

Was heißt "der Port ist nicht erreichbar?" ... kommen Daten an, wenn man mit tcpdump nachsieht (wenn nicht, ist es die Firewall) oder kommen sie nicht an?

Unter /proc/kdsld/dsliface/internet/ip6_ct/forwards kannst Du Dir die Forwards ansehen ... die landen für "[LOCAL]" auf der Box selbst. Allerdings muß natürlich die IPv6-Adresse (in voller Länge) stimmen und von außen ist auch die richtige IPv6-Adresse zu verwenden (die letzte in der genannten Ausgabe). Die erste (und zweite, ich habe noch nie gesehen, daß sich die unterschieden haben) IPv6-Adresse ist diejenige, an die sich der SoftEther-Server binden muß ... das ist die auf dem "dev lan" und dort kommen die Pakete an, wenn sie die Firewall passiert haben.

Ansonsten kannst Du Dir die vorhandenen Port-Forwardings auch in der Ausgabe von
Code:
echo "T=openports:settings/openports/list(addrtype,protocol,extern_ip,extern_port,intern_ip,intern_port,intern_name,priority,group,type,exposed_host,ping_allowed,temporary,description,dsliface)" | queries.lua
ansehen, wenn Du Telnet-Zugang und die queries.lua verwendest (die Abfrage geht natürlich auch über das Web-Interface und die query.lua).
 
Das ist die Ausgabe von forwards:
Code:
[LOCAL]: 2003:5f:7d38:3d0[COLOR="#FF0000"]0[/COLOR]:3631:ddaa:bbcc:f6 2003:5f:7d38:3d0[COLOR="#FF0000"]1[/COLOR]:3631:ddaa:bbcc:f6 2003:5f:7d7f:b832:3631:ddaa:bbcc:fa
  UDP 500,1701,4500
Die letzte stimmt mit der genutzten IP überein.

Hier ist queries.lua:
Code:
T_1_index="openports0"
T_1_addrtype="v4"
T_1_protocol="UDP"
T_1_extern_ip="91.40.251.3"
T_1_extern_port="500"
T_1_intern_ip="192.168.188.9"
T_1_intern_port="500"
T_1_intern_name=""
T_1_priority="0"
T_1_group="normal"
T_1_type="IKE"
T_1_exposed_host="0"
T_1_ping_allowed="0"
T_1_temporary="0"
T_1_description="IKE"
T_1_dsliface="internet"
T_2_index="openports1"
T_2_addrtype="v4"
T_2_protocol="UDP"
T_2_extern_ip="91.40.251.3"
T_2_extern_port="4500"
T_2_intern_ip="192.168.188.9"
T_2_intern_port="4500"
T_2_intern_name=""
T_2_priority="0"
T_2_group="normal"
T_2_type="NAT-T"
T_2_exposed_host="0"
T_2_ping_allowed="0"
T_2_temporary="0"
T_2_description="NAT-T"
T_2_dsliface="internet"
T_3_index="openports2"
T_3_addrtype="v4"
T_3_protocol="UDP"
T_3_extern_ip="91.40.251.3"
T_3_extern_port="1701"
T_3_intern_ip="192.168.188.9"
T_3_intern_port="1701"
T_3_intern_name=""
T_3_priority="0"
T_3_group="normal"
T_3_type=""
T_3_exposed_host="0"
T_3_ping_allowed="0"
T_3_temporary="0"
T_3_description=""
T_3_dsliface="internet"
T_4_index="openports3"
T_4_addrtype="v6"
T_4_protocol="UDP"
T_4_extern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_4_extern_port="500"
T_4_intern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_4_intern_port="500"
T_4_intern_name=""
T_4_priority="0"
T_4_group=""
T_4_type="IKE"
T_4_exposed_host="0"
T_4_ping_allowed="0"
T_4_temporary="0"
T_4_description="IKE"
T_4_dsliface="internet"
T_5_index="openports4"
T_5_addrtype="v6"
T_5_protocol="UDP"
T_5_extern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_5_extern_port="1701"
T_5_intern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_5_intern_port="1701"
T_5_intern_name=""
T_5_priority="0"
T_5_group=""
T_5_type=""
T_5_exposed_host="0"
T_5_ping_allowed="0"
T_5_temporary="0"
T_5_description=""
T_5_dsliface="internet"
T_6_index="openports5"
T_6_addrtype="v6"
T_6_protocol="UDP"
T_6_extern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_6_extern_port="4500"
T_6_intern_ip="2003:5f:7d38:3d00:3631:ddaa:bbcc:f6,2003:5f:7d38:3d01:3631:ddaa:bbcc:f6,2003:5f:7d7f:b832:3631:ddaa:bbcc:fa"
T_6_intern_port="4500"
T_6_intern_name=""
T_6_priority="0"
T_6_group=""
T_6_type="NAT-T"
T_6_exposed_host="0"
T_6_ping_allowed="0"
T_6_temporary="0"
T_6_description="NAT-T"
T_6_dsliface="internet"
T_count=6

Hier der Mitschnitt von vcc0/16 über die Fritzbox und dann Wireshark-Auswertung:

Screenshot - 12.08.2015 , 12_38_41_ver001.jpg
 
Zuletzt bearbeitet:
Um das noch einmal klarer zu formulieren: Die Ausgabe von queries.lua oder query.lua ist die Sicht des ctlmgr auf die Freigaben ... genauso wie die in der Security-Seite. Die Anzeige unter /proc/kdsld ist die "Netzwerksicht" des dsld ... die müssen nicht zwangsläufig identisch sein, wenn man von Hand Änderungen vorgenommen hat.

EDIT: Stimmt, bei mir stehen da tatsächlich auch drei unterschiedliche Adressen ... die erste ist die des "lan"-Interfaces, die zweite die des "guest"-Interfaces und die dritte schließlich die des "dsl"-Interfaces. Was die Aussage (u.a. in Bezug auf das Gast-Interface) sein soll, weiß ich nicht so richtig ... vielleicht ja auch ein Fehler bei der Einrichtung des Port-Forwardings? Was hat ansonsten das "guest"-Interface in dieser Liste zu suchen?
 
Zuletzt bearbeitet:
Ich bin dem nochmal mit nmap nachgegangen, da ist bei IPv4 und IPv6 das Ergebnis identisch:
Code:
500/udp open isakmp
1701/udp closed L2TP
4500/udp open|filtered nat-t-ike

Also gehe ich mal von aus, dass seitens der Fritzbox alles so ist wie es sein soll und die Lösung von @PeterPawn mit der Angabe in ipv6 -> firewall -> rules genau die richtige ist.

Das brachte mich dann auf die Idee, dass der Server den L2TP Port nur öffnet wenn konkret etwas zu erwarten ist. Und siehe da, im Log ist mir dann aufgefallen, dass
Code:
2015-08-12 06:17:14.256 IPsec Client 17 (1.2.3.4:4500 -> 5.6.7.8:4500): The L2TP Server Module is started.
bei IPv6 fehlt. Jetzt fehlt mir aber im Moment die weitere Zeit zu.
 
Zuletzt bearbeitet:
Bei der tcpdump-Ausgabe (bzw. das sieht eher nach WireShark aus) blicke ich nicht so richtig durch ohne Ports ... ich würde spontan auf IKE/ISAKMP tippen und damit auf IPSec-Verkehr.

Es muß noch irgendeinen Trigger geben, denn verstanden hat die Box diese Portfreigabe offenbar bei mir schon (ich habe auch mal getestet). Während alle anderen Ports weiterhin in der "nmap"-Ausgabe auf "filtered" stehen (da kommt vermutlich ein "admin filtered" zurück), erhalte ich für den Port 1701 (hinter dem kein Dienst läuft, ich muß mir erst mal einen IPv6-fähigen UDP-Listener suchen) eindeutig ein "closed" ... ohne die Freigabe gibt das auch ein "filtered".

Wenn es bei Dir auch nur an einem nicht erfolgreichen "listen"-Aufruf für das Interface liegt (was sagt denn "netstat" dazu?), wäre das ja auch eine Erklärung für das "closed" (wenn es bei Dir auch kein "filtered" ist).
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.