10
Konfiguration der pfSense mit Starface-PBX (Asterisk)
So langsam werde ich warm mit der pfSense 2.4.5 auf einer IPU672, daher zunächst herzlichen Dank an @aqui für die Anleitung IPsec VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten, mit der die VPN-Anbindung wunderbar geklappt hat.
Jetzt gerade hapert es aber mit der Anbindung unserer Starface-Telefonanlage (ergo Asterisk).
Folgendes Setting: Wir haben von Vodafone ein /28er Subnetz bekommen. Die erste nutzbare IP habe ich der pfSense zugewiesen, die zweite will ich für die Starface-Anlage einsetzen und im weiteren Verlauf über OPT1 einbinden. Jetzt gerade hängt sie aber noch wie alle anderen Geräte auch auf LAN.
Internet läuft, VPN auch.
Die Telefone können sich aber nicht bei der Starface-PBX anmelden - und zwar sowohl aus dem LAN als auch aus dem WAN heraus nicht.
Wenn ich nmap bemühe, zeigt sich, dass die für die Telefonie wesentlichen Ports gefiltert werden:
Die pfSense Firewall-Logs melden allerdings keine geblockten Anfragen für diese IP.
Beim Setup habe ich mich an der Anleitung pfSense port settings for Asterisk FreePBX mit 1:1 NAT orientiert.
Ich habe offensichtlich irgendwas wesentliches übersehen. Was könnte das sein?
Jetzt gerade hapert es aber mit der Anbindung unserer Starface-Telefonanlage (ergo Asterisk).
Folgendes Setting: Wir haben von Vodafone ein /28er Subnetz bekommen. Die erste nutzbare IP habe ich der pfSense zugewiesen, die zweite will ich für die Starface-Anlage einsetzen und im weiteren Verlauf über OPT1 einbinden. Jetzt gerade hängt sie aber noch wie alle anderen Geräte auch auf LAN.
Internet läuft, VPN auch.
Die Telefone können sich aber nicht bei der Starface-PBX anmelden - und zwar sowohl aus dem LAN als auch aus dem WAN heraus nicht.
Wenn ich nmap bemühe, zeigt sich, dass die für die Telefonie wesentlichen Ports gefiltert werden:
sudo nmap -sS -sU -p U:53,123,1902,10000-20000,3090,5060,T:53,80,443,3090,5060-5061,5222,50080-50081 37.24.XX.XXStarting Nmap 7.80 ( https://nmap.org ) at 2020-10-01 13:10 CEST
Nmap scan report for b2b-37-24-XX-XX.unitymedia.biz (37.24.XX.XX)
Host is up (0.00021s latency).
Not shown: 10004 open|filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
3090/tcp filtered stss
5060/tcp filtered sip
5061/tcp filtered sip-tls
5222/tcp filtered xmpp-client
50080/tcp filtered unknown
50081/tcp filtered unknown
53/udp open domain
123/udp open ntpDie pfSense Firewall-Logs melden allerdings keine geblockten Anfragen für diese IP.
Beim Setup habe ich mich an der Anleitung pfSense port settings for Asterisk FreePBX mit 1:1 NAT orientiert.
Ich habe offensichtlich irgendwas wesentliches übersehen. Was könnte das sein?
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: 609192
Url: https://administrator.de/contentid/609192
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
10 Kommentare
Neuester Kommentar
Was etwas unverständlich und verwirrend ist ist dein IP Adress Design für die VoIP Anlage. Warum will man die mit einer öffentlichen IP versehen und VOR die Firewall legen ??
Normal liegt die Anlage mit den Telefonen im internen LAN idealerweise in einem eigenen Voice VLAN. Was ist also deine Intention diese ungeschützt direkt im Internet zu exponieren ?
Oder ist das jetzt so zu verstehen das sie intern liegt aber in z.B. einer DMZ ?
Dann richtest du unter "Firewall" eine Virtual IP ein in der pfSense mit einer der freien /28er IP Adressen und mappst diese IP auf die interne der PBX.
Normal liegt die Anlage mit den Telefonen im internen LAN idealerweise in einem eigenen Voice VLAN. Was ist also deine Intention diese ungeschützt direkt im Internet zu exponieren ?
Oder ist das jetzt so zu verstehen das sie intern liegt aber in z.B. einer DMZ ?
Dann richtest du unter "Firewall" eine Virtual IP ein in der pfSense mit einer der freien /28er IP Adressen und mappst diese IP auf die interne der PBX.
1
Intention war eigentlich nur, die PBX über eine eigene statische IP über WAN erreichbar zu machen.
Das 1:1 NAT scheint ein gängiges Setup zu sein, das abgesehen von dem bereits zitierten Konfigurationsvorschlag unter anderem auch von netgate unter Configuring NAT for a VoIP PBX vorgeschlagen wird.
Meinem Verständnis nach liegt die öffentliche IP ja nicht wirklich VOR der Firewall, die Firewall-Regeln greifen, wie netgate unter Risks of 1:1 NAT beschreibt. Wobei mich da beim nochmaligen nachlesen gerade der netgate-Hinweis unter 1:1 NAT on the WAN IP, aka “DMZ” on Linksys wieder etwas verunsichert.
Ich könnte jetzt natürlich auf reines Portforwarding auf die IP der pfsense umstellen und sehen, ob es damit klappt. Trotzdem interessiert mich, was beim derzeitigen Setup schief hängt, ich würde das gerne verstehen.
Vielleicht das noch als Hintergrundinfo: Ich habe hier keine tolle Testumgebung. Ich konfiguriere die pfSense lokal/offline und tausche dann den alten Draytek-Router gegen die pfSense. Jeder Test bedeutet für meine HomeOffice-Kollegen einen Ausfall von Telefonie und RDP.
Das 1:1 NAT scheint ein gängiges Setup zu sein, das abgesehen von dem bereits zitierten Konfigurationsvorschlag unter anderem auch von netgate unter Configuring NAT for a VoIP PBX vorgeschlagen wird.
Meinem Verständnis nach liegt die öffentliche IP ja nicht wirklich VOR der Firewall, die Firewall-Regeln greifen, wie netgate unter Risks of 1:1 NAT beschreibt. Wobei mich da beim nochmaligen nachlesen gerade der netgate-Hinweis unter 1:1 NAT on the WAN IP, aka “DMZ” on Linksys wieder etwas verunsichert.
Ich könnte jetzt natürlich auf reines Portforwarding auf die IP der pfsense umstellen und sehen, ob es damit klappt. Trotzdem interessiert mich, was beim derzeitigen Setup schief hängt, ich würde das gerne verstehen.
Vielleicht das noch als Hintergrundinfo: Ich habe hier keine tolle Testumgebung. Ich konfiguriere die pfSense lokal/offline und tausche dann den alten Draytek-Router gegen die pfSense. Jeder Test bedeutet für meine HomeOffice-Kollegen einen Ausfall von Telefonie und RDP.
Intention war eigentlich nur, die PBX über eine eigene statische IP über WAN erreichbar zu machen.
Und genau DAS machst du ja mit der Virtual IP die auf die interne IP der PBX mappt ?! Aber das hast du scheinbar nicht gemacht.Meinem Verständnis nach liegt die öffentliche IP ja nicht wirklich VOR der Firewall,
Wenn du mit der Virtual IP arbeitest dann nicht, das ist richtig. Die Firewall antwortet zwar auf Zugriffe auf diese IP aber im Hindergrund arbeitet das Regelwerk.Ich könnte jetzt natürlich auf reines Portforwarding auf die IP der pfsense umstellen
Davon kann man nur dringenst abraten. Ist auch unsinnig wenn man ein öffentliches /28er Netz hat und dafür eine eigene IP verwenden kann (Virtual IP).Intention war eigentlich nur, die PBX über eine eigene statische IP über WAN erreichbar zu machen.
Und genau DAS machst du ja mit der Virtual IP die auf die interne IP der PBX mappt ?! Aber das hast du scheinbar nicht gemacht.Genau daran hakt es bei mir gedanklich.
Ich habe offensichtlich irgendwas wesentliches übersehen.
Wo in den Einstellungen, die ich gepostet habe, steckt denn der Fehler?
Du benutzt keinerlei Virtual IP bzw. hast das gar nicht konfiguriert !!
Du arbeitest lediglich mit Port Weiterleitung was natürlich fatal ist.
https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses ...
Zudem hat dein WAN Port Regelwerk ein paar grobe fehler die eine Funktion nach deiner Methode auch verhindern.
Punkt 1 ist das die VPN Destination niemals "Any" sein sollte sondern immer der WAN Port selber ! Dieser ist ja das Ziel von VPN Verbindungen aber niemals any.
Eine Sicherheitsrisiko.
Punkt 2 ist dein VNC Zugang. Als Destination Port hast du oben die 59xx Ports definiert diese aber unten in den WAN Port Rules nicht freigegeben. Folglich wird jeder TCP 59xx Traffic geblockt. Das sollte dir auch so in den Firewall Logs angezeigt werden.
So oder so ist diese Konfig sehr umständlich und eine ziemliche Frickelei und wäre mit einer Virtual IP besser und eleganter gelöst.
Du arbeitest lediglich mit Port Weiterleitung was natürlich fatal ist.
https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses ...
Zudem hat dein WAN Port Regelwerk ein paar grobe fehler die eine Funktion nach deiner Methode auch verhindern.
Punkt 1 ist das die VPN Destination niemals "Any" sein sollte sondern immer der WAN Port selber ! Dieser ist ja das Ziel von VPN Verbindungen aber niemals any.
Eine Sicherheitsrisiko.
Punkt 2 ist dein VNC Zugang. Als Destination Port hast du oben die 59xx Ports definiert diese aber unten in den WAN Port Rules nicht freigegeben. Folglich wird jeder TCP 59xx Traffic geblockt. Das sollte dir auch so in den Firewall Logs angezeigt werden.
So oder so ist diese Konfig sehr umständlich und eine ziemliche Frickelei und wäre mit einer Virtual IP besser und eleganter gelöst.
1
Okay, das sehe ich mir alles nochmal an.
Bei der IPsec-Einrichtung hat die pfSense bei mir die WAN Port Regeln übrigens nicht automatisch eingerichtet. Vielleicht ist es sinnvoll, die von Dir geschilderte "Any"-Problematik in Deinem Tutorial Firewall Regeln für IPsec einrichten nochmal explizit zu thematisieren.
Bei der IPsec-Einrichtung hat die pfSense bei mir die WAN Port Regeln übrigens nicht automatisch eingerichtet. Vielleicht ist es sinnvoll, die von Dir geschilderte "Any"-Problematik in Deinem Tutorial Firewall Regeln für IPsec einrichten nochmal explizit zu thematisieren.
Zurück auf Los, ich lasse die VOIP-Clients nun über einen IPsec-Tunnel auf die Starface-Anlage zugreifen.
Der Tunnel ist erfolgreich eingerichtet. Bei einem ersten Telefonie-Test hat es fast geklappt, d.h. die Rufe wurden aufgebaut und es kam eine Verbindung zustande. Allerdings war die Audio-Übertragung einseitig, d.h. wir konnten die Kollegen im HomeOffice zwar hören, sie uns aber leider nicht.
Ich tippe darauf, dass die ausgehenden UDP-Pakete nicht richtig ins VPN geleitet werden. Woran kann das liegen? Muss evt. eine NAT-Outbound-Regel hinzugefügt werden und wie sollte die wohl aussehen? Bislang gibt es dort im wesentlichen nur eine Regel für das Outbound-NAT der Telefonanlage in Richtung WAN.
Der Tunnel ist erfolgreich eingerichtet. Bei einem ersten Telefonie-Test hat es fast geklappt, d.h. die Rufe wurden aufgebaut und es kam eine Verbindung zustande. Allerdings war die Audio-Übertragung einseitig, d.h. wir konnten die Kollegen im HomeOffice zwar hören, sie uns aber leider nicht.
Ich tippe darauf, dass die ausgehenden UDP-Pakete nicht richtig ins VPN geleitet werden. Woran kann das liegen? Muss evt. eine NAT-Outbound-Regel hinzugefügt werden und wie sollte die wohl aussehen? Bislang gibt es dort im wesentlichen nur eine Regel für das Outbound-NAT der Telefonanlage in Richtung WAN.
wir konnten die Kollegen im HomeOffice zwar hören, sie uns aber leider nicht.
Klassiker wenn irgendwo NAT gemacht wird und die dynamischen RTP Ports einseitig im NAT hängen bleiben.Auf einer Seite bleiben also die RTP Ports an der NAT Firewall hängen. Verwunderlich, denn in einem transparenten IPsec Tunnel gibt es gar kein NAT. Es sei denn man hat das wissentlich eingeschaltet ?!
Hast du eine any to any Regel im IPsec Interface auf der FW ??
NAT darfst du auf gar keinen Fall benutzen im internen Tunnel. Das wäre ja auch Blödsinn, denn seine eigenen internen IP Netze NATet man natürlich niemals. Wozu sollte das auch gut sein ?!
NAT habe ich für den Tunnel nirgendwo bewusst eingeschaltet und die Firewall-Regel für IPsec steht für alle Protokolle auf any to any ... daher bin ich gerade etwas ratlos.
Zitat von @HanDoku:
NAT habe ich für den Tunnel nirgendwo bewusst eingeschaltet und die Firewall-Regel für IPsec steht für alle Protokolle auf any to any ... daher bin ich gerade etwas ratlos.
NAT habe ich für den Tunnel nirgendwo bewusst eingeschaltet und die Firewall-Regel für IPsec steht für alle Protokolle auf any to any ... daher bin ich gerade etwas ratlos.
Ist das Ding jetzt durch oder brauchst du noch Support (@Status:Gelöst). Any-Any macht das Problem nicht wirklich obsolet...Wenn du willst, schreib mir gerne ne PN für Support am Problemkind...
