[geloest]fritzbox hinter linux/iptables/nat ... kernel 2.6.22

skambar

Neuer User
Mitglied seit
7 Apr 2007
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
hi forum,

ich hoffe, ich finde hier jemanden, der mir bei meinem problem ein wenig unter die arme greifen kann. hintergrund des problems:

ich habe bis vor kurzem einen alten rechner in der ecke stehen gehabt, der mir dank m0n0wall-linux immer eine angenehm gepflegte internetleitung praesentiert hat. leider ist mein anspruch an die leitung und an den rechner so sehr gestiegen, dass ich mich von m0n0wall verabschieden musste und nun ein gentoo-linux dort aufgebaut habe. dabei verwende ich eine fritzbox 7050 als lan-client hinter dem router, welche mir weiterhin - wie auch schon in zeiten von m0n0wall - die moeglichkeit geben soll via voip nach draussen zu telefonieren. meinen sipaccount habe ich bei gmx, die leitung ist bei congster/t-online - 6mbit.

beim aufstellen des neuen routers war das wiederherstellen der internetverbindung ueberhaupt kein problem. aufstellen, gescheiten kernel aufsetzen, dnsmasq + iptables -t nat -A POSTROUTING MASQUERADE und mit ein paar einstellungen bei ppp und schon gehts erst mal fuer testzwecke. nun schlage ich mich aber seit mehr als einem tag arbeitszeit damit herum, dass meine voip-verbindung zustande kommt. da es vorher so gut unter monowall funktioniert hat, habe ich mir dort die konfiguration gespeichert und diese mittels abtippen direkt wieder bei iptables aufgebaut - ohne erfolg.

erster versuch: kein rauswaehlen moeglich, fritzbox kann voip-nummer nicht registrieren

dann hab ich was per google gefunden, dass es nette kernelmodule dafuer gibt marke: nf_conntrack_sip und ip_nat_sip ... die beiden module habe ich geladen und tada, jetzt habe ich mit meiner alten konfiguration die moeglichkeit jemanden via voip anzurufen. ... dooferweise hoert man weder auf der einen noch auf der anderen seite etwas.

auch dafuer hat google einige loesungen parat gehalten, leider haben ALLE nicht funktioniert und bei mehr als 24h arbeitszeit an dem thema, habe ich auch etliche davon ausprobiert. anhand von iptraf, tcpdump/wireshark und rtpbreak habe ich meine konfiguration noch etwas optimieren koennen, allerdings gibt es keinerlei gedropte pakete. anhand der tools kann ich auch klar und deutlich erkennen, dass es zu einem hin- und rueckaufbau von rtp-verbindungen kommt, die in der paketzahl (mittels iptables-regel ausgelesen) auch kraeftig steigen wenn ich gerade in so einem ich-hoer-mich-nicht-du-hoerst-mich-nicht-gespraech bin. auch wenn mir ein techniker von 1und1 gesagt hat, dass man fuer die fbox nur die ports 5070-5097, 3478 und 30000-30019 benoetigt, habe ich nach erfolglosem test danach auch noch die anderen ports weitergeleitet, die mit der voip-kommunikation in verbindung stehen. leider auch ohne erfolg.

gegentest: softphone(kphone) mit sipgate-account von der workstation aus: ergebnis:
ich starte das softphone und habe noch gar keine regeln in PREROUTING gesetzt, schon fragt mich kphone nach meinem passwort. ein wenig erstaunt, da ich davon ausgegangen bin, dass das anmelden auch schon ueber portforwarding laeuft, habe ich dann so getestet > niemand hoert jemanden. wenn ich nun aber den stunport in PREROUTING auf die workstation weiterleite, habe ich zumindest ergebnis, dass der angerufene die toene meiner workstation hoeren kann, umgekehrt aber nicht. ...
mit dem wissen bin ich dann wieder an die fritzbox gegangen, in der hoffnung, dass ein weitergeleiteter stunport mri zumindest one-way-kommunikation erlaubt, doch auch das hat nichts gebracht. unabhaengig vom portforward in PREROUTING habe ich trotzdem die moeglichkeit jemanden anzurufen, wobei niemand den anderen hoeren kann ...
ich tipoe darauf, dass es in POSTROUTING ein problem mit MASQUERADE gibt, wobei ich im moment den wald vor lauter baeumen nicht mehr sehe. ich waere euch echt dankbar, wenn mir jemand einfach eine funktionierende iptables-config hier posten koennte, so dass ich mal gegenpruefen kann, was ich vergessen habe.

