[HOWTO] Firewallregeln für VoIP

Antworten
Nachricht
Autor
sparkie
Erfahrener
Erfahrener
Beiträge: 50
Registriert: 27. Okt 2017 05:52
Status: Offline

[HOWTO] Firewallregeln für VoIP

#1 Beitrag von sparkie » 9. Nov 2017 07:21

[ einen Forenbereich 'Firewall' gibt es hier anscheinend nicht. Der Beitrag bezieht sich nicht auf eine bestimmte Hardware sondern auf ein linuxbasierendes System mit netfilter-Standardeinstellungen. Deswegen habe ich das mal hierher kopiert ]

anbei meine Vorgehensweise, die sich allgemein bewaehrt hat. Sie funktioniert hier mit ueber 6 verschiedenen VoIP-Anbietern.

Ausgangslage:
- ich betreibe einen Asterisk hinter einem Router (port restricted cone)
- der Asterisk ist SIP Server zu Geraeten im lokalen Netz
- der Asterisk ist SIP Client zu Servern div. VoIP Provider im Internet
- der 5060 wird bei mir nur per conntracking (nach register) von extern->intern geforwarded
- der RTP Portbereich wird statisch von extern->intern geforwarded
- ich versuche mit moeglichst wenig expliziten IP-Daten der Provider auszukommen.

empfohlene Konfiguration:
- folgende relevanten Einstellungen im Router:

Code: Alles auswählen


iptables:
SIP_RTP_RANGE = "14532:14565"

-A FORWARD -i $EXT_IF -o $IN0_IF -d $DIMBIP -p udp --dport $SIP_RTP_RANGE -j ACCEPT      
-A PREROUTING  -t nat -i $EXT_IF -d $EXT_IP -p udp --dport $SIP_RTP_RANGE -j DNAT --to $DIMBIP

/proc/sys:
/bin/echo 70 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

- fuer ip_conntrack_udp_timeout ist standardmaessig nur 30s eingetragen was fuer 60s Keepalives zu wenig ist -> deswegen erhoehen auf 70s
- durch die Keepalives (alle 60s) wird der SIP Port zuerst fuer 70s, anschliessend nach dem 2. Keepalive 180s (Standard ip_conntrack_udp_timeout_stream) offengehalten

- folgende relevanten Einstellungen im Asterisk:

Code: Alles auswählen


/etc/asterisk/rtp.conf:
[...]
rtpstart=14532
rtpend=14564
[...]

/etc/asterisk/sip.conf:
[...]
[general]
bindport=5060
qualify=no
nat=no
externaddr=$EXT_IP
localnet=192.168.0.0/255.255.0.0
[...]

[...]
[129839842]
type=peer
qualify=yes      ; defaults to 60s
[...]

Code: Alles auswählen

legende:
SIP_RTP_RANGE - Portbereich fuer RTP (umfasst rtpend+1 wegen RTCP)
EXT_IF        - externes Interface (zum Internet)
IN0_IF        - internes Interface (zum lokalen Netz)
DIMBIP        - lokale IP Asterisk
EXT_IP        - externe IP (oeffentliche IP Internet)
diese Konfiguration funktioniert mit allen von mir bislang genutzten VoIP Providern (inklusive neuem Vodafone-SIP nach Routerfreiheit)
PBX Functionality:___ISDN-SIP Gateway (TE/NT-mode)
PBX Software:________debian 9 + asterisk 13.14.1 + dahdi-linux 2.11.1
PBX Hardware:________Intel D945GSEJT + HFC-4S (Swyx 4xS0 SX2 QuadBri PCI)
CABLE Modem:_________Technicolor TC4400
CABLE Router:________Jetway JNF9HB-2930 + Delock MiniPCIe 2x GbE + debian 9 + some hand-crafted firewalling stuff
FRITZ!Box:___________nein danke

Benutzeravatar
woprr
Fan
Fan
Beiträge: 112
Registriert: 25. Okt 2017 20:13
Status: Offline

[HOWTO] Firewallregeln für VoIP

#2 Beitrag von woprr » 10. Nov 2017 22:59

