handoku
Goto Top

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:

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.XX
Starting 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     ntp

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?

0_interface
1_wan
2_interface
3_interface_2
4_nat1
5_nat2
6_nat3
7_nat_4
8_firewall
9_lan

Content-Key: 609192

Url: https://administrator.de/contentid/609192

Printed on: April 24, 2024 at 13:04 o'clock

Member: aqui
aqui Oct 01, 2020 updated at 16:37:09 (UTC)
Goto Top
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.
Member: HanDoku
HanDoku Oct 02, 2020 at 07:01:58 (UTC)
Goto Top
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.
Member: aqui
aqui Oct 02, 2020 at 07:26:31 (UTC)
Goto Top
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).
Member: HanDoku
HanDoku Oct 02, 2020 at 10:24:11 (UTC)
Goto Top
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?
Member: aqui
aqui Oct 02, 2020 updated at 10:41:22 (UTC)
Goto Top
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.
Member: HanDoku
HanDoku Oct 02, 2020 at 11:13:17 (UTC)
Goto Top
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.
Member: HanDoku
HanDoku Oct 14, 2020 at 11:28:14 (UTC)
Goto Top
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.
Member: aqui
aqui Oct 14, 2020 at 13:04:14 (UTC)
Goto Top
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 ?!
Member: HanDoku
HanDoku Oct 14, 2020 at 13:24:43 (UTC)
Goto Top
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.
Member: falscher-sperrstatus
falscher-sperrstatus Oct 14, 2020 at 13:29:46 (UTC)
Goto Top
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.

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...