mit freundlichen gruessen,
skamp
 
Zuletzt bearbeitet:
Hallo,

erst mal grundsätzlich: Einen STUN Server hast du drin in der Box?

Dann kann ich dir hier:
Howto: Mein Telefon klingelt nicht bei ankommenden Anrufen?
das Kapitel Sonderfall VoIP Telefonie: Betrieb einer Box als WDS Client oder im Betrieb "Internet über LAN"
empfehlen. Dort sind auch die korrekten Ports der Box aufgeführt, die oben genannten gehören zum 1&1 Softphone. :shock:
 
und der frust geht weiter ...

hey frank,

erst mal besten dank fuer deine rasche antwort und respekt, was du da schon an knowhow zusammengefasst hast. brauchte einige zeit, um mich durch die posts zu lesen. jetzt die schlechte nachricht: obwohl ich fleissig alles aus den posts gelesen und mich danach gerichtet habe, habe ich immer noch keinen erfolg beim 'sprechen+hoeren' bei einer voip-verbindung. ich habe jeden test jetzt noch um das kurzzeitige rebooten der fritzbox + conntrack-verbindungen-loeschen bei linux erweitert, um sicher zu stellen, dass keine alten nat-tabellen neue tests behindern, aber auch hiermit ueberhaupt kein erfolg.

ich habe jetzt auf deine anfrage noch mal in der fritzbox den stun-server von gmx explizit angegeben durch umschalten auf "andere anbieter". was ich da noch wissen moechte:
muss der port fuer den stunserver (3478) evtl. auch noch nen forward erhalten? hab leider nirgendwo dazu was gefunden, was entweder heisst, dass dem einfach nicht so ist, oder das es jeder fuer selbstverstaendlich nimmt.

kurios war dann folgendes:
ich habe mir erneut die pakete mittels wireshark angeschaut und habe etwas gefunden, was mich sofort an einen post von gfuer erinnert hat und zwar bekomme ich beim rtp-aufbau folgende mitschnitte:

100 7.990918 192.168.178.2 212.227.15.231 UDP Source port: 7078 Destination port: 18672

104 8.048725 212.227.15.231 192.168.178.2 ICMP Destination unreachable (Port unreachable)

schaue ich mir die verbindung mit rtpbreak an, so sehe ich zwei rtp-verbindungen (eingehend, ausgehend), in der fleissig daten hochlaufen. das kann ich mit wireshark nun auch belegen, da die erste genannte verbindung ziemlich viele dieser pakete losschickt, die zweite lediglich ein paar mal auftritt, was aber bei fehlermeldungen auch vollkommen normal ist.
um noch mal auf den post von gfuer zurueckzukommen:

kurzfassung:
macht er portforward an, haben seine ausgehenden pakete den quellport 6060, die avm als loesung des problems in verbindung mit port-forward angibt.

macht er portforward aus, haben seine ausgehenden pakete irgendwas dynamisches im oberen portbereich ...

so, auch wenn das nun gar nicht mein problem ist, da meine sip-verbindung ja zustande kommt, muss ich betonen, dass ich diese forwards von avm eingerichtet habe und trotzdem laeuft nichts ueber den port 6060. wireshark:

35 4.865436 192.168.178.2 212.227.15.231 UDP Source port: sip Destination port: sip
36 4.936395 212.227.15.231 192.168.178.2 SIP Status: 407 Proxy Authenti
37 4.940582 192.168.178.2 212.227.15.231 UDP Source port: sip Destination port: sip
38 4.960641 192.168.178.2 212.227.15.231 UDP Source port: sip Destination port: sip

in diesen vier paketen findet der komplette sip-sessionaufbau statt. inhalte der pakete sind folgende:

INVITE sip:EINENUMMER@sipSIP/2.0 407 Proxy AuthentiACK sip:EINENUMMER@sip.gmINVITE sip:EINENUMMER@sipSIP/2.0 100 trying -- yourSIP/2.0 183 Session ProgreSIP/2.0 180 Ringing

(nachfolgendes kommt, wenn ich die session wieder abbaue durch auflegen)
Via: SIP/2.0 200 OK

Via: SIP/2ACK sip:EINENUMMER@subscBYE sip:EINENUMMER@subscSIP/2.0 200 OK Via: SIP/2

Ebensowenig habe ich irgendwelchen traffic ueber die rtp-ports 6078-6097, welche avm als forward-ports fuer die eigentlichen rtp 7078-7097 angibt. auch hier findet die kommunikation, wie oben schon dargestellt, nur ueber die 7078 statt, wobei das reply dann aus irgendeinem grund nicht mehr ankommt.

steh echt aufm schlauch

Gruesse,
Uwe

EDIT:

Was ich noch vergessen hab zu protokollieren:

Hier die STUN-Anfrage:

Internet Protocol, Src: 192.168.178.2 (192.168.178.2), Dst: 212.227.15.200 (212.227.15.200)
User Datagram Protocol, Src Port: sip (5060), Dst Port: nat-stun-port (3478 )

Internet Protocol, Src: 212.227.15.200 (212.227.15.200), Dst: 192.168.178.2 (192.168.178.2)
User Datagram Protocol, Src Port: nat-stun-port (3478 ), Dst Port: sip (5060)

Internet Protocol, Src: 192.168.178.2 (192.168.178.2), Dst: 212.227.15.200 (212.227.15.200)
User Datagram Protocol, Src Port: 7078 (7078 ), Dst Port: nat-stun-port (3478 )

Internet Protocol, Src: 212.227.15.200 (212.227.15.200), Dst: 192.168.178.2 (192.168.178.2)
User Datagram Protocol, Src Port: nat-stun-port (3478 ), Dst Port: 7078 (7078 )

Internet Protocol, Src: 192.168.178.2 (192.168.178.2), Dst: 212.227.15.200 (212.227.15.200)
User Datagram Protocol, Src Port: 7079 (7079), Dst Port: nat-stun-port (3478 )

Internet Protocol, Src: 212.227.15.200 (212.227.15.200), Dst: 192.168.178.2 (192.168.178.2)
User Datagram Protocol, Src Port: nat-stun-port (3478 ), Dst Port: 7079 (7079)
 
Zuletzt bearbeitet:
Hallo,

muss der port fuer den stunserver (3478) evtl. auch noch nen forward erhalten?
Nein. Das war bei mir nie erforderlich.

100 7.990918 192.168.178.2 212.227.15.231 UDP Source port: 7078 Destination port: 18672

104 8.048725 212.227.15.231 192.168.178.2 ICMP Destination unreachable (Port unreachable)
Hmm. Destination Port 18672. Da wäre interessant zu wissen, wie die Box ausgerechnet auf diesen Port verfällt. Wurde der vorher im SIP Handshake irgendwie ausgehandelt? Und warum schickt sie die RTP Daten an den SIP Server? Ich hab solche Logs nie im Detail analysiert, aber ich hätte erwartet, die gehen direkt an den VoIP Peer. Wohin hast du angerufen? Eine Handy oder Festnetz-Nummer? Vielleicht wird dann über diese IP auch das VoIP<->PSTN Gateway erreicht.
Welche Ports nutzt denn die 2. RTP Verbindung? Und welchen Ziel-Server?

kurzfassung:
macht er portforward an, haben seine ausgehenden pakete den quellport 6060, die avm als loesung des problems in verbindung mit port-forward angibt.
Ja, aber das ist der Quell-Port. Bei dir macht mich der Destination Port stutzig. Der Quell-Port sollte egal sein und mit STUN Unterstützung korrekt ausgehandelt werden.

so, auch wenn das nun gar nicht mein problem ist, da meine sip-verbindung ja zustande kommt, muss ich betonen, dass ich diese forwards von avm eingerichtet habe und trotzdem laeuft nichts ueber den port 6060. wireshark:
Da kommt es natürlich sehr auf die Implementierung der Firewall an, wie sie solche ausgehenden Pakete handhabt. Außerdem stellt sich die Frage, ob der Wireshark-Log auch den abgehenden Port auf deiner öffentlichen IP loggt. Den sehe ich dort nicht, sondern nur die Pakete auf der LAN Seite der NAT Behandlung.

auch hier findet die kommunikation, wie oben schon dargestellt, nur ueber die 7078 statt, wobei das reply dann aus irgendeinem grund nicht mehr ankommt.
Ich glaube nicht, dass das Replay das Problem ist. Der Server lehnt das ankommende Paket bereits mit einem "ICMP not reachable" ab.

Die Frage, die wir also klären müssen, ist folgende: Wie kommt die Box auf die Idee, die abgehenden RTP Pakete an den Destination Port 18672 zu schicken? Denn die lehnt der Server ab.
 
So, nabend noch mal ... sorry, dass ich erst so spaet antworte, aber da ich mir die naechsten zwei tage einen kurzurlaub goenne, gab es noch einiges dafuer vorzubereiten. also:

Hmm. Destination Port 18672. Da wäre interessant zu wissen, wie die Box ausgerechnet auf diesen Port verfällt. Wurde der vorher im SIP Handshake irgendwie ausgehandelt? Und warum schickt sie die RTP Daten an den SIP Server?

Der Port wird definitiv nicht ueber den SIP-Handshake ausgehandelt. Ich gehe davon aus, dass dies ein Port ist, der via STUN ausgehandelt wurde. Hier noch mal beteiligte IPs mit Zuordnung:

PING sip-gmx.net (212.227.15.197) 56(84) bytes of data.
64 bytes from sipbalance0.schlund.de (212.227.15.197): icmp_seq=1 ttl=54 time=50.9 ms

alternativ:
PING sip-gmx.schlund.de (212.227.15.231) 56(84) bytes of data.
64 bytes from sipbalance1.schlund.de (212.227.15.231): icmp_seq=1 ttl=54 time=31.4 ms

stun:
PING stun.gmx.net (212.227.15.200) 56(84) bytes of data.
64 bytes from stun.schlund.de (212.227.15.200): icmp_seq=1 ttl=54 time=33.5 ms

Wohin hast du angerufen? Eine Handy oder Festnetz-Nummer? Vielleicht wird dann über diese IP auch das VoIP<->PSTN Gateway erreicht.
Welche Ports nutzt denn die 2. RTP Verbindung? Und welchen Ziel-Server?

Ich habe eine Festnetznummer angerufen.
Die zweite RTP-Verbindung hat die gleichen Ports wie die erste, da sie das beobachtende Interface (in diesem Fall eth0, sprich die interne netzwerkkarte) in eingehend und ausgehend trennt. Es ist also letztendlich die gleiche Verbindung.

... abgehenden Port auf deiner öffentlichen IP ...

Sorry, hab in meinem Frust total verpennt, den Log-Auszug hier noch zu posten:

hier schickt der PSTN-Gateway mir RTP-Daten (ich bin also: 84.132...):
124 5.043039 87.234.1.69 84.132.6.143 UDP Source port: 27266 Destination port: 7078

Daten zu dem PSTN sind hier:

~ $ whois 87.234.1.69

## Ausgabe gekuerzt ##
inetnum: 87.234.1.0 - 87.234.1.255
netname: QSC-VOIP-5
descr: QSC AG
descr: Internal Network Infrastructure
country: DE
## Ausgabe gekuerzt ##

folgende antwort wird daraufhin von meiner leitung weggeschickt:

125 5.048307 84.132.6.143 212.227.15.231 UDP Source port: 7078 Destination port: 27266
hier schicke ich also RTP-Daten an den SIP-Server ... Ich vermute jetzt einfach mal, dass das noetig ist, um die Daten dann weiter an den QSC-Server zwecks Relay ins Festnetz, zu reichen. Aber alles nur Spekulation :confused:

