15
Cisco 886VA, Gigaset C610-IP: ausgehende Telefonate nicht möglich
Hallo Community,
ich habe einige Probleme, ein Siemens Gigaset C610 IP über den Cisco zum Laufen zu bringen, vielleicht kann mir ja jemand von euch weiterhelfen.
Folgender Aufbau ist vorhanden:
[T-Com VDSL 50 (über ISDN) mit VoIP]
|
[Cisco 886VA] -- Fe0, Fe1: [Cisco WAP321] (2x)
|
Fe2: [Siemens Gigaset C610 IP] -(...)- [DECT Mobilteil] (3x)
Der Router hat aktuell folgende Konfiguration [3]. Die ursprüngliche Konfiguration lehnt sich sehr an den hier vorhandenen Tutorial-Beitrag [2] an, die Access-List 102 habe ich momentan für die Fehlersuche derart reduziert.
Zum Problem:
Es ist problemlos möglich, die auf den drei Mobilteilen jeweils konfigurierten VoIP-Nummern von intern und extern anzurufen (eingehend).
Versuche ich jedoch, mit diesen nach extern (ausgehend) zu telefonieren, kommt eine Sprachansage (vermutlich von der Gigaset-Basis), dass ein Verbindungsaufbau derzeit nicht möglich ist.
Ich vermute, dass entweder eine Firewall-Regel, oder eine fehlende Routing-Regel [1] dafür verantwortlich sind, habe aber momentan keine Idee was hier noch fehlt.
Hat jemand eine Idee??
Vielen Dank und beste Grüße
core
[1] http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/faq-350884716
[2] Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
[3] Router-Konfiguration:
ich habe einige Probleme, ein Siemens Gigaset C610 IP über den Cisco zum Laufen zu bringen, vielleicht kann mir ja jemand von euch weiterhelfen.
Folgender Aufbau ist vorhanden:
[T-Com VDSL 50 (über ISDN) mit VoIP]
|
[Cisco 886VA] -- Fe0, Fe1: [Cisco WAP321] (2x)
|
Fe2: [Siemens Gigaset C610 IP] -(...)- [DECT Mobilteil] (3x)
Der Router hat aktuell folgende Konfiguration [3]. Die ursprüngliche Konfiguration lehnt sich sehr an den hier vorhandenen Tutorial-Beitrag [2] an, die Access-List 102 habe ich momentan für die Fehlersuche derart reduziert.
Zum Problem:
Es ist problemlos möglich, die auf den drei Mobilteilen jeweils konfigurierten VoIP-Nummern von intern und extern anzurufen (eingehend).
Versuche ich jedoch, mit diesen nach extern (ausgehend) zu telefonieren, kommt eine Sprachansage (vermutlich von der Gigaset-Basis), dass ein Verbindungsaufbau derzeit nicht möglich ist.
Ich vermute, dass entweder eine Firewall-Regel, oder eine fehlende Routing-Regel [1] dafür verantwortlich sind, habe aber momentan keine Idee was hier noch fehlt.
Hat jemand eine Idee??
Vielen Dank und beste Grüße
core
[1] http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/faq-350884716
[2] Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
[3] Router-Konfiguration:
version 15.1
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname XXXXXXXXXXXXXXXXXXXX
!
boot-start-marker
boot-end-marker
!
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 20480000
enable secret 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
enable password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
no aaa new-model
no process cpu extended history
no process cpu autoprofile hog
memory-size iomem 10
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
crypto pki token default removal timeout 0
!
!
no ip source-route
no ip gratuitous-arps
ip auth-proxy max-login-attempts 5
ip admission max-login-attempts 5
!
!
!
ip dhcp excluded-address 192.168.100.1 192.168.100.99
ip dhcp ping packets 3
ip dhcp ping timeout 100
!
ip dhcp pool local
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
dns-server 192.168.100.1
domain-name XXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool wap1
host 192.168.100.11 255.255.255.0
client-identifier 01XX.XXXX.XXXX.XX
default-router 192.168.100.1
dns-server 192.168.100.1
client-name wap1
domain-name XXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool wap2
host 192.168.100.12 255.255.255.0
client-identifier 01XX.XXXX.XXXX.XX
default-router 192.168.100.1
dns-server 192.168.100.1
client-name wap2
domain-name XXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool dect1
host 192.168.100.21 255.255.255.0
hardware-address XXXX.XXXX.XXXX
default-router 192.168.100.1
dns-server 192.168.100.1
client-name dect1
domain-name XXXXXXXXXXXXXXXXXXXX.local
!
!
ip cef
no ip bootp server
ip domain name XXXXXXXXXXXXXXXXXXXX.local
ip multicast-routing
ip inspect name Firewall tcp router-traffic
ip inspect name Firewall udp
ip ddns update method dyndns
HTTP
add http://XXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXX@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
interval maximum 1 0 0 0
!
no ipv6 cef
!
!
license udi pid CISCO886VA-K9 sn XXXXXXXXXXXXXXXXXXXX
!
!
username root privilege 15 password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
!
!
!
controller VDSL 0
description DTAG VDSL 50 Leitung
!
ip ssh version 2
!
!
!
bridge irb
!
!
!
!
interface Ethernet0
description VDSL Physical Interface
no ip address
no ip route-cache
!
interface Ethernet0.7
description VDSL Daten Verbindung
encapsulation dot1Q 7
no ip route-cache
pppoe-client dial-pool-number 1
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface FastEthernet0
description Uplink wap1
no ip address
spanning-tree portfast
!
interface FastEthernet1
description Uplink wap2
no ip address
spanning-tree portfast
!
interface FastEthernet2
no ip address
spanning-tree portfast
!
interface FastEthernet3
no ip address
spanning-tree portfast
!
interface Vlan1
description Lokales Netzwerk
no ip address
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dialer0
description DSL Einwahl Interface
ip ddns update hostname XXXXXXXXXXXXXXXXXXXX.dyn.XXXXXXXXXXXXXXXXXXXX.net
ip ddns update dyndns
ip address negotiated
ip access-group 102 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect Firewall out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@t-online.de password 7 XXXXXXXXXXXXXXXXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
interface BVI1
description Lokales Netzwerk
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
no 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 route 0.0.0.0 0.0.0.0 Dialer0
!
ip access-list log-update threshold 1
access-list 1 permit any
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 102 permit ip any any log
access-list 105 permit tcp any any eq 22
dialer-list 1 protocol ip list 101
no cdp run
!
!
!
!
bridge 1 protocol ieee
bridge 1 route ip
!
line con 0
exec-timeout 5 0
login local
line aux 0
line vty 0 4
access-class 105 in
exec-timeout 30 0
privilege level 15
login local
transport preferred ssh
transport input ssh
!
end
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 225187
Url: https://administrator.de/contentid/225187
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
15 Kommentare
Neuester Kommentar
Bitte lasse den Unsinn mit externen Sites hier im Forum. In den FaQs steht wie du Konfigs über die (code) Tags hier problemlos in deinen Thread einbetten kannst ohne externe Sites mit Zwangswerbung !
Zurück zum Thema….
Vergleiche deine Konfig mit diesem Tutorial hier:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Damit funktioniert VoIP zu diversen SIP Providern (T-Com, Sipgate) fehlerlos. Eine entsprechende Konfig sollte auch dein Problem im Handumdrehen lösen.
Tip: Die IP Konfig (vlan 1) deines lokalen LANs ist gelinge gesagt ungewähnlich. vlan1 ist das lokale IP Interface und das BVI Interface dient lediglich dazu den internen AP zu bridgen. Das solltest du ggf. umstellen.
Routing Regel ist ebenso Blödsinn, denn mit nur einem Internet Zugang hast du ja nur eine einzige Route zu deinem Provider. Ist wie immer hier die Firewall Regel oder die CBAC Konfig sofern du das überhaupt konfiguriert hast (was du aber solltest !) ACL 102 ist eher eine weihnachtliche Einladung zum Hacken. Damit machst du den Router offen wie ein Scheunentor. OK zum VoIP Testen temporär mag das OK sein für einen Produktivtraffic später aber nicht.
Wenn alle Stricke reissen schmeiss die Debugger Funktion an und checke WAS ggf. die VoIP Pakete blockt in der Konfig.
Zurück zum Thema….
Vergleiche deine Konfig mit diesem Tutorial hier:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Damit funktioniert VoIP zu diversen SIP Providern (T-Com, Sipgate) fehlerlos. Eine entsprechende Konfig sollte auch dein Problem im Handumdrehen lösen.
Tip: Die IP Konfig (vlan 1) deines lokalen LANs ist gelinge gesagt ungewähnlich. vlan1 ist das lokale IP Interface und das BVI Interface dient lediglich dazu den internen AP zu bridgen. Das solltest du ggf. umstellen.
Routing Regel ist ebenso Blödsinn, denn mit nur einem Internet Zugang hast du ja nur eine einzige Route zu deinem Provider. Ist wie immer hier die Firewall Regel oder die CBAC Konfig sofern du das überhaupt konfiguriert hast (was du aber solltest !) ACL 102 ist eher eine weihnachtliche Einladung zum Hacken. Damit machst du den Router offen wie ein Scheunentor. OK zum VoIP Testen temporär mag das OK sein für einen Produktivtraffic später aber nicht.
Wenn alle Stricke reissen schmeiss die Debugger Funktion an und checke WAS ggf. die VoIP Pakete blockt in der Konfig.
Hi,
zunächst sorry für das Auslagern der Config, inzwischen hab ich es in den Beitrag hinzu editiert.
(hatte das für übersichtlicher gehalten)
Zu dem BVI hab' ich mich nach dem Tipp noch mal informiert - und da ich das Modell ohne WLAN habe, dann auch entfernt, sowie mein Vlan1 angepasst:
Damit sehen die entsprechenden Abschnitte nun wie folgt aus:
Zwischenzeitlich habe ich auch noch einige Stunden
mit der Telekom telefoniert, dort weiß man zwar "Es liegen Auffälligkeiten bei der Rufnummernkonfiguration vor." (soll wohl so dort angezeigt werden), Details könne man aber nicht einsehen. Am Problem selbst hat sich nichts geändert. Mit dem Gigaset-Support durfte ich auch telefonieren, laut ihnen ist meine Einstellung (der VoIP-Basis) aber richtig, und ich solle mich an die Telekom wenden ...
Kurzzeitig habe ich auch mal ebenso noch die ACL 101 auf "permit ip any any" gesetzt, das brachte aber ebenso keinen Erfolg.
zunächst sorry für das Auslagern der Config, inzwischen hab ich es in den Beitrag hinzu editiert.
(hatte das für übersichtlicher gehalten)
Zu dem BVI hab' ich mich nach dem Tipp noch mal informiert - und da ich das Modell ohne WLAN habe, dann auch entfernt, sowie mein Vlan1 angepasst:
no interface BVI1
no bridge 1 protocol ieee
no bridge 1 route ip
no bridge irb
interface Vlan1
no bridge-group 1
no bridge-group 1 spanning-disabled
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1452Damit sehen die entsprechenden Abschnitte nun wie folgt aus:
[...]
!
ip cef
no ip bootp server
ip domain name XXXXXXXXXXXXXXXXXXXXXX.local
ip multicast-routing
ip inspect name Firewall tcp router-traffic
ip inspect name Firewall udp
ip ddns update method dyndns
HTTP
add http://XXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXX@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
interval maximum 1 0 0 0
!
[...]
!
interface Vlan1
description Lokales Netzwerk
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
[...]
!
ip access-list log-update threshold 1
access-list 1 permit any
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 102 permit ip any any log
access-list 105 permit tcp any any eq 22
dialer-list 1 protocol ip list 101
no cdp run
!
[...]Zwischenzeitlich habe ich auch noch einige Stunden
mit der Telekom telefoniert, dort weiß man zwar "Es liegen Auffälligkeiten bei der Rufnummernkonfiguration vor." (soll wohl so dort angezeigt werden), Details könne man aber nicht einsehen. Am Problem selbst hat sich nichts geändert. Mit dem Gigaset-Support durfte ich auch telefonieren, laut ihnen ist meine Einstellung (der VoIP-Basis) aber richtig, und ich solle mich an die Telekom wenden ...Kurzzeitig habe ich auch mal ebenso noch die ACL 101 auf "permit ip any any" gesetzt, das brachte aber ebenso keinen Erfolg.
Mmmhhh ist schon komisch… Die ACL 101 kann es niemals sein, denn die bestimmt ja nur den outgoing Traffic und du sagst ja selber es sind ausschliesslich eingehende Calls, also wenn die Gigasets angerufen werden von extern.
D.h. eine SIP und RTP Session die von außen eingeht.
In der Beziehung kann es also nur einzig die ACL 102 sein, die eingehende SIP bzw. RTP Calls blockt. Allerdings hast du mit "ip any any" hier ja auch das Scheunentor voll aufgemacht, d.h. alles darf rein bei dir also auch SIP Calls des Provider Gateways. Du solltest also drauf achten das SIP (Port 5060 und 5061) durchkommen kann auf die lokale IP des Gigasets.
CBAC erlaubt allerdings nur eingehende Sessions wenn auch eine ausgehende existiert. Ggf. soltest du testweise mal CBAC deaktivieren oder das ACL Debugging einschalten um zu sehen WAS hängenbleibt.
Du solltest also deshalb testweise vom Dialer Interface mal die ACL 102 ganz weg nehmen und auch die Firewall Funktion (ip inspect) und dann nochmal die VoIP Funktion testen.
Nochwas… Das permit logging der ACL 102 ist unsinnig, denn damit wird dir jeder einzelne eingehende Call ins Log geschrieben. Das bewirkt zusätzliche CPU Last die unsinnig und überflüssig ist. Das "log" Statement bei der ACL 102 solltest du also besser wehlassen.
Du kannst immer diese ACL debuggen mit dem debug xyz Kommando was sinnvoller ist ( u all am Schluss dann aber nicht vergessen !)
D.h. eine SIP und RTP Session die von außen eingeht.
In der Beziehung kann es also nur einzig die ACL 102 sein, die eingehende SIP bzw. RTP Calls blockt. Allerdings hast du mit "ip any any" hier ja auch das Scheunentor voll aufgemacht, d.h. alles darf rein bei dir also auch SIP Calls des Provider Gateways. Du solltest also drauf achten das SIP (Port 5060 und 5061) durchkommen kann auf die lokale IP des Gigasets.
CBAC erlaubt allerdings nur eingehende Sessions wenn auch eine ausgehende existiert. Ggf. soltest du testweise mal CBAC deaktivieren oder das ACL Debugging einschalten um zu sehen WAS hängenbleibt.
Du solltest also deshalb testweise vom Dialer Interface mal die ACL 102 ganz weg nehmen und auch die Firewall Funktion (ip inspect) und dann nochmal die VoIP Funktion testen.
Nochwas… Das permit logging der ACL 102 ist unsinnig, denn damit wird dir jeder einzelne eingehende Call ins Log geschrieben. Das bewirkt zusätzliche CPU Last die unsinnig und überflüssig ist. Das "log" Statement bei der ACL 102 solltest du also besser wehlassen.
Du kannst immer diese ACL debuggen mit dem debug xyz Kommando was sinnvoller ist ( u all am Schluss dann aber nicht vergessen !)
Gibt es einen aktuellen Status zu deinem Problem und hast du es lösen können ??
Wenn ja wäre ein entspr. Feedback hier mal ganz hilfreich für die Forums Community hier !!
Was du noch testen kannst (sofern noch nicht gelöst ?!) ist die CBAC Inspection anders zu konfigurieren:
ip inspect name Firewall tcp
ip inspect name Firewall udp
ip inspect name Firewall sip
ip inspect name Firewall rtsp
Ansonsten bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Wenn ja wäre ein entspr. Feedback hier mal ganz hilfreich für die Forums Community hier !!
Was du noch testen kannst (sofern noch nicht gelöst ?!) ist die CBAC Inspection anders zu konfigurieren:
ip inspect name Firewall tcp
ip inspect name Firewall udp
ip inspect name Firewall sip
ip inspect name Firewall rtsp
Ansonsten bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Ich bin leider noch nicht zum ausprobieren gekommen - da ich gerade auf dem 30c3 in Hamburg bin.
Zum ebenfalls probieren hab ich auch noch ein direktes Forwarden der Ports per Config [1] gefunden, so als last-chance...
Viele Grüße,
core
[1] http://www.ifm.net.nz/cookbooks/nat.html
Zum ebenfalls probieren hab ich auch noch ein direktes Forwarden der Ports per Config [1] gefunden, so als last-chance...
Viele Grüße,
core
[1] http://www.ifm.net.nz/cookbooks/nat.html
Ist eigentlich unerheblich für dich denn mit deiner ACL 102 erlaubst du ja eh alles an eingehenden Verbindungen am Internet Port (Dialer) !!
access-list 102 permit ip any any log
Das hat den gleichen Effekt als wenn du mit no access-list 102 permit ip any any log diese ACL vom Dialer Interface vollkommen entfernen würdest, das erlaubt dann auch alles.
Eigentlich müsste das eine "deny"" Liste sein für korrekt konfiguriertes CBAC also müsste sie korrektermassen so lauten:
access-list 102 permit icmp any any administratively-prohibited
access-list 102 permit icmp any any echo-reply
access-list 102 permit icmp any any packet-too-big
access-list 102 permit icmp any any time-exceeded
access-list 102 permit icmp any any unreachable
access-list 102 permit udp any eq domain any
access-list 102 permit tcp any eq domain any
access-list 102 permit tcp any eq 5060
access-list 102 permit gre any any
access-list 102 deny ip any any log
Das o.a. greift also für dich bzw. deinen ACL 102 so nicht.
OK warten wir mal den Kongress ab und deine weiteren Tests
access-list 102 permit ip any any log
Das hat den gleichen Effekt als wenn du mit no access-list 102 permit ip any any log diese ACL vom Dialer Interface vollkommen entfernen würdest, das erlaubt dann auch alles.
Eigentlich müsste das eine "deny"" Liste sein für korrekt konfiguriertes CBAC also müsste sie korrektermassen so lauten:
access-list 102 permit icmp any any administratively-prohibited
access-list 102 permit icmp any any echo-reply
access-list 102 permit icmp any any packet-too-big
access-list 102 permit icmp any any time-exceeded
access-list 102 permit icmp any any unreachable
access-list 102 permit udp any eq domain any
access-list 102 permit tcp any eq domain any
access-list 102 permit tcp any eq 5060
access-list 102 permit gre any any
access-list 102 deny ip any any log
Das o.a. greift also für dich bzw. deinen ACL 102 so nicht.
OK warten wir mal den Kongress ab und deine weiteren Tests
(ohne bisheriges Ausprobieren oder näheres Recherchieren) als Überlegung aber:
Die ACLs erlauben zwar den In-/Outbound Traffic. Woher weiß nun aber Inbound SIP Traffic, dass er innerhalb des Local LAN an das Device x.x.x.21 gehen soll?
Andererseits:
Die Probleme liegen ja nur bei Outbound Calls, eingehende Anrufe funktionieren ja...
Könnte aber maybe auch einfach nur bedeuten, dass STUN funktioniert?
Die ACLs erlauben zwar den In-/Outbound Traffic. Woher weiß nun aber Inbound SIP Traffic, dass er innerhalb des Local LAN an das Device x.x.x.21 gehen soll?
Andererseits:
Die Probleme liegen ja nur bei Outbound Calls, eingehende Anrufe funktionieren ja...
Könnte aber maybe auch einfach nur bedeuten, dass STUN funktioniert?
Deshalb das oben erwähnte "inspect sip und rtsp" in der CBAC Firewall, denn das eröffnet intelligent alle benötigsten Ports. SIP nutzt dynamische Antwort Ports bzw. STUN Ports die dann auch geöffnet werden.
Vermutlich wird das dann dein Problem fixen...?! Wäre sehr interessant, denn das könnte man dann noch als Ergänzung in das o.a. 886va Tutorial aufnehmen für VoIP Anlagen die hinter der NAT Firewall betrieben werden.
Vermutlich wird das dann dein Problem fixen...?! Wäre sehr interessant, denn das könnte man dann noch als Ergänzung in das o.a. 886va Tutorial aufnehmen für VoIP Anlagen die hinter der NAT Firewall betrieben werden.
Hey,
ich bin nun endlich zum Testen gekommen.
Leider aber ohne das erhoffte Ergebnis, die beiden zusätzlichen Inspect-Anweisungen haben sich nicht ausgewirkt.
Cisco [1] schreibt in seiner Doku was zur SIP Firewall, das "ip inspect ..." kann ich jedoch nicht mehr auf ein einzelnes Interface legen (command unknown).
[1] http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_protocol_cbac_fw/c ...
Den Logging-Level für inzwischen so ziemlich alles angeschaltet, sieht es aktuell so aus:
- Telefon wurde vom Netz getrennt und wieder verbunden (erster Absatz)
- mehrere Versuche für einen Outbound Call
Viele Grüße
core
ich bin nun endlich zum Testen gekommen.
Leider aber ohne das erhoffte Ergebnis, die beiden zusätzlichen Inspect-Anweisungen haben sich nicht ausgewirkt.
Cisco [1] schreibt in seiner Doku was zur SIP Firewall, das "ip inspect ..." kann ich jedoch nicht mehr auf ein einzelnes Interface legen (command unknown).
[1] http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_protocol_cbac_fw/c ...
Den Logging-Level für inzwischen so ziemlich alles angeschaltet, sieht es aktuell so aus:
- Telefon wurde vom Netz getrennt und wieder verbunden (erster Absatz)
- mehrere Versuche für einen Outbound Call
Log Buffer (8192 bytes):
192.168.100.21, src_port:60281, dst_tableid:0, dst_addr:176.9.12.26, dst_port:80
Jan 7 22:55:25.032 CET: FIREWALL: Finding pregen session for src_tableid:0, src_addr:192.168.100.21, src_port:60281, dst_tableid:0, dst_addr:176.9.12.26, dst_port:80
... Edit (10. Jan.): der Übersicht halber entfernt, hat mit Lösung nichts zu tun ...
Jan 7 23:01:50.349 CET: FIREWALL sent a TCP pkt (192.168.100.122:53970) tcp flag:0x4 -> 173.194.35.161:80 seq 2892824903 ack 0 wnd 662, Vlan1
Jan 7 23:01:50.401 CET: FIREWALL: Finding pregen session for src_tableid:0, src_addr:192.168.100.11, src_port:4554, dst_tableid:0, dst_addr:192.168.100.255, dst_port:4554Viele Grüße
core
Ich habe es nun endlich lösen können (sogar ohne Telekom...):
Mit der Firmware 15.1 (M4) ist es nicht möglich gewesen, ausgehende VoIP-Calls aufzubauen, zumindest an einem V-DSL 50/10 MBit Anschluss.
(außerdem lag die max. Datenrate bei 8.3/2.7 MBit)
Nach einem Upgrade auf die Version 15.4 (T) läuft alles einwandfrei, die Transferrate liegt bei 44/8.5 MBit, und VoIP-Calls laufen in alle Richtungen so wie es von Anfang an hätte sein sollen...
Lösung also für alle Telekom-Kunden:
Nutzt die Firmware >= 15.4
PS an dieser Stelle, die zum Download angebotene Modem-Firmware ist in der dort aktuellsten Version ÄLTER als die System-Firmware 15.4 - und funktioniert (zumindest bei der Telekom am o.g. Anschluss) NICHT! Hier also bei der embedded Firmware bleiben.
Auch an dich, aqui, noch mal vielen Dank - ob es auch ohne die ip inspect gehen würde hab ich nun mal nicht mehr getestet, allein da auch die dadurch ausführlicheren Log/Debug Meldungen in meinem Szenario doch ganz praktisch sind.
Viele Grüße
ein total genervter core
Mit der Firmware 15.1 (M4) ist es nicht möglich gewesen, ausgehende VoIP-Calls aufzubauen, zumindest an einem V-DSL 50/10 MBit Anschluss.
(außerdem lag die max. Datenrate bei 8.3/2.7 MBit)
Nach einem Upgrade auf die Version 15.4 (T) läuft alles einwandfrei, die Transferrate liegt bei 44/8.5 MBit, und VoIP-Calls laufen in alle Richtungen so wie es von Anfang an hätte sein sollen...
Lösung also für alle Telekom-Kunden:
Nutzt die Firmware >= 15.4
PS an dieser Stelle, die zum Download angebotene Modem-Firmware ist in der dort aktuellsten Version ÄLTER als die System-Firmware 15.4 - und funktioniert (zumindest bei der Telekom am o.g. Anschluss) NICHT! Hier also bei der embedded Firmware bleiben.
Auch an dich, aqui, noch mal vielen Dank - ob es auch ohne die ip inspect gehen würde hab ich nun mal nicht mehr getestet, allein da auch die dadurch ausführlicheren Log/Debug Meldungen in meinem Szenario doch ganz praktisch sind.
Viele Grüße
ein total genervter core
Tip für dich noch:
Wenn du die Firewall mit CBAC aktiv hast kannst du auch SIP Inspection einschalten was die SIP Connections sicherer macht.
Das wird nicht wie du fälschlicherweise annimmst per Interface sondern logischerweise global gemacht, da es ja für die Firewall gilt !
Dazu muss aber eine entprechende Inbound ACL für den SIP Port UDP 5060 offen sein sonst funktioniert die SIP Inspection nicht !
Gemäß der im Cisco_886vaw_Tutorial vorgestellten Konfig musst du diese geingfügig anpassen:
!
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw sip
!
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit udp any eq 5060 any
access-list 111 permit tcp any eq domain any
access-list 111 permit gre any any
access-list 111 deny ip any any (log)
Damit rennt dann auch sichere SIP Inspection ! Getestet hier mit der IOS Version 15.3.3(M) das ist das Stable Release.
Was interessant ist: Kommen Incoming SIP Call generiert der Router eine Log Message:
IPNAT SIP SDP: Trying to parse unsupported attribute at media level
Es funktioniert aber alles fehlerfrei. Siehst du mit deiner 15.4(T) diese Message auch ?? ("show logg" zeigt sie, mit "clear logg" kannst du das Log ggf. löschen)
Kurze Frage noch: Nutzt du einen Telekom VDSL Vollanschluss (Call and Surf) für den SIP bzw. Telefonie Zugang mit dem Cisco ?
Wenn du die Firewall mit CBAC aktiv hast kannst du auch SIP Inspection einschalten was die SIP Connections sicherer macht.
Das wird nicht wie du fälschlicherweise annimmst per Interface sondern logischerweise global gemacht, da es ja für die Firewall gilt !
Dazu muss aber eine entprechende Inbound ACL für den SIP Port UDP 5060 offen sein sonst funktioniert die SIP Inspection nicht !
Gemäß der im Cisco_886vaw_Tutorial vorgestellten Konfig musst du diese geingfügig anpassen:
!
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw sip
!
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit udp any eq 5060 any
access-list 111 permit tcp any eq domain any
access-list 111 permit gre any any
access-list 111 deny ip any any (log)
Damit rennt dann auch sichere SIP Inspection ! Getestet hier mit der IOS Version 15.3.3(M) das ist das Stable Release.
Was interessant ist: Kommen Incoming SIP Call generiert der Router eine Log Message:
IPNAT SIP SDP: Trying to parse unsupported attribute at media level
Es funktioniert aber alles fehlerfrei. Siehst du mit deiner 15.4(T) diese Message auch ?? ("show logg" zeigt sie, mit "clear logg" kannst du das Log ggf. löschen)
Kurze Frage noch: Nutzt du einen Telekom VDSL Vollanschluss (Call and Surf) für den SIP bzw. Telefonie Zugang mit dem Cisco ?
Hi,
die sip-Regel habe ich bereits drin - deine genannte Log-Meldung kommt bei mir allerdings nicht.
Der Anschluss ist, soweit ich weiß, ein Telekom VDSL Call & Surf Comfort (OHNE Entertain) 50 MBit und ohne Speed-Option (also 10 MBit Upload), sowie kein Fastlink.
(mit dynamischer IP, und kein Business-Kunden-Zugang)
Anbei (auch für alle, die hier später wie ich über Google landen...) meine aktuelle, funktionierende (!) Konfiguration:
(Hinweis: die ACL 111 aus dem Tutorial ist bei mir die 102)
Wobei die Access-Listen nun, wo man auch endlich ordentlich testen kann, dann noch nähere Pflege erfahren werden.
Viele Grüße
core
die sip-Regel habe ich bereits drin - deine genannte Log-Meldung kommt bei mir allerdings nicht.
Der Anschluss ist, soweit ich weiß, ein Telekom VDSL Call & Surf Comfort (OHNE Entertain) 50 MBit und ohne Speed-Option (also 10 MBit Upload), sowie kein Fastlink.
(mit dynamischer IP, und kein Business-Kunden-Zugang)
Anbei (auch für alle, die hier später wie ich über Google landen...) meine aktuelle, funktionierende (!) Konfiguration:
(Hinweis: die ACL 111 aus dem Tutorial ist bei mir die 102)
Wobei die Access-Listen nun, wo man auch endlich ordentlich testen kann, dann noch nähere Pflege erfahren werden.
version 15.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
boot-start-marker
boot system flash:c880data-universalk9-mz.154-1.T.bin
boot-end-marker
!
!
security authentication failure rate 3 log
security passwords min-length 6
logging userinfo
logging buffered 8192
no logging console
enable secret 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
enable password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
no aaa new-model
no process cpu extended history
no process cpu autoprofile hog
memory-size iomem 10
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.99
ip dhcp ping packets 3
ip dhcp ping timeout 100
!
ip dhcp pool local
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
dns-server 192.168.100.1
domain-name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool wap1
host 192.168.100.11 255.255.255.0
client-identifier 014c.4e35.5774.70
default-router 192.168.100.1
dns-server 192.168.100.1
client-name wap1
domain-name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool wap2
host 192.168.100.12 255.255.255.0
client-identifier 014c.4e35.5774.b8
default-router 192.168.100.1
dns-server 192.168.100.1
client-name wap2
domain-name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.local
!
ip dhcp pool dect1
host 192.168.100.21 255.255.255.0
hardware-address 7c2f.806b.845e
default-router 192.168.100.1
dns-server 192.168.100.1
client-name dect1
domain-name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.local
!
!
!
no ip bootp server
ip domain name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.local
ip multicast-routing
ip inspect name Firewall tcp router-traffic
ip inspect name Firewall udp
ip inspect name Firewall sip
ip inspect name Firewall rtsp
ip inspect name Firewall ftp
ip inspect name Firewall icmp
ip inspect name Firewall pptp
ip ddns update method dyndns
HTTP
add http://XXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXX@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
interval maximum 1 0 0 0
!
ip cef
login block-for 120 attempts 3 within 60
login delay 1
login on-failure log
login on-success log
no ipv6 cef
!
!
vpdn enable
!
vpdn-group 1
! Default PPTP VPDN group
description Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 1
!
license udi pid CISCO886VA-K9 sn XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
!
username root privilege 15 password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
username remote password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
!
!
!
!
controller VDSL 0
description DTAG VDSL 50 Leitung
no cdp run
!
ip ssh version 2
!
!
!
!
!
!
!
!
!
!
interface Ethernet0
description VDSL Physical Interface
no ip address
no ip route-cache
!
interface Ethernet0.7
description VDSL Daten Verbindung
encapsulation dot1Q 7
no ip route-cache
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface FastEthernet0
description Uplink wap1
no ip address
spanning-tree portfast
!
interface FastEthernet1
description Uplink wap2
no ip address
spanning-tree portfast
!
interface FastEthernet2
description Uplink dect1
no ip address
spanning-tree portfast
!
interface FastEthernet3
no ip address
shutdown
spanning-tree portfast
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered Vlan1
peer default ip address pool pptp_dialin
no keepalive
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
interface Vlan1
description Lokales Netzwerk
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer0
description DSL Einwahl Interface
ip ddns update hostname XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.dyn.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.net
ip ddns update dyndns
ip address negotiated
ip access-group 102 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect Firewall out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@t-online.de password 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip local pool pptp_dialin 192.168.100.80 192.168.100.99
no ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip dns server
ip nat log translations syslog
ip nat inside source list 101 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0
!
!
ip access-list log-update threshold 1
dialer-list 1 protocol ip list 101
!
access-list 1 permit any
access-list 101 remark Traffic allowed to access the Internet from inside the network
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 102 remark Traffic allowed to enter the router from the Internet
access-list 102 permit gre any any
access-list 102 permit ip any any
access-list 105 remark Traffic allowed to access the router management CLI
access-list 105 permit tcp any any eq 22
!
!
line con 0
exec-timeout 5 0
login local
no modem enable
line aux 0
line vty 0 4
access-class 105 in
exec-timeout 30 0
privilege level 15
login local
transport preferred ssh
transport input ssh
!
ntp server ptbtime1.ptb.de
ntp server ptbtime2.ptb.de
ntp server ptbtime3.ptb.de
!
endViele Grüße
core
Danke fürs Feedback ! Kleine Anmerkung zu deiner ACL 102 die, mit Verlaub gesagt, eigentlich totaler Blödsinn ist, sorry !! Warum....?
Du merkst sicher selber wie unsinnig diese Regel ist, denn warum erlaubst du speziell GRE wenn du so oder so generell danach alles IP artige erlaubst ?! Das ist unsinnig.
Die Firewall ist eine CBAC Firewall wenn du Inspection nutzt. D.h. eine inbound ACL sollte ALLES verbieten um den Router nicht angreifbar zu machen.
Die Cisco Firewall sorgt dann dafür das alles was in der Inspection definiert wird dynamsich die ACL öffnet wenn interne Sessions nach extern gehen.
D.h. die Firewall macht also nur das temporär auf was intern auch gebraucht wird. Genau deshalb auch am Ende der WAN Port ACL immer ein deny any any.
Deine derzeitige ACL 102 öffnet den Router generell weit wie ein Scheunentor !!!
Mach den ct' Angriffstest und der sollte dir die Augen öffnen:
http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
Deine ACL ist also vollkommen überflüssig am Dialer Port denn sie erlaubt eh alles. Das gleiche erreichst du auch wenn du die ACL gleich ganz weglässt !
Die korrekte ACL hat folgende Statements:
Würdest du dann DNS Requests vom Router senden (was er tut da er Proxy ist), würde die Firewall die Antworten vom DNS Server blocken, da die dynamische ACL Öffnung (CBAC) nur von inbound gerouteten Sessions aus dem lokalen LAN getriggert wird ! DNS nutzt TCP und UDP
Solltest du spaßeshalber mal für einen Tag aktivieren damit du mal siehst was so einprasselt auf den Router...und nicht nur deinen !!
Fazit: Dein Router ist vollkommen offen so mit deiner ACL 102 zum Internet ! Das solltest du besser ganz schnell fixen !!
Bei NTP (Time Protokoll) müsstes du auf deinem Router auch noch "access-list 111 permit udp any eq ntp any" konfigurieren sonst bleiben auch NTP Updates des Routers selber (clock) hängen.
Was noch offen ist an Fragen:
- Eine Accessliste wird der Reihe nach abgearbeitet vom Router dabei gilt immer "First Match wins" ! Reihenfolge in der ACL ist also sehr wichtig !
- Eingehende externe Verbindungen ohne interne NAT Session ID fürs IP Protokoll 47 GRE (Teil von PPTP) erlauben
- Alle irgendwie gearteten eingehenden externen Verbindungen ohne interne NAT Session ID generell erlauben.
Du merkst sicher selber wie unsinnig diese Regel ist, denn warum erlaubst du speziell GRE wenn du so oder so generell danach alles IP artige erlaubst ?! Das ist unsinnig.
Die Firewall ist eine CBAC Firewall wenn du Inspection nutzt. D.h. eine inbound ACL sollte ALLES verbieten um den Router nicht angreifbar zu machen.
Die Cisco Firewall sorgt dann dafür das alles was in der Inspection definiert wird dynamsich die ACL öffnet wenn interne Sessions nach extern gehen.
D.h. die Firewall macht also nur das temporär auf was intern auch gebraucht wird. Genau deshalb auch am Ende der WAN Port ACL immer ein deny any any.
Deine derzeitige ACL 102 öffnet den Router generell weit wie ein Scheunentor !!!
Mach den ct' Angriffstest und der sollte dir die Augen öffnen:
http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
Deine ACL ist also vollkommen überflüssig am Dialer Port denn sie erlaubt eh alles. Das gleiche erreichst du auch wenn du die ACL gleich ganz weglässt !
Die korrekte ACL hat folgende Statements:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
Das erlaubt eingehende ICMP Steuerpakete die für den IP Paketflow wichtig sind. Ansonsten würden diese ICMPs geblockt werden da sie einen anderen Type entsprechen als die Types echo und echo request (Ping)access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
Erlaubt vom Router initierte DNS Requests (denk dran der Router ist DNS Proxy hier !), denn alles was vom Router bzw. dessen IP "direkt" kommt, unterliegt nicht dem Inspection Prozess und der dynamischen Firewall !access-list 111 permit tcp any eq domain any
Würdest du dann DNS Requests vom Router senden (was er tut da er Proxy ist), würde die Firewall die Antworten vom DNS Server blocken, da die dynamische ACL Öffnung (CBAC) nur von inbound gerouteten Sessions aus dem lokalen LAN getriggert wird ! DNS nutzt TCP und UDP
access-list 111 permit udp any eq 5060 any
Erlaubt eingehende SIP Calls wenn dein hinter dem NAT gelegenes VoIP Gerät angerufen wird ohne bestehende SIP outbound Session.access-list 111 permit gre any any
Erlaubt von außen eingehende PPTP VPN Sessionsaccess-list 111 deny ip any any (log)
DAS ist hier das wichtigste Stament, denn es BLOCKT ALLES was sonst noch von außen rein will auf dein Router oder lokales LAN ! Das ist ja der tiefere Sinn einer Firewall. Das optional "log" Stament würde noch alle Angreifer mitloggen die versuchen im Router einzubrechen oder versuchen aufs lokale LAN zuzugreifen.Solltest du spaßeshalber mal für einen Tag aktivieren damit du mal siehst was so einprasselt auf den Router...und nicht nur deinen !!
Fazit: Dein Router ist vollkommen offen so mit deiner ACL 102 zum Internet ! Das solltest du besser ganz schnell fixen !!
Bei NTP (Time Protokoll) müsstes du auf deinem Router auch noch "access-list 111 permit udp any eq ntp any" konfigurieren sonst bleiben auch NTP Updates des Routers selber (clock) hängen.
Was noch offen ist an Fragen:
- Nutzt du einen Telekom VDSL Vollanschluss (Call and Surf) für den SIP bzw. Telefonie Zugang mit dem Cisco ?
- Siehst du wenn du die Firewall "richtig" konfigurierst ggf. auch die o.a. Log Message ?
Hatte genau das gleiche Problem (IPNAT SIP SDP: Trying to parse unsupported attribute at media level) - außerdem wurde kein voice übertragen.
Das ganze hat sich mit einem einfachen 'no ip nat service sip udp port 5060' gelöst. Meldungen traten nicht mehr auf, voice wird übertragen, alles schön
Das ganze hat sich mit einem einfachen 'no ip nat service sip udp port 5060' gelöst. Meldungen traten nicht mehr auf, voice wird übertragen, alles schön
1
Super ! Danke für das Feedback.
Hier ist es so das die Log Meldung mit jedem Call auftritt. Voice funktioniert aber fehlerlos nur diese Messages die einem das Syslog vollmüllen nerven schon gewaltig...
Mal sehen...gleich mal testen ob ein no ip nat service sip udp port 5060 dem Spuk endlich ein Ende bereitet !
Hier ist es so das die Log Meldung mit jedem Call auftritt. Voice funktioniert aber fehlerlos nur diese Messages die einem das Syslog vollmüllen nerven schon gewaltig...
Mal sehen...gleich mal testen ob ein no ip nat service sip udp port 5060 dem Spuk endlich ein Ende bereitet !