sparkie hat geschrieben:
9. Nov 2017 07:21
- der RTP Portbereich wird statisch von extern->intern geforwarded
Ist das wirklich nötig? Da * die zumeist symmetric RTP connection outbound aufbaut ist das doch schon per conntrack offen?
SFLphone, Twinkle, CallWeaver als Standalone T.38/37 FAX-Server am NAT der UM Connect Box.
Lenovo Moto G5, Android 7.0 mit CSipSimple.
Provider: de.dus.net (T.38 FoIP), sipgate.de, dellmont.lu, netvoip.ch, unitymedia.de

sparkie
Erfahrener
Erfahrener
Beiträge: 50
Registriert: 27. Okt 2017 05:52
Status: Offline

[HOWTO] Firewallregeln für VoIP

#3 Beitrag von sparkie » 11. Nov 2017 10:14

ja:-)
ich hatte definitiv bei Anrufweiterleitungen von extern nach extern (ueber den internen '*') schon Faelle, dass kein Audio zustande kam. Ein Blick in den 'tcpdump' hat dann gezeigt, dass von extern die ersten RTP packets eintrudelten und von der Firewall geblockt wurden. Der '*' im internen Netz hat keine Anstalten gemacht, selbst mal ein RTP packet zu schicken. So wartet einer auf den anderen und nix passiert. Bei statischem Port-Forwarding hingegen kann dieses Problem natuerlich mehr auftreten.

Ich schaetze, dass Hardware- Endgeraete sich wesentlich NAT-freundlicher verhalten und so frueh wie moeglich selbst was nach draussen schicken um die Verbindung zu oeffnen. Aber ein '*' (zumindest in meiner damaligen Version) schert sich da nicht drum.
PBX Functionality:___ISDN-SIP Gateway (TE/NT-mode)
PBX Software:________debian 9 + asterisk 13.14.1 + dahdi-linux 2.11.1
PBX Hardware:________Intel D945GSEJT + HFC-4S (Swyx 4xS0 SX2 QuadBri PCI)
CABLE Modem:_________Technicolor TC4400
CABLE Router:________Jetway JNF9HB-2930 + Delock MiniPCIe 2x GbE + debian 9 + some hand-crafted firewalling stuff
FRITZ!Box:___________nein danke

Benutzeravatar
woprr
Fan
Fan
Beiträge: 112
Registriert: 25. Okt 2017 20:13
Status: Offline

[HOWTO] Firewallregeln für VoIP

#4 Beitrag von woprr » 13. Nov 2017 06:43

Ja, hallo, das ist ein typischer Bug, an Digium melden oder fixen die immer noch keine Bugs?
SFLphone, Twinkle, CallWeaver als Standalone T.38/37 FAX-Server am NAT der UM Connect Box.
Lenovo Moto G5, Android 7.0 mit CSipSimple.
Provider: de.dus.net (T.38 FoIP), sipgate.de, dellmont.lu, netvoip.ch, unitymedia.de

sparkie
Erfahrener
Erfahrener
Beiträge: 50
Registriert: 27. Okt 2017 05:52
Status: Offline

[HOWTO] Firewallregeln für VoIP

#5 Beitrag von sparkie » 13. Nov 2017 07:28

gegen welche Spec soll es verstossen? Naja, wenn ich ins Jira schaue, dann kann ich nicht sagen, dass die keine Bugs fixen:-)
PBX Functionality:___ISDN-SIP Gateway (TE/NT-mode)
PBX Software:________debian 9 + asterisk 13.14.1 + dahdi-linux 2.11.1
PBX Hardware:________Intel D945GSEJT + HFC-4S (Swyx 4xS0 SX2 QuadBri PCI)
CABLE Modem:_________Technicolor TC4400
CABLE Router:________Jetway JNF9HB-2930 + Delock MiniPCIe 2x GbE + debian 9 + some hand-crafted firewalling stuff
FRITZ!Box:___________nein danke

Benutzeravatar
woprr
Fan
Fan
Beiträge: 112
Registriert: 25. Okt 2017 20:13
Status: Offline

[HOWTO] Firewallregeln für VoIP

#6 Beitrag von woprr » 13. Nov 2017 07:33

Melde es. Specs sind Sache der Entwickler, nicht der User.
SFLphone, Twinkle, CallWeaver als Standalone T.38/37 FAX-Server am NAT der UM Connect Box.
Lenovo Moto G5, Android 7.0 mit CSipSimple.
Provider: de.dus.net (T.38 FoIP), sipgate.de, dellmont.lu, netvoip.ch, unitymedia.de

Antworten

Zurück zu „Sonstige“