jetzt das boese erwachen:

128 5.073856 212.227.15.231 84.132.6.143 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture]

Da es ICMP ist, hat es auch gleich eine ausfuehrlichere Fehlermeldung im Paket enthalten und zwar folgende:

Internet Protocol, Src: 84.132.6.143 (84.132.6.143), Dst: 212.227.15.231 (212.227.15.231)
User Datagram Protocol, Src Port: 7078 (7078), Dst Port: 27266 (27266)
... unser zuvor erstelltes und losgeschicktes paket kommt nicht an :mad:


Weiterfuehrend bin ich jetzt also so an die Sache gegangen, dass ich per NAT gesagt habe, dass Pakete, die hier mit SourcePort 7078:7097 ausgehen auch bitte nur auf den gleichen ports bei dem sip-server von gmx landen -> ohne erfolg, wobei doch eine veraendung zu merken war und zwar kann jetzt das telefonat nicht mal mehr mit sip signalisiert werden und ich bekomme sehr schnell ein besetzt-zeichen. meldung der box: ... war nicht erfolgreich, fehler 503. Was, wenn man nachschlaegt ein DNS-Fehler ist.

naechster versuch:
um ein stun-problem auszuschliessen, habe ich diesen kurzfristig einfach mal komplett deaktiviert und versucht alles ueber portforwards zu machen ... ergebnis: siehe erster versuch ... auch hier hab ich vorher alle conntrack-eintraege geloescht und die box kurz neugestartet, um eine art memory-effekt der firewall zu unterbinden. kleiner etappensieg ist hier, dass man als schlussfolgerung daraus schliessen lassen kann, dass stun in meiner situation durchaus notwendig scheint und das stun weitergehend vorsieht, dass ich bitte nicht mit dem sip-server auf port 7078 sprechen soll. Warum das so ist, werde ich heute abend wohl nicht mehr rausfinden.

wenn mich weiterhin kein geistesblitz ereilt, werde ich versuchen wireshark-logs von leuten mit funktionierden konfigurationen gegen meine zu pruefen, um dann entsprechend die portforwardings nachzubilden. des weiteren werde ich ueberpruefen, wie eine voip2voip-verbindung auf paketebene aussieht, welche server dort involviert sind und schlussendlich muss ich dann noch mal einen abschlussbericht meiner tests verfassen, welcher dann noch mal den weg zu avm geht und zum gmx-support geht, um dort hoffentlich auch noch mal hilfestellung zu bekommen.

So, angenehme Bettruhe und danke schon mal im Voraus. Vielleicht faellt dir ja noch mal was ein

ps: gross- und kleinschreibung beherrsche ich um diese uhrzeit leider nicht mehr :alt:
 
geloest

moin zusammen,

nach mittlerweile ueber zwei wochen nervenaufreibender arbeit an diesem thema, habe ich nun eine loesung gefunden und moechte sie nicht vorenthalten.

zunaechst einmal muss ich hier noch einiges angeben und zwar:

# benutzer kernel: 2.6.22 (vserver-sources)

wie ich in einem der oberen posts schon mal geschrieben habe, gibt es seit einiger zeit die module nf_conntrack_sip und damit verbunden das modul ip_nat_sip. diese module sind echt hilfreich, wenn man einen anbieter hat, dessen sip-server die gleiche ip hat, wie der server, der den voice-stream via rtp annimmt. in meinem fall ist der anbieter gmx und da ist es eben nicht so, dass fuer alles, der gleiche server verwendet wird. in dem fall, dass die verbindungen verschiedene wege gehen, hilft das modul nf_conntrack_sip nicht nur nicht, sondern es ist sogar hinderlich und verhindert den rtp-stream-aufbau!
naeheres dazu hier:
http://www.gossamer-threads.com/lists/iptables/user/63445
und hier:
http://lists.opensuse.org/opensuse-bugs/2008-02/msg01037.html

dazu gibt es zwei loesungen. die erste ist relativ simpel und lautet: benutzt in so einem fall einfach das modul nicht! ... die zweite loesung ist, dass man das entsprechende kernelmodul patched. wie das funktioniert und was dadurch besser wird, findet man hier:
http://lwn.net/Articles/271597/

so, wenn jetzt also dadurch schon mal eine fehlerquelle ausgeschlossen ist, man mit einer ansonsten guten firewallconfig aber immer noch nichts hoert, koennte es daran liegen, dass einem das modul nf_conntrack_h323 fehlt. unabhaengig davon, dass man ja eigentlich SIP anstatt H323 benutzt, steckt in dem modul nf_conntrack_h323 die unterstuetzung fuer RTP und RTCP, welche man braucht. sowas findet man dann, wenn man sich die doku zu den einzelnen modulen durchliest.

damit waere die kernelconfig jetzt schon mal komplett an meinen voipanbieter gmx angepasst.

die entsprechenden zeilen in meiner firewall sehen dann bei mir folgendermassen aus (auch wenn sie derzeit noch mit allen voip-ports, die ich jemals gefunden habe, ueberladen ist):
modprobe nf_conntrack_h323

# allow voip
SIPPORT="5004 5005 5006 5007 5008 5009 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7096 7097 10000"
for pt in $SIPPORT; do
$IPT -A FORWARD -s $FRITZBOX -p udp --dport $pt -j ACCEPT
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --sport $pt -j DNAT --to $FRITZBOX:$pt
done

damit funktionierts und ich hoffe, das hilft vielleicht auch noch der ein oder anderen gequaelten seele.

auch noch mal herzlichen dank an frank, der mir hier anfangs mit viel muehe, rat und tat zur seite stand. :bier:

Gruss,
Uwe
 
Zuerstmal: Danke für diese hervorragende Hilfe!

Kernel: 2.6.33.4

SIPgate mit der Fritzbox läuft bei mir nur, wenn man in der vorhergehenden Anleitung "sport" in "dport" ersetzt. Mit "sport" war es bei mir gleich als wenn man gar keine Regeln neben MASQUERADE setzt: Man konnte durchs nf_conntrack_h323 an der Fritzbox über Sipgate angerufen werden aber nicht rausrufen. Mit nf_conntrack_h323 und dem besagten dport statt sport läuft das Rausrufen mit der Fritzbox über Sipgate bei mir nun auch.

Da DNAT im PREROUTING in der Reichenfolge vor MASQUERADE im POSTROUTING arbeitet, muss man MASQUERADE sagen dass es die Source IP nach innen nicht ändern darf. Die Fritzbox ignoriert ansonsten die UDP Pakete, da sie immer nur die Absender IP von eurem Linux und nicht die echten aus dem im Internet sieht. Darum muss man explizit sagen dass nur beim Rausschicken über das externe Interface das MASQUERADE durchgeführt werden darf:

Falsch:
$IPT -t nat -A POSTROUTING -j MASQUERADE
Richtig:
$IPT -t nat -A POSTROUTING -j MASQUERADE -o $EXTIF

Bei mir sieht das ganze also folgendermaßen aus:

modprobe nf_conntrack_h323
rmmod nf_conntrack_sip
TROUTING -j MASQUERADE -o $EXTIF
# allow voip
SIPPORT="5004 5005 5006 5007 5008 5009 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7096 7097 10000"
for pt in $SIPPORT; do
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport $pt -j DNAT --to $FRITZBOX:$pt
done

Das Telefonieren mit einem Softphone mit SIpgate hatte bei mir mit beliebigen Softphone (der ganze Counterpathmüll oder auch 3cx) bei MASQUERADE nach dem rausschmeissen von nf_conntrack_sip und dem laden von nf_conntrack_h323 sofort geklappt. Ist schon komisch dass die Fritzbox nur mit den UDP DNATS läuft.....

Ich hoffe dass nf_conntrack_sip bald mal ordentlich gefixed wird... noch besser wäre es natürlich SIP durch ein anständiges Protokoll zu ersetzen... das is ja noch schlimmer als bei FTP... :p

Viele Grüße
Markus
http://projekte.priv.de/
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
244,808
Beiträge
2,218,758
Mitglieder
371,494
Neuestes Mitglied
msh7
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.