ALL-IP Anschluss Telekom VoiP MikroTik mit VLAN Konfiguration
Hallo zusammen,
ich bin momentan etwas ratlos meine 2 Telefone zum Laufen zu bekommen.
Mein MikroTik Routerboard verbindet sich via PPPoE an eth1 zu meinem FTTH Anschluss der Telekom.
Via sfp1 habe ich meinen Netgear Switch angeschlossen.
Aktuell ist an g11 des Switches meine Dect Basisstation (Gigaset C430A GO) angeschlossen und in VLAN10 konfiguriert. (IP 10.0.1.12 via DHCP)
Die internen Netzwerkgeräte (z.B. Laptop) kommen auf die Basisstation und ich konnte dort auch erfolgreich meine Rufnummern mit der Telekom verbinden.
Am MikroTik habe ich die Service Ports (unter IP->Firewall) für sip deaktiviert (wobei egal ob aktiviert - geht dennoch nicht).
Nun habe ich eigentlich "nur" das Problem, dass weder ich den Anrufer höre, noch der Anrufer mich.
Eingehende Anrufe kommen an den Telefonen an und ich kann auch nach außen telefonieren (z.B. Handy).
Für die Sprachübergabe ist wohl das RTP Protokoll zuständig, nur habe ich mit Firewall Regeln keinen Erfolg gehabt.
Folgende Mangles habe ich eingerichtet:
Im Log File erhalte ich beim Anrufen folgenden Eintrag:
In der Dect Station ist der SIP Port 5060, RTP auf 5004 - 5020 eingestellt. STUN Server ist bei den Telefonie Einstellungen aktiv mit stun.t-online.de Port 3478
Ich bin ehrlich gesagt etwas ratlos - ist das Problem evtl. dass ich die Basistation nicht direkt am Router eingestöpselt habe, sondern über den Switch mit VLAN tagging gehe?
Vielen Dank für mögliche Hinweise zur Lösung
ich bin momentan etwas ratlos meine 2 Telefone zum Laufen zu bekommen.
Mein MikroTik Routerboard verbindet sich via PPPoE an eth1 zu meinem FTTH Anschluss der Telekom.
Via sfp1 habe ich meinen Netgear Switch angeschlossen.
Aktuell ist an g11 des Switches meine Dect Basisstation (Gigaset C430A GO) angeschlossen und in VLAN10 konfiguriert. (IP 10.0.1.12 via DHCP)
Die internen Netzwerkgeräte (z.B. Laptop) kommen auf die Basisstation und ich konnte dort auch erfolgreich meine Rufnummern mit der Telekom verbinden.
Am MikroTik habe ich die Service Ports (unter IP->Firewall) für sip deaktiviert (wobei egal ob aktiviert - geht dennoch nicht).
Nun habe ich eigentlich "nur" das Problem, dass weder ich den Anrufer höre, noch der Anrufer mich.
Eingehende Anrufe kommen an den Telefonen an und ich kann auch nach außen telefonieren (z.B. Handy).
Für die Sprachübergabe ist wohl das RTP Protokoll zuständig, nur habe ich mit Firewall Regeln keinen Erfolg gehabt.
Folgende Mangles habe ich eingerichtet:
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=accept protocol=tcp dst-address=10.0.1.12 dst-port=5060 log=yes
1 ;;; voip rtp
chain=forward action=accept protocol=udp dst-address=10.0.1.12 src-port=3478 dst-port=5004-5020 log=yes
Im Log File erhalte ich beim Anrufen folgenden Eintrag:
forward: in:Telekom out:vlan10, src-mac 84:b2:61:7f:bb:51, proto UDP, 217.0.0.143:3478->10.0.1.12:5008, NAT 217.0.0.143:3478->(84.158.172.28:5008->10.0.1.12:5008), prio 6->0, len 84
In der Dect Station ist der SIP Port 5060, RTP auf 5004 - 5020 eingestellt. STUN Server ist bei den Telefonie Einstellungen aktiv mit stun.t-online.de Port 3478
Ich bin ehrlich gesagt etwas ratlos - ist das Problem evtl. dass ich die Basistation nicht direkt am Router eingestöpselt habe, sondern über den Switch mit VLAN tagging gehe?
Vielen Dank für mögliche Hinweise zur Lösung
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 337516
Url: https://administrator.de/forum/all-ip-anschluss-telekom-voip-mikrotik-mit-vlan-konfiguration-337516.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
11 Kommentare
Neuester Kommentar
Heyho.
Also,
erstens sind Mangle-Rules hier absolut fehl am Platz. Zweitens benötigst du auf deiner Firewall nur eine Established,Related Regel für FORWARD und INPUT und die SIP-Leitung 5060TCP mit DSTNAT auf die DECT Station.
Der Sinn und Zweck von STUN ist es ja gerade das du auf der Firewall keine explizite Freigabe der RTP (UDP) Pakete benötigst, denn das erledigt das STUN indem es mit ausgehenden Paketen diese benötigten Ports quasi von innen her öffnet, woraufhin die RELATED,ESTABLISHED Regel anspringt und die Pakete auf diesen Ports reinlässt.
Drittens die IP für die DECT ist per DHCP zugewiesen? Dann stelle bitte sicher das du eine MAC-Reservation für die DECT eingerichtet hast sonst würde die Portweiterleitung irgendwann ins Leere laufen.
Das VLAN hat hier damit nichts zu tun.
Aber eine exportierte Mikrotik Config ist hier wie immer sehr willkommen.
Gruß
Also,
erstens sind Mangle-Rules hier absolut fehl am Platz. Zweitens benötigst du auf deiner Firewall nur eine Established,Related Regel für FORWARD und INPUT und die SIP-Leitung 5060TCP mit DSTNAT auf die DECT Station.
Der Sinn und Zweck von STUN ist es ja gerade das du auf der Firewall keine explizite Freigabe der RTP (UDP) Pakete benötigst, denn das erledigt das STUN indem es mit ausgehenden Paketen diese benötigten Ports quasi von innen her öffnet, woraufhin die RELATED,ESTABLISHED Regel anspringt und die Pakete auf diesen Ports reinlässt.
Drittens die IP für die DECT ist per DHCP zugewiesen? Dann stelle bitte sicher das du eine MAC-Reservation für die DECT eingerichtet hast sonst würde die Portweiterleitung irgendwann ins Leere laufen.
Das VLAN hat hier damit nichts zu tun.
Aber eine exportierte Mikrotik Config ist hier wie immer sehr willkommen.
Gruß
Die Regeln sind nicht richtig.
Sie sollten eher algemeiner so lauten denn sie müssen ja auch für die RTP(UDP) Packets gelten!:
Denn das dstnat und die Ports schränken diese zu sehr ein.
Sie sollten eher algemeiner so lauten denn sie müssen ja auch für die RTP(UDP) Packets gelten!:
/ip firewall filter add chain=forward action=accept connection-state=established,related
Tja, kein Wunder denn in deiner obigen Config fehlt die eingehende DSTNAT Regel für 5060-5061, die Related regeln sind immer separat zu betrachten (Stichwort: Statefull Firewall und müssen ganz oben stehen, First Match Wins!), du hast anscheinend keine Plan was die Regeln bedeuten oder??
Habe das hier ja am laufen, sonst würde ich das hier nicht erzählen
Viel Erfolg und schönes WE.
Habe das hier ja am laufen, sonst würde ich das hier nicht erzählen
Viel Erfolg und schönes WE.
Zitat von @rogatec:
So verstehe ich das:
input-chain = Pakete die von meinem eth1 (WAN) an den Router gesendet wurden mit einer Ziel-IP in meinem Router Netzwerk
Nein INPUT sind Pakete die direkt an den Router selbst gerichtet sind.So verstehe ich das:
input-chain = Pakete die von meinem eth1 (WAN) an den Router gesendet wurden mit einer Ziel-IP in meinem Router Netzwerk
forward-chain = Pakete, die innerhalb meines Routers verarbeitet werden
Nein. In der FORWARD Chain passieren Pakete die durchgeleitet werden. Egal ob von intern nach extern oder von VLANx zu VLANy. /ip firewall filter add chain=forward action=accept connection-state=established,related
Der Router führt eine Connection-State Tabelle in der er alle Verbindungen von Hosts mit Quelladresse/Port und Zieladresse/Port aufführt. Sobald ein Host eine Verbindung mit einem anderen Host erfolgreich herstellt ist die Verbindung in beide Richtungen freigegeben. Die Einträge haben ein Timeout bei Leerlauf.
Du schreibst mir fehlt die Eingehende DSTNAT Regel. Das interpretiere ich so:
Die ist unnötig da durch den DST-NAT Prozess die Zieladresse schon im PREROUTING umgeschrieben wird, s.u./ip firewall filter add chain=input action=accept connection-nat-state=dstnat port=5060-5061 protocol=tcp
Damit brauch ich aber auch eine NAT Regel, die mir die übergebenen Daten an meine DECT Station weiterleitet.
Richtig , (aber die Adresse wo der Traffic aufläuft hast du darin vergessen, s. https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Forward_all_traffi ... denn du willst ja nur vom WAN NATen)denn der NAT-Prozess wird im PREROUTING durchgeführt und bekommt dort die neue Ziel-Adresse der DECT Station, von dort aus kommt er direkt in die FORWARD-Chain weil die Zieladresse ja nicht mehr die des Routers ist! Deswegen ist es wichtig wenn du die FORWARD-Chain am Ende mit einer generellen BLOCK-Rule blockst du ebenfalls noch eine explizite Regel für die FORWARD Chain benötigst die Traffic an die DECT zulässt./ip firewall nat add chain=dstnat action=dst-nat to-addresses=10.0.5.2 to-ports=5060-5061 protoctol=tcp dst-port=5060-5061
Da es noch nicht funktioniert, nehme ich an, dass ich hier weiterhin aufm Schlauch stehe, oder noch was vergessen habe ;-(
Am besten du schaust dir mal die Grafik für den Packetflow des Mikrotik an, die ist bei den meisten Firewalls sehr ähnlich, diese ist essentiell zum verstehen der Firewall-Regeln.
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Dir fehlt die Forward-Related Regel noch. Aber mit den Regeln kommen die Clients nicht mehr ins Internet falls du den DNS-Proxy des Mikrotik verwendest dann bräuchtest du noch Port 53UDP/TCP im Input.
Denke immer daran beim Mikrotik musst du selbst an alles denken .
So also z.B. jeder Depp per SSH oder Webinterface auf deinen Router kommt. Da ist es nur eine Frage der Zeit bis Zombies deinen Router übernehmen! Deswegen siehst du dort auch den Zähler sehr schnell ansteigen, das ist das Hintergrundrauschen des Web's, und alles was an den Router gerichtet war und verworfen wurde.
Schönes WE
Denke immer daran beim Mikrotik musst du selbst an alles denken .
Verständnisfrage: Warum ist hier die letzte drop Regel zwingend?
Nun, weil der Mikrotik per Default alles rein lässt also die Default-Regel im Gegensatz zu anderen Firewalls ACCEPT ist. Lässt du die Regel weg hast du quasi einen offenen Router der mit dem nackten Arsch im Internet hängt und bei dem er jedes Paket aus dem Internet akzeptiert!So also z.B. jeder Depp per SSH oder Webinterface auf deinen Router kommt. Da ist es nur eine Frage der Zeit bis Zombies deinen Router übernehmen! Deswegen siehst du dort auch den Zähler sehr schnell ansteigen, das ist das Hintergrundrauschen des Web's, und alles was an den Router gerichtet war und verworfen wurde.
Bis hierhin schonmal danke schön
Immer gerne.Schönes WE
Zitat von @rogatec:
Also bisher nutze ich "use peer DNS" bei meinem PPPoE Interface, dann werden unter /ip dns die DNS Server vom Telekom Verteiler(?) automatisch als "Dynamic Servers" angezeigt.
Schon klar aber das meinte ich nicht, deine Clients müssen ja einen DNS-Server zugewiesen bekommen. D.h. du aktivierst den DNS-Proxy am Mikrotik und gibst in den DHCP-Server-Settings die jeweilige IP des Mikrotik in dem jeweiligen Subnetz an!Also bisher nutze ich "use peer DNS" bei meinem PPPoE Interface, dann werden unter /ip dns die DNS Server vom Telekom Verteiler(?) automatisch als "Dynamic Servers" angezeigt.
Die input-chain mit udp & Port 53 habe ich auch mal angelegt - die Filter sehen dann folgendermaßen aus
2 ;;; lan -> dns
chain=input action=accept protocol=udp in-interface=Telekom dst-port=53 log=no log-prefix=""
2 ;;; lan -> dns
chain=input action=accept protocol=udp in-interface=Telekom dst-port=53 log=no log-prefix=""
Die Regel ist natürlich Blödsinn denn deine Clients sollen den Mikrotik fragen nicht die Telekom deinen Mikrotik .
Wenn ich den MikroTik als DNS Server verwenden will, habe ich mir die Anleitung vom Wiki angeschaut
DNS Proxy (Cache) Setup
Mich irritiert hier nur das Beispiel, dass hier ein DNS Server angelegt wird mit der mikrotik.com IP - sollte der Server nicht eine von mir ausgewählte Adresse sein?
Die DNS Servers die ich angebe, sollten dann doch normalerweise in meinem DHCP Server Network Setup auch für meine VLAN-Adressen als DNS Servers hinterlegt werden?
Du brauchst nur unter /ip dns "Allow Remote Requests" anticken. Als Forwarder Adressen bekommt der MK die DNS-Server der Telekom.DNS Proxy (Cache) Setup
Mich irritiert hier nur das Beispiel, dass hier ein DNS Server angelegt wird mit der mikrotik.com IP - sollte der Server nicht eine von mir ausgewählte Adresse sein?
Die DNS Servers die ich angebe, sollten dann doch normalerweise in meinem DHCP Server Network Setup auch für meine VLAN-Adressen als DNS Servers hinterlegt werden?
Ich vermute, dass mir trotz der input-chain von Port 53 noch eine Regel fehlt, denn so schliesse ich alle Geräte hinterm Netzwerk aus
s.o. deine Regel ist falsch, die Regeln sollte so aussehen/ip firewall filter
add chain=input action=accept protocol=udp in-interface=!Telekom dst-port=53
add chain=input action=accept protocol=tcp in-interface=!Telekom dst-port=53
DNS ist aber immer UDP und TCP.
Netzwerkgrundlagen ...