Problem Cisco 926 4P VoiP SnomD713 SIP eingehen ausgehend keine Telefonie und Uhrzeit Problem
Hallo,
ich störe nur ungern aber habe ein Problem mit nem Cisco ROuter und SNOM D713 Telefon was betrieben werden soll.
Ich habe eine Zone Based Firewall und die Config kann ich euch geben genauso wie die Ausgabe der CLI das geblockt wird.
Könnt Ihr mir weiterhelfen weil ich nicht weiterkomme.
In der obigen Anleitung konnte ich nicht genau herausfinden was ich machen muss aber SIP ist grundlegend nicht geblockt oder liege ich falsch?
Gleichzeitig habe ich beim hochladen der letzten Firmeware festgestellt dass die Zeit nicht passt , aber mit den Befehlen welche ich ausprobiert habe konnte ich das Problem nicht beheben und die Zeit stimmt immer noch nicht wäre toll wenn mir auch da jmd. helfen könnte.
Hier die Config
Gruß Mario
ich störe nur ungern aber habe ein Problem mit nem Cisco ROuter und SNOM D713 Telefon was betrieben werden soll.
Ich habe eine Zone Based Firewall und die Config kann ich euch geben genauso wie die Ausgabe der CLI das geblockt wird.
Könnt Ihr mir weiterhelfen weil ich nicht weiterkomme.
https://administrator.de/tutorial/cisco-800-900-isr1100-router-konfiguration-mit-xdsl-kabel-ftth-anschluss-und-vpn-179345.html
In der obigen Anleitung konnte ich nicht genau herausfinden was ich machen muss aber SIP ist grundlegend nicht geblockt oder liege ich falsch?
Gleichzeitig habe ich beim hochladen der letzten Firmeware festgestellt dass die Zeit nicht passt , aber mit den Befehlen welche ich ausprobiert habe konnte ich das Problem nicht beheben und die Zeit stimmt immer noch nicht wäre toll wenn mir auch da jmd. helfen könnte.
Hier die Config
*May 17 12:06:45: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:46: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:47: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:49: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:53: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:57: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:01: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:05: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:09: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:13: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:17: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
Cisco_Router#sh ver
Cisco IOS Software, C900 Software (C900-UNIVERSALK9-M), Version 15.9(3)M11, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2025 by Cisco Systems, Inc.
Compiled Thu 20-Mar-25 03:13 by mcpre
ROM: System Bootstrap, Version 15.8(3r)M0b, RELEASE SOFTWARE (fc1)
Cisco_Router uptime is 6 hours, 42 minutes
System returned to ROM by power-on
System image file is "flash:c900-universalk9-mz.SPA.159-3.M11.bin"
Last reload type: Normal Reload
Last reload reason: power-on
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco C926-4P (revision 1.0) with 994825K/53750K bytes of memory.
Processor board ID FGL2551L05S
1 DSL controller
1 Ethernet interface
5 Gigabit Ethernet interfaces
1 ATM interface
1 Virtual Private Network (VPN) Module
256K bytes of non-volatile configuration memory.
1900544K bytes of SD Flash flash (Read/Write)
License Info:
License UDI:
-------------------------------------------------
Device# PID SN
-------------------------------------------------
*1 C926-4P SERIENNNUMMER
Technology Package License Information for Module:'c900'
------------------------------------------------------------------------
Technology Technology-package Technology-package
Current Type Next reboot
------------------------------------------------------------------------
ipbase ipbasek9 Permanent ipbasek9
security securityk9 Permanent securityk9
appx None None None
Configuration register is 0x2102
Cisco_Router#show conf
Using 6373 out of 262144 bytes
!
version 15.9
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime localtime
service password-encryption
!
hostname Cisco_Router
!
boot-start-marker
boot system flash:c900-universalk9-mz.SPA.159-3.M11.bin
boot-end-marker
!
!
enable secret 9 XXXXXX
!
aaa new-model
aaa local authentication attempts max-fail 3
!
!
aaa authentication login default local
!
!
!
!
!
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
!
!
!
no ip source-route
no ip gratuitous-arps
!
!
!
ip dhcp excluded-address 192.168.100.1 192.168.100.149
ip dhcp excluded-address 192.168.100.200 192.168.100.254
ip dhcp excluded-address 172.16.100.1 172.16.100.149
ip dhcp excluded-address 172.16.100.200 172.16.100.254
!
ip dhcp pool Lokal
network 192.168.100.0 255.255.255.0
default-router 192.168.100.254
dns-server 192.168.100.254
domain-name mario.domain
!
ip dhcp pool Gastnetz
network 172.16.100.0 255.255.255.0
default-router 172.16.100.254
dns-server 172.16.100.254
domain-name mario.domain
!
!
!
ip domain name mario.domain
ip cef
ipv6 unicast-routing
ipv6 dhcp pool DHCPv6
!
ipv6 cef
!
multilink bundle-name authenticated
!
!
!
license udi pid C926-4P sn FGL2551L05S
!
!
username admin privilege 15 secret 9 XXXXXX
!
redundancy
!
!
!
!
!
controller VDSL 0
firmware filename flash:c900_VA_A_39x3_B_39x3_26d.bin
!
!
class-map type inspect match-any LOKAL-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol sip
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-any GAST-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol ntp
class-map type inspect match-all IPsec_VPN
match access-group name ISAKMP_IPSEC
class-map type inspect match-any ROUTER-PROTOCOLS
match class-map IPsec_VPN
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect LOKAL-INTERNET-POLICY
description Traffic Lokales LAN zum Internet
class type inspect LOKAL-ERLAUBT
inspect
class class-default
drop
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Router zum Internet
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
policy-map type inspect GAST-INTERNET-POLICY
description Traffic Gast zum Internet
class type inspect GAST-ERLAUBT
inspect
class class-default
drop
policy-map type inspect INTERNET-ROUTER-POLICY
description Traffic Internet zum Router
class type inspect IPsec_VPN
pass
class class-default
drop
!
zone security LOKAL
zone security GAST
zone security INTERNET
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
service-policy type inspect LOKAL-INTERNET-POLICY
zone-pair security GAST-INTERNET source GAST destination INTERNET
service-policy type inspect GAST-INTERNET-POLICY
zone-pair security INTERNET-ROUTER source INTERNET destination self
service-policy type inspect INTERNET-ROUTER-POLICY
zone-pair security ROUTER-INTERNET source self destination INTERNET
service-policy type inspect ROUTER-INTERNET-POLICY
!
!
!
!
!
!
!
!
!
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface Ethernet0
no ip address
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0
no ip address
!
interface GigabitEthernet1
no ip address
!
interface GigabitEthernet2
no ip address
!
interface GigabitEthernet3
description Gastnetz
no ip address
no cdp enable
!
interface GigabitEthernet4
no ip address
shutdown
duplex auto
speed auto
!
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security LOKAL
ip tcp adjust-mss 1448
ipv6 address provider-v6-prefix ::1:0:0:0:1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6
!
interface Vlan2
description Gastnetz
ip address 172.16.100.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security GAST
ip tcp adjust-mss 1448
ipv6 address provider-v6-prefix ::2:0:0:0:1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6
!
interface Dialer0
description DSL Internet Interface
mtu 1488
ip address negotiated
ip access-group bockext in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
zone-member security INTERNET
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 verify unicast reverse-path
ppp authentication pap callin
ppp pap sent-username DSL@PROVIDER.DE password 7 XXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip dns server
ip nat inside source list 101 interface Dialer0 overload
!
ip access-list extended ISAKMP_IPSEC
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
ip access-list extended blockext
remark offene TCP Verbindungen dr
remark offene TCP Verbindungen durchlassen
permit tcp any any established
remark DNS Port beide Protokolle, blockieren
deny tcp any any eq domain
deny udp any any eq domain
remark Rest erlauben
permit ip any any
!
!
!
tftp-server flash:/firmware/vadsl_module_img.bin
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 101 permit ip 172.16.100.0 0.0.0.255 any
!
!
!
control-plane
!
banner motd ^CCCC
LOGIN AUF DIESEN ROUTER OHNE GENEHMIGUNG STRAFBAR AUCH JEG: VERSUCH . ALLES ANDE RE AUCH!!!
NO LOGIN IS ALLOWED OR USING OF THIS ROUTER!
^C
!
line con 0
line vty 0 4
transport input none
!
scheduler allocate 20000 1000
!
end
Gruß Mario
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator colinardo am 24.05.2025 um 07:32:59 Uhr
Konfiguration in Codetags gesetzt.
Content-ID: 673009
Url: https://administrator.de/forum/problem-cisco-926-4p-voip-snomd713-sip-eingehen-ausgehend-keine-telefonie-und-uhrzeit-problem-673009.html
Ausgedruckt am: 15.07.2025 um 15:07 Uhr
32 Kommentare
Neuester Kommentar
Moin Mario,
vorab: könntest Du Deine Config bitte über die Beitrag bearbeiten Funktion in CODE-Tags setzen, das erhöht die Lesbarkeit erheblich und man kann Zeilennummern in der Antwort angeben.
Zu Deinem Telefon(ie)problem: Welche Telefonanlage oder VoIP-Anbieter kommt zum Einsatz? Oder bist Du noch immer bei o2 und versuchst dort die Telefonie im D713 anzudocken? Steht die TK-Anlage (wenn vorhanden) extern oder im internen Netz.
Zusätzlich mal auf der Weboberfläche des Snoms ins Logfile schauen, vielleicht schlagen auch bereits die SIP REGISTER Anfragen fehl (Logfile (auszugsweise) ggf. dann mal hier posten).
Ich vermute es gibt ein Problem mit der RTP-Übertragung. Aber dafür wäre ein Paketmitschnitt hilfreich, da kann man besser sehen, was genau passiert (geblockt wird).
Im Cisco Forum gibt es einige Einträge mit dem gleichen Problem: community.cisco.com/t5/network-security/zbfw-quot-sip-protocol-v ...
Einige FW-Versionen sind wohl buggy in Bezug auf SIP mit aktivierter deep packet inspection.
Gruß
cykes
vorab: könntest Du Deine Config bitte über die Beitrag bearbeiten Funktion in CODE-Tags setzen, das erhöht die Lesbarkeit erheblich und man kann Zeilennummern in der Antwort angeben.
Zu Deinem Telefon(ie)problem: Welche Telefonanlage oder VoIP-Anbieter kommt zum Einsatz? Oder bist Du noch immer bei o2 und versuchst dort die Telefonie im D713 anzudocken? Steht die TK-Anlage (wenn vorhanden) extern oder im internen Netz.
Zusätzlich mal auf der Weboberfläche des Snoms ins Logfile schauen, vielleicht schlagen auch bereits die SIP REGISTER Anfragen fehl (Logfile (auszugsweise) ggf. dann mal hier posten).
Ich vermute es gibt ein Problem mit der RTP-Übertragung. Aber dafür wäre ein Paketmitschnitt hilfreich, da kann man besser sehen, was genau passiert (geblockt wird).
Im Cisco Forum gibt es einige Einträge mit dem gleichen Problem: community.cisco.com/t5/network-security/zbfw-quot-sip-protocol-v ...
Einige FW-Versionen sind wohl buggy in Bezug auf SIP mit aktivierter deep packet inspection.
Gruß
cykes
aber SIP ist grundlegend nicht geblockt oder liege ich falsch?
Richtig, du liegst da keineswegs falsch!Kannst du ja auch an deiner eigenen Class Map LOKAL-ERLAUBT für dein lokales LAN immer selber sehen. Am Ende mit match protocol tcp und udp lässt du ja grundsätzlich ALLES an TCP und UDP basierten Protokollen durch!
Alles was zusätzlich noch protokollspezifisch angegeben ist wird auch auf den UDP und TCP Port bezogen noch genauer untersucht. Das ist also alles OK.
Als Vergleich dazu kannst du dir die Class Map GAST-ERLAUBT für dein Gastnetz ansehen. Gäste dürfen bei dir lediglich mit dem Browser arbeiten, DNS Requests senden und NTP Zeitserver befragen. Ping, VoIP und auch alles andere ist den Gästen verboten.
SIP Thematik:
Sehr hilfreich ist es in dem Falle einmal ein freies VoIP Softphone auf dem PC zu installieren wie Phoner oder Phone Lite:
phoner.de/index.htm
lite.phoner.de/index_de.htm
Das Softphone konfigurierst du dann mit deinem SIP User/Pass und SIP-Server Credentials und kannst damit aktiv testen. Auf dem gleichen PC kannst du dann parallel einen Wireshark Sniffer bei Bedarf laufen lassen und dir den SIP Prozess einmal genau ansehen.
Zusätzlich führt die Phoner Software ein Log was etwaige Fehler und Probleme immer mitloggt.
Manche VoIP Endgeräte verhalten sich nicht SIP RFC Standard konform und "mögen" das mit der ZFW und der spezifischen SIP und RTP Inspection aktivierte Voice Application Gateway nicht, so das es zu den o.a. SIP Format Fehlermeldungen und Drops kommt weil die Firewall einen Angriff vermutet.
In dem Falle ist es dann immer hilfreich zuerst testweise die beiden SIP "match" Kommandos aus der Class Map zu entfernen und nur RTSP zu belassen.
Die VoIP Protokoll Inspection wir dann weniger restriktiv und rein über die globale TCP bzw. UDP Inspection gemacht. Damit verschwindet dann auch die Fehlermeldung im Log und natürlich auch das Droppen dieses Traffics in der Firewall.
Im Zweifel, sollte es wider Erwarten immer noch nicht klappen, kannst du ebenfalls den RTSP Eintrag weglassen und das auch global über die UDP Inspection machen lassen.
Damit sollte das Problem verschwinden.
Sofern deine VoIP Endgeräte einen Keepalive nutzen prüfe das der Keepalive Timer nicht größer als 30 Sek. gesetzt ist oder stelle im Endgerät SIP immer auf einem TCP Encapsulation ein und nicht UDP! Prüfe dort auch das symetrische RTP Ports verwendet werden! Das o.a. Verhalten ist in erster Linie ein Konfig Fehler des VoIP Endgerätes und nicht des Routers. In so gut wie allen dieser Fälle halten sich Hersteller nicht an den SIP RFC Standard was dann bei protokollspezifischer Inspection in solchen Error Meldungen resultiert.
Wie gesagt: Prüfe das Verhalten auch immer mit dem o.a. Softphone im Vergleich.
Das Tutorial hat in den Kommentaren ebenfalls einen Thread zu dieser Thematik!
NTP Thematik:
Du hast auf dem Router keinerlei NTP Konfig, so das der Router daran scheitert sich von irgendwo her eine korrekte Uhrzeit und Datum zu holen. Diese Konfig fehlt bei dir schlicht und einfach so das es erwartbar ist das du eine falsche Uhrzeit hast.
Wenn du die Uhrzeit aus dem Internet ziehst, dann lösen diese im Tutorial beschriebenen Kommandos dein selbstgemachtes NTP Problem im Handumdrehen:
ntp server de.pool.ntp.org source Dialer0
ntp update-calendar
Wenn dein Internet Provider eigene Zeitserver betreibt z.B. die Telekom D mit ntp1.t-online.de dann solltest du diese verwenden. Letztlich aber kosmetisch.
Der deutsche ntp.org Pool hat den Vorteil das sich dahinter mehrere NTP Server in einem Pool befinden. (Redundanz)
Ein show ntp status bzw. auch show ntp ass und show clock zeigt dir dann ob der Router eine korrekte NTP Zeitserver Verbindung aufgebaut hat und die korrekte Uhrzeit und Datum hat.
Weitere Punkte:
- Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects.
Alles weitere erklärt dir, wie immer, das hiesige Cisco Tutorial.
Zitat von @mariocisco:
Also schon einmal die Info dass das TSIp TElefon registriert ist abaer eingehend wie ausgehend keine Telefonie möglich ist eingehend ist das Telefon nicht erreichbar und ausgehend klingelt es es klingelt auch beim gegenüber aber wenn man abhebt höhrt man nichts und am VoiP Telefon sieht man auch nicht das abgehoben wurde.
Das sind weitere Indizien dafür, dass RTP nicht korrekt durchgeht, also Trace machen (geht auch auf einigen Snom Telefonen - das D713 kenne ich nicht aus eigener Anschauung) und mit Wireshark o.ä. auswerten.Also schon einmal die Info dass das TSIp TElefon registriert ist abaer eingehend wie ausgehend keine Telefonie möglich ist eingehend ist das Telefon nicht erreichbar und ausgehend klingelt es es klingelt auch beim gegenüber aber wenn man abhebt höhrt man nichts und am VoiP Telefon sieht man auch nicht das abgehoben wurde.
@aqui was ist damit gemeint
Er meint um die Zeile 339 (hab' Dein Zitat mal ein wenig umformatiert)."Weitere Punkte:
Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects."
Welcher Eintrag ist gemeint damit?Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects."
Anbieter ist O2. Das Telefon soll ausschließlich mit SIP Daten betrieben werden.
Sind die SIP-Daten direkt im Snom eingetragen? Welcher VoIP/SIP-Server steht da?Ich meine mich erinnern zu können, dass es bei o2 da immer wieder Probleme mit SIP i.V.m. Fremdroutern gab. Ggf. wäre ein SBC hilfreich, wenn Du lokal keine VoIP-TK-Anlage hast. Ist das ein Privat- oder Geschäftskundenanschluss?
Gruß
cykes
TSIp TElefon
Was ist das? 🤔abaer eingehend wie ausgehend keine Telefonie möglich ist
Ein paar Fragen dazu:- Hat das Telefon eine aktive SIP Session? Sprich ist es erfolgreich mit dem SIP Server verbunden? (Status Display)
- Hast du parallel einmal das dir oben genannte kostenlose Softphone Phoner oder [https://lite.phoner.de/index_de.htm Phoner-Lite installiert mit den gleichen O2 SIP Credentials und damit einmal getestet? Wenn ja, welches Ergebnis? SIP Status im Logging etc.?
- Hast du die beiden SIP match protocol Statements erst einmal testweise aus der Class Map Konfig entfernt? Ggf. auch das RTSP Statement? (Siehe dazu auch HIER in den Tutorial Kommentaren) Wie verhält sich das Telefon dann?
- Wenn alle Stricke reissen deaktivierst du einmal testweise die ZFW Firewall komplett indem du auf allen 3 aktiven IP Interfaces die Zonen Zuordnung entfernst. Kommt dann eine SIP Session zustande mit Telefon und Softphone?
Hier funktioniert ein Gemisch aus Auerswald Anlage, Cisco Telefonen und dem o.a. Softphone auf einem 886er, 896er, 926er und 1100er ohne jegliche Auffälligkeiten.
Vermutlich scheitert dein Telefon schon grundsätzlich an der O2 SIP Registrierung was dann auf falsche SIP Zugangsdaten schliessen lässt. Also einem Problem am Endgerät selber. Deshalb die Empfehlung testweise immer mit dem Softphone zu arbeiten, weil das eine deutlich bessere Troubleshooting Option durchs Logging hat.
was ist damit gemeint
OK, sorry wenn das unklar ausgedrückt war aber gerne nochmal etwas detailierter.Auf deinem o.a. Router befindet sich eine ungenutzte und bei ZFW Betrieb damit auch sinnfreie Accessliste namens blockext!!
Da diese ACL völlig ungenutzt und damit nutzlos ist, weil sie nirgendwo zugewiesen ist solltest du diese besser mit no ip access-list extended blockext vollständig entfernen. Denn wozu sollte es Sinn machen so eine ungenutzte und damit überflüssige ACL (Leiche) in der Konfig zu behalten?
In Bezug auf IPv6 hat deine ZFW Konfig auch noch einen groben Fehler.
Es fehlt vollständig ein Regelwerk was DHCPv6 vom Internet Provider (O2) passieren lässt. Damit ist dann keine IPv6 Prefix Delegation und Adressvergabe vom Provider möglich. Als weitere Folge davon scheitert dann auch die ansonsten korrekt konfigurierte IPv6 Adressvergabe auf den internen LAN Interfaces.
Ein show ipv6 dhcp interface dialer0 sollte diesen Konfig Fehler belegen. Dort müsste die gescheiterte IPv6 Adressierung und v6 Prefix Delegation zu sehen sein.
Aber das ist jetzt erstmal nur ein Nebenkriegsschauplatz und hat mit dem eigentlichen Thread Thema VoIP nichts zu tun.
Details auch hier wie immer in den IPv6 Customizing Hinweisen für die ZFW Firewall im Cisco Tutorial.
Antwort: ja selbes Fehlerbild. Ein Ausgehend keine Telefonie.
Wie gesagt: Sehr wahrscheinlich scheitert zu 98% schon deine SIP Registrierung. Für ein zielführendes Troubleshooting wäre jetzt einmal das Phoner Log sehr hilfreich.
Idealerweise indem du parallel einmal mit dem Wireshark dir die SIP Registrierung ansiehst. Dort kann man sofort sehen was Sache ist.
Wenn weder eingehend noch ausgehend Anrufe möglich sind ist es sehr wahrscheinlich das schon gar keine aktive SIP Session mit den Telefonen existiert.
Hast du auch einmal versucht den SIP Server sip.alice-voip.de zu pingen ob das möglich ist.
P.S.: Wenn zitieren dann bitte richtig so das man den Zitattext auch sauber erkennen kann!!
Zitieren von Kommentaren
.. und was auch für die Telefonie bei o2-DSL extrem wichtig ist: Es muss zwingend der dem Anschluss zugeordnete (o2) DNS-Server verwendet werden, das ist ähnlich bei einem Telekom Anschluss.
Hier gibt's auch noch weitere Konfigurationstipps für o2 VoIP über einen Fremdrouter: O2 VoIP mit Fritzbox als Client hinter OPNsense (musst Du halt nur auf Deinen Cisco übertragen).
Hier gibt's auch noch weitere Konfigurationstipps für o2 VoIP über einen Fremdrouter: O2 VoIP mit Fritzbox als Client hinter OPNsense (musst Du halt nur auf Deinen Cisco übertragen).
SIP Destination Error und Transport Error sprechen ja schon für sich das die SIP Daten falsch sind!!
Wie vermutet kommt gar keine gültige SIP Session vom Telefon zum SIP Server zustande. Der Router und seine Konfig hat mit dem Problem primär also nix zu tun!
Es sei denn du propagierst intern an die SIP Clients per DHCP einen anderen DNS als den O2 DNS wie Kollege @cykes schon gesagt hat?
So sollte es aussehen:
Wie vermutet kommt gar keine gültige SIP Session vom Telefon zum SIP Server zustande. Der Router und seine Konfig hat mit dem Problem primär also nix zu tun!
Es sei denn du propagierst intern an die SIP Clients per DHCP einen anderen DNS als den O2 DNS wie Kollege @cykes schon gesagt hat?
So sollte es aussehen:
- SIP Statuscode 200 (Notify OK) bei der Registrierung (Subscribe) am SIP Server
- Resultiert dann in einer tcp registered Message am Phoner Client
- Rausgehender SIP Call fehlerlos mit einem invite

- Works as designed!
dort eintragen bei Zeile 332 von meinem config post?
Nein, das ist das Kommando was den Cisco selber zu einem Caching DNS Server macht.Relevant für den zu lernenden Provider DNS ist Zeile 323.
Ob der Router den richtigen Provider DNS Server gelernt hat kannst du mit dem Kommando show hosts selber überprüfen statt zu raten.
aber eingehend geht es weiterhin nicht.
Versuche mal einen ausgehenden Anruf und nach dem Auflegen dich direkt innerhalb von 30 Sekunden zurückzurufen. Klappt das?Wenn ja kann es sein das du am UDP Timeout scheiterst. Grund ist meistens ein falsch konfiguriertes SIP Keepalive oder ein fehlender STUN Server. Oftmals passiert das wenn man statt TCP fälschlicherweise UDP bei SIP verwendet.
Achte am Softphone darauf das du dort TCP anhakst!
Ich gehe davon aus dass hat nichts mit den dns zutun weil ausgehend ja funktioniert
Das ist korrekt!P.S.: Bitte die Forenregeln beachten! Insbesondere korrekte Rechtschreibung (Groß- Klein). Das hilft allen hier!
Gibt es denn eine Möglichkeit die Zone based firewall mit match protocol weiter zu betreiben so dass die Protokolle sip , sip-tls und rtsp?
Ja natürlich! Das ist sehr einfach.Du lässt dafür einfach die 3 "match protocol..." für sip, sip-tls und für rtsp schlicht und einfach weg.
Damit rennt die SIP und RTSP Protokoll Inspection über die globale UDP und TCP Inspection am Ende.
Sie werden dann nicht bis in die Tiefe untersucht sondern nur über den TCP oder UDP Header.
Wie oben schon mehrfach gesagt fixt das dann in der Regel auf die Fehlermeldung und die Fehlfunktion.
So wie es aussieht hast du oben keine Fehlfunktion des Routers oder der Firewall sondern eine Fehlkonfiguration beim SIP auf den Endgeräten. Bei UDP Encapsulation öffnet die Firewall für max. 150 Sekunden (plus/minus je nach Hersteller) den Port. Jeder Traffic retriggert den 150 Sek. Timer. Deshalb kann man sich innerhalb dieser Zeit auch problemlos anrufen.
Passiert aber nix dann schliesst die Firewall den Port wieder und eingehende UDP SIP Sessions (bei Anrufen) scheitern verständlicherweise.
Das passiert wenn keine SIP Keepalives gesendet werden oder eben UDP verwendet wird für SIP. Bei TCP passiert das durch den Sessionerhalt nicht. Die Firewall kann am TCP Sessionheader erkennen das die Session aktiv gehalten wird und hält den SIP Port offen.
Dies Verhalten ist immer so an Firewalls bei SIP. Siehe dazu auch HIER.
etwas auswählen nämlich active
Geraten wäre das wohl "active". Active Keepalives. Wie gesagt geraten und sagt dir, wie immer, das Handbuch des Gerätes.In dem selben Menü gibt es folgende Einträge:
Das wichtigste ist dort das Keepalive Setting.Was passiert mit dem Phoner Softphone wenn du SIP dort auf TCP setzt? Ist das zu jeder Zeit anrufbar?
die Zone based firewall mit match protocol weiter zu betreiben
Ja klar das klappt.Hier rennen Auerswald Anlage, FritzBox im Client Mode, Cisco Telefone, Gigaset VoIP-Dect Knoten, Panasonic VoIP-Dect Telefon, Phoner Softphone usw. völlig problemlos mit den 3 relevanten match protocol ... Kommandos.
Die Auerswald sogar im UDP Mode mit 180 Sek Keepalive und ohne Error Messages. Das ist bei dir in jedem Falle falsch das bei UDP auf 0 zu lassen. Setze den Keepalive in jedem Fall!

Es ist gut möglich das deine MD Edition einen Fehler im ZFW Protokollhandling hat. Das passiert manchmal auch innerhalb des gleichen Releasetrains.
Einfach das als 2tes Image ins Flash laden und das system boot ... Kommando anpassen.
aber das ist doch eine alte Firmeware oder?
Nope! Es ist das offiziell für den 900er recommendete Image von Cisco!software.cisco.com/download/home/286315020/type/280805680/releas ...
Man achte auf das Sternchen!
Poste bitte nochmal den Karteireiter "SIP" des Telefons. Das hast du oben leider vergessen. Dort stehen sehr wahrscheinlich alle relevanten Einstellungen der Signalisierung und da ist nochwas falsch.
Nochmals die Frage: Was passiert mit dem Phoner Softphone wenn du SIP dort auf TCP setzt? Ist der Phoner zu mindestens zu jeder Zeit anrufbar?

Wenn das DER hier ist...
dann ja. Ansonsten ist der Eingekringelte gemeint!
Als Beispiel hast du mal eine Session Ausgabe der ZFW mit einem Phoner Softphone (SIP mit TCP, Port 5060) was auf einen Sipgate Account gemappt ist und 24/7 anrufbar ist.
Die ZFW hat alle 3 Voice relevanten match protocol .. Settings aktiv!
Wenn der Phoner Client (192.168.1.183) SIP registriert ist OHNE aktiven Call:
Dto. mit aktivem Anruf
Das sollte bei dir identisch aussehen! 🤔

Als Beispiel hast du mal eine Session Ausgabe der ZFW mit einem Phoner Softphone (SIP mit TCP, Port 5060) was auf einen Sipgate Account gemappt ist und 24/7 anrufbar ist.
Die ZFW hat alle 3 Voice relevanten match protocol .. Settings aktiv!
Wenn der Phoner Client (192.168.1.183) SIP registriert ist OHNE aktiven Call:
Cisco#sh policy-map type inspect zone-pair sessions source 192.168.1.183 | include sip
Match: protocol sip
Match: protocol sip-tls
Match: protocol sip
Match: protocol sip-tls
Session ID 0x0001E179 (192.168.1.183:50195)=>(212.9.44.244:5060) sip SIS_OPEN
Session ID 0x0001E04D (192.168.1.183:50028)=>(212.9.44.242:5060) sip SIS_CLOSED
Session ID 0x0001E050 (192.168.1.183:0)=>(212.9.44.242:5060) sip SIS_PREGEN
Session ID 0x0001E17C (192.168.1.183:0)=>(212.9.44.244:5060) sip SIS_PREGEN
Dto. mit aktivem Anruf
Cisco#sh policy-map type inspect zone-pair sessions source 192.168.1.183 | include sip
Match: protocol sip
Match: protocol sip-tls
Match: protocol sip
Match: protocol sip-tls
Session ID 0x0001E224 (192.168.1.183:5062)=>(212.9.44.185:17132) sip-RTP-data SIS_OPEN
Session ID 0x0001E22D (192.168.1.183:5060)=>(217.10.77.244:5060) sip SIS_OPEN
Session ID 0x0001E225 (192.168.1.183:5063)=>(212.9.44.185:17133) sip-RTP-data SIS_OPEN
Session ID 0x0001E179 (192.168.1.183:50195)=>(212.9.44.244:5060) sip SIS_OPEN
Session ID 0x0001E04D (192.168.1.183:50028)=>(212.9.44.242:5060) sip SIS_CLOSED
Session ID 0x0001E050 (192.168.1.183:0)=>(212.9.44.242:5060) sip SIS_PREGEN
Session ID 0x0001E17C (192.168.1.183:0)=>(212.9.44.244:5060) sip SIS_PREGEN
Hi Mario,
ich würde auch erstmal Dinge wie RTP Verschlüsselung ausschalten und da keine lokale TK-Anlage vorhanden ist auch TLS-Verschlüsselung (Secure) SIP aauf aus stellen. Das müssen beide (Gesprächs-)Parteien unterstützen und da es um eingehende Anrufe geht, kannst Du Dir da nicht sicher sein. Versuche ersteinmal alles mit möglichst wenig Features, wenn das dann funktioniert, kannst Du ja weiter experimentieren.
Gruß
cykes
ich würde auch erstmal Dinge wie RTP Verschlüsselung ausschalten und da keine lokale TK-Anlage vorhanden ist auch TLS-Verschlüsselung (Secure) SIP aauf aus stellen. Das müssen beide (Gesprächs-)Parteien unterstützen und da es um eingehende Anrufe geht, kannst Du Dir da nicht sicher sein. Versuche ersteinmal alles mit möglichst wenig Features, wenn das dann funktioniert, kannst Du ja weiter experimentieren.
Gruß
cykes
@cykes Ich gehe davon aus am Telefon. Sonst kann ich das ja nicht einstellen. Vielen Dank
Ja, genau, da ja keine TK-Anlage vorhanden ist -> in Deinem letzten Screenshot bspw. unter RTP-Verschlüsselung (und weitere) zu sehen.
habe ich ausprobiert und es hat nichts genützt leider.
Da wirst du dann nicht umhinkommen einmal den Wireshark anzuschmeissen. Capture Filter auf UDP und TCP Port 5060 ("port 5060") und checken was da genau abgeht bei der Registrierung des Snom Telefons. Irgendwas muss da schieflaufen, denn wenn es mit den Phoner Softphone fehlerlos rennt kann es nur das Snom sein.Alternativ könntest du, sofern du noch irgendwo ne olle Fritte in der Bastelschublade rumliegen hast, diese als IP Client konfigurieren, ins lokale Netz als lokale VoIP Anlage hängen und dann mal mit dem Snom versuchen lokal und ohne FW dazwischen eine SIP Verbindung direkt auf die Fritzbox zu realisieren.
Scheitert das auch, dann hast du den ultimativen Beleg das irgendwas am Snom schiefläuft bzw. grundsätzlich falsch konfiguriert ist.
Intensive Tests mit dem aktuellen M11 Patch und der Cisco recommendeten M0a auf der 900er Plattform mit einem Phoner Softphone VoIP Client über SIPgate bestätigten deinen Fehler!
Fazit:
In beiden Versionen ist das SIP spezifische Checking in der ZFW Firewall buggy!
Es erscheint schon bei der eigentlichen SIP Registrierung ein "%AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Mandatory header field missing) - resetting tcp session" Error im Log was dann das Passieren der SIP Session verhindert und damit den VoIP Betrieb unmöglich macht.
Auch ein Ändern der SIP Encapsulation auf UDP brachte keine Lösung. Zwar verschwindet dann die o.a. ZFW Fehlermeldung im Log es kann aber dennoch keine SIP Verbindung aufgebaut werden. Das mag aber auch daran liegen das SIPgate ggf. kein auf UDP basierendes SIP akzeptiert. Müsste man nochmal checken?!
Mit TCP ist der Fehler in jedem Falle reproduzierbar.
Daraus bleibt dann der Schluss das dein SNOM Knochen sehr wahrscheinlich NICHT der böse Buhmann ist sondern das 900er Image auf dem Cisco 900.
Interessanterweise funktionierte ein völlig identisches ZFW Setup mit einem Cisco 886va, 896 und 1100er jeweils in der recommendeten Version als auch in der latest und greatest absolut fehlerfrei MIT aktiver SIP Inspection in der ZFW. Es ist also de facto ein Cisco 900 spezifisches Problem der ZFW.
Wenn dein 900er unter Wartung ist solltest du in jedem Falle einen TAC Case bei Cisco diesbezüglich aufmachen! Da die anderen Router allesamt nicht betroffen sind ist das sicher schnell zu fixen.
Es gibt einen sehr einfachen Workaround bis zu einem Fix:
Entferne einfach mit no match protocol sip nur die SIP spezifische Protocol Inspection!
Die TLS und auch die RTSP Inspection kannst du belassen da die nachweislich nicht betroffen sind.
Damit läuft SIP über die normale TCP Inspection und die VoIP Telefonie funktioniert fehlerlos mit beiden o.a. Firmware Images auf dem 900er.
Fazit:
In beiden Versionen ist das SIP spezifische Checking in der ZFW Firewall buggy!
Es erscheint schon bei der eigentlichen SIP Registrierung ein "%AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Mandatory header field missing) - resetting tcp session" Error im Log was dann das Passieren der SIP Session verhindert und damit den VoIP Betrieb unmöglich macht.
Auch ein Ändern der SIP Encapsulation auf UDP brachte keine Lösung. Zwar verschwindet dann die o.a. ZFW Fehlermeldung im Log es kann aber dennoch keine SIP Verbindung aufgebaut werden. Das mag aber auch daran liegen das SIPgate ggf. kein auf UDP basierendes SIP akzeptiert. Müsste man nochmal checken?!
Mit TCP ist der Fehler in jedem Falle reproduzierbar.
Daraus bleibt dann der Schluss das dein SNOM Knochen sehr wahrscheinlich NICHT der böse Buhmann ist sondern das 900er Image auf dem Cisco 900.
Interessanterweise funktionierte ein völlig identisches ZFW Setup mit einem Cisco 886va, 896 und 1100er jeweils in der recommendeten Version als auch in der latest und greatest absolut fehlerfrei MIT aktiver SIP Inspection in der ZFW. Es ist also de facto ein Cisco 900 spezifisches Problem der ZFW.
Wenn dein 900er unter Wartung ist solltest du in jedem Falle einen TAC Case bei Cisco diesbezüglich aufmachen! Da die anderen Router allesamt nicht betroffen sind ist das sicher schnell zu fixen.
Es gibt einen sehr einfachen Workaround bis zu einem Fix:
Entferne einfach mit no match protocol sip nur die SIP spezifische Protocol Inspection!
Die TLS und auch die RTSP Inspection kannst du belassen da die nachweislich nicht betroffen sind.
Damit läuft SIP über die normale TCP Inspection und die VoIP Telefonie funktioniert fehlerlos mit beiden o.a. Firmware Images auf dem 900er.
Ich muss erst einmal dabei belassen vielen dank für eure Mühe.
Was denn belassen?? Den o.a. Workaround? 🤔Interessant vielleicht noch das ein Cisco 7970 Telefon mit der SIP Inspection zwar ausgehend am 900er funktionierte aber kein Call reinkam. Bei eingehenden SIP Calls kam beim 900er sofort wieder die o.a. ZFW Error Meldung bzgl. des Header Field Fehlers. Korreliert also zu deiner Beobachtung.
Bei allen anderen Cisco Routern unterblieb das und das Telefon funktionierte problemlos. Auch das zeigt de facto ein 900er spezifisches Problem.
Wie gesagt: Mit dem Entfernen der spezifischen SIP Inspection in der ZFW Firewall beim 900er funktionieren alle getesteten Telefone völlig fehlerlos. Auch ein altes SNOM 360.
Damit hat man einen sehr einfachen Workaround ohne auf die Sicherheit der ZFW verzichten zu müssen und bekommt VoIP problemlos zum Laufen.
Bei Yealink hört natürlich der Chinese immer mit. Ob du das willst oder nicht musst du selber entscheiden.
Nochwas zum Thema Uhrzeit... Dieser Punkt deiner Frage ist hier leider etwas untergegangen im Eifer des VoIP Gefechts.
Der Grund keiner oder der falschen Uhrzeit liegt leider auch wieder in einer NTP Fehlkonfiguration des Routers deinerseits!
Die Zeitzone usw. stimmt, aber es fehlt vollständig die Angabe eines NTP Servers von dem der Router seine Uhrzeit zieht. Z.B.
ntp source Dialer 0
ntp update-calendar
ntp server de.pool.ntp.org
👉🏽 Wichtig zu wissen ist das der Cisco damit als NTP Proxy arbeitet im lokalen Netzwerk. Du kannst die Cisco Router IP Adresse dann bei allen lokalen Endgeräten als NTP Zeitserver angeben und sie zusätzlich auch per DHCP in der DHCP Konfig mit option 42 ip <router_ip_addr> allen Endgeräten mitgeben.
Nabend,
ich glaube, Mario möchte erstmal die weitere Bearbeitung unterbrechen (oder sogar abbrechen)!? Im Endeffekt wirst Du - wie @aqui das bei seinen Tests dargelegt hat - mit jedem SIP-Telefon diese oder ähnliche Probleme i.V.m. dem 900er Cisco haben. Grundlegend arbeiten die alle gleich. Das Yealink ist da keine Ausnahme, also jetzt nicht wegen dieses Bugs ne Materialschlacht starten.
So steht es auch in den Threadsim Cisco Forum, die ich eingangs verlinkt habe, Darfste Dir gern mal durchlesen ...
Gruß
cykes
ich glaube, Mario möchte erstmal die weitere Bearbeitung unterbrechen (oder sogar abbrechen)!? Im Endeffekt wirst Du - wie @aqui das bei seinen Tests dargelegt hat - mit jedem SIP-Telefon diese oder ähnliche Probleme i.V.m. dem 900er Cisco haben. Grundlegend arbeiten die alle gleich. Das Yealink ist da keine Ausnahme, also jetzt nicht wegen dieses Bugs ne Materialschlacht starten.
So steht es auch in den Threadsim Cisco Forum, die ich eingangs verlinkt habe, Darfste Dir gern mal durchlesen ...
Gruß
cykes
Wenn Abbruch dann bitte deinen Thread auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?