9
SIP Verbindung ins WAN (das eigentliche LAN) über M0n0wall
Hallo,
ich hänge gerade an einem Problem...
Die Situation:
Gäste-WLAN 10.59.x.x --- M0n0wall --- LAN 192.168.10.0
Nun möchte ich vom Gäste-Wlan eine SIP-Verbindung herstellen mit dem Telefonserver der im LAN 192.168.10.0 steht.
Firewalltechnisch ist der Weg zur IP des Telefonservers 192.168.10.40 freigegeben. Leider lässt sich kein SIP Account vom Gäste-WLAN registrien am Telefonserver.
Muss ich hier noch irgend etwas in der Firewall bei NAT einstellen?
Grüße
Touro
ich hänge gerade an einem Problem...
Die Situation:
Gäste-WLAN 10.59.x.x --- M0n0wall --- LAN 192.168.10.0
Nun möchte ich vom Gäste-Wlan eine SIP-Verbindung herstellen mit dem Telefonserver der im LAN 192.168.10.0 steht.
Firewalltechnisch ist der Weg zur IP des Telefonservers 192.168.10.40 freigegeben. Leider lässt sich kein SIP Account vom Gäste-WLAN registrien am Telefonserver.
Muss ich hier noch irgend etwas in der Firewall bei NAT einstellen?
Grüße
Touro
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 212453
Url: https://administrator.de/contentid/212453
Printed on: April 19, 2024 at 10:04 o'clock
9 Comments
Latest comment
Eigentlich nicht wenn es dir nur ums SIP geht bzw. die Registrierung geht. Voice selber wird nachher per RTP übertragen da brauchst du dann weitere Freigaben.
Deine erste Anlaufstelle sollte das Firewall Log sein !
Was sagt das denn. Wird trotz deiner Einstellung noch irgendwas geblockt ?
Hast du den Default Blocker für RFC 1918 IP Netze weggenommen vom WAN Port ?? (Haken unten in den WAN Interface Settings !)
Deine erste Anlaufstelle sollte das Firewall Log sein !
Was sagt das denn. Wird trotz deiner Einstellung noch irgendwas geblockt ?
Hast du den Default Blocker für RFC 1918 IP Netze weggenommen vom WAN Port ?? (Haken unten in den WAN Interface Settings !)
Wenn du NAT betrachtest, bist du auf der falschen Fährte.
Du machst hier sauberes Routing zwischen privaten Netzen, kein NAT.
So liegt es wohl an den Firewall Regeln.
Oder du willst, dass der WLAN-Gast über die Telefonanlage ins öffentliche Netz oder direkt über SIP mit einer SIP-Gegenstelle telefonieren soll.
GRuß
Netman
Hast du den Default Blocker für RFC 1918 IP Netze weggenommen vom WAN Port ?? (Haken unten in den WAN Interface Settings !)
Ja der Haken war entfernt...
In den Firewalllogs finde ich keine Angaben zu der Verbindung. Das Softphone im Wlannetz. 10.59.1.0 meldet beim registrieren: Time Out...
Hier noch ein Screenshot der LAN Rules der Firewall:
@MrNetman: Der WLAN-Gast soll über die Telefonanlage ins öffentliche Netz telefonieren....
Ja der Haken war entfernt...
In den Firewalllogs finde ich keine Angaben zu der Verbindung. Das Softphone im Wlannetz. 10.59.1.0 meldet beim registrieren: Time Out...
Hier noch ein Screenshot der LAN Rules der Firewall:
@MrNetman: Der WLAN-Gast soll über die Telefonanlage ins öffentliche Netz telefonieren....
@MrNetman
Doch, er macht auch NAT. Er hat ja das WAN Interface mit dem privaten LAN verbunden ! Am WAN Interface macht die Monowall per se immer NAT (wenn man es nicht deaktiviert).
Eine SIP Verbindung müsste aber damit zustandekommen
.@touro
Nimm mal spasseshalber die zusätzlichen Regeln am LAN Port weg und belasse dort nur die any zu any Default Regel die alles erlaubt !
Kannst du damit dann eine Verbindung aufbauen ?
Nur mal um wirklich zu checken ob es an den Regeln liegt !
Doch, er macht auch NAT. Er hat ja das WAN Interface mit dem privaten LAN verbunden ! Am WAN Interface macht die Monowall per se immer NAT (wenn man es nicht deaktiviert).
Eine SIP Verbindung müsste aber damit zustandekommen
.@touro
Nimm mal spasseshalber die zusätzlichen Regeln am LAN Port weg und belasse dort nur die any zu any Default Regel die alles erlaubt !
Kannst du damit dann eine Verbindung aufbauen ?
Nur mal um wirklich zu checken ob es an den Regeln liegt !
Nimm mal spasseshalber die zusätzlichen Regeln am LAN Port weg und belasse dort nur die any zu any Default Regel
Hab ich gemacht, wieder ein TimeOut vom Softphone... Also an den Regeln glaube ich liegt es nicht. Der Telefonserver ist aus dem Gäste WLAN anpingbar.....
Hallo alle zusammen,
ich bin jetzt nicht so der Netzwerkprofi, aber sollte es nicht möglich sein, dass man einfach eine DMZ anlegt, dort den Telefonserver herein stellt und dann den beiden Netzwerken (WLAN & privat) darauf den Zugriff gestattet?
Ich denke das sollte einfacher, schneller und vor allem sauberer zu lösen sein, als die Firewall vom WLAN in das
private Netzwerk aufzubohren.
Gruß
Dobby
ich bin jetzt nicht so der Netzwerkprofi, aber sollte es nicht möglich sein, dass man einfach eine DMZ anlegt, dort den Telefonserver herein stellt und dann den beiden Netzwerken (WLAN & privat) darauf den Zugriff gestattet?
Ich denke das sollte einfacher, schneller und vor allem sauberer zu lösen sein, als die Firewall vom WLAN in das
private Netzwerk aufzubohren.
Gruß
Dobby
@d.o.b.b.y: ja das wäre eine Möglichkeit, aber hier würde ich das Problem lösen indem ich es umgehe....
Ich denke es macht Sinn mit Wireshark den Datenverkehr anzuschauen, von dem Rechner im Wlan, auf welchem der SIP Client läuft....
Ich denke es macht Sinn mit Wireshark den Datenverkehr anzuschauen, von dem Rechner im Wlan, auf welchem der SIP Client läuft....
Nein das wäre ja mit Kanonen auf Spatzen... Das muss natürlich auch so gehen !
Irgendwas wird da aber blockiert, das ist sicher, denn mit der any zu any Regel hast du aus dem Gästenetz ja erstmal jeglichen Zugriff freigeschaltet. Folglich sollte der Request auch am Server ankommen.
Vermutlich öffnet der aber dynamisch andere Ports oder was auch immer so das die NAT Firewall an der Monowall sagt iss nich....
Genau DAS musst du rausbekommen ! Eigentlich stehen diese Infos immer alle im Firewall log, denn das loggt alles mit was geblockt wird. Wenn man es vorher löscht, dann der Connect Versuch macht wird eigentlich übersichtlich dokumentiert was da geblockt wird....
Es gibt 2 Möglichkeiten für eine Lösung:
1.) Du nimmst einen Wireshark Sniffer und snifferst alles am Telefonserver Port mit was dort ankommt und wie der Telefonserver antwortet !
Da kannst du ganz genau sehen WAS für Ports zurückkommen und was ggf. hängenbleibt.
Ganz wichtig ist hier STUN Support am telefonserver einzuschalten.
2.) Du konfigurierst am WAN Port einmal ein "Scheunentor" aus sicher der Regeln, will heissen das du dort mal als Source das WAN Netzwerk nimmst dann Port any und Destination auch any.
Damit erlaubst du alles eingehende am WAN Port.
Damit sollte dann sicher eine Verbindung zustandekommen.
Nun musst du nur rausbekommen was dann wirklich durchmuss und da hilft wieder der Wireshark.
Es sei denn du postest hier mal WAS dein "Telefonserver" ist, dann könnten wir für dich das Handbuch lesen und rausbekommen mit welchen Protokollen Clients mit ihm kommunizieren !
Irgendwas wird da aber blockiert, das ist sicher, denn mit der any zu any Regel hast du aus dem Gästenetz ja erstmal jeglichen Zugriff freigeschaltet. Folglich sollte der Request auch am Server ankommen.
Vermutlich öffnet der aber dynamisch andere Ports oder was auch immer so das die NAT Firewall an der Monowall sagt iss nich....
Genau DAS musst du rausbekommen ! Eigentlich stehen diese Infos immer alle im Firewall log, denn das loggt alles mit was geblockt wird. Wenn man es vorher löscht, dann der Connect Versuch macht wird eigentlich übersichtlich dokumentiert was da geblockt wird....
Es gibt 2 Möglichkeiten für eine Lösung:
1.) Du nimmst einen Wireshark Sniffer und snifferst alles am Telefonserver Port mit was dort ankommt und wie der Telefonserver antwortet !
Da kannst du ganz genau sehen WAS für Ports zurückkommen und was ggf. hängenbleibt.
Ganz wichtig ist hier STUN Support am telefonserver einzuschalten.
2.) Du konfigurierst am WAN Port einmal ein "Scheunentor" aus sicher der Regeln, will heissen das du dort mal als Source das WAN Netzwerk nimmst dann Port any und Destination auch any.
Damit erlaubst du alles eingehende am WAN Port.
Damit sollte dann sicher eine Verbindung zustandekommen.
Nun musst du nur rausbekommen was dann wirklich durchmuss und da hilft wieder der Wireshark.
Es sei denn du postest hier mal WAS dein "Telefonserver" ist, dann könnten wir für dich das Handbuch lesen und rausbekommen mit welchen Protokollen Clients mit ihm kommunizieren !
aber hier würde ich das Problem lösen indem ich es umgehe....
Warum umgehst Du das Problem?Und warum muss man erst zwei Netze sauber von einander trennen und soll sie dann doch wieder aufbohren?
Bei dem Anlegen einer DMZ bleiben beide Netze weiter schön von einander getrennt und können dennoch beide den
Telefonserver benutzen, der auch Kontakt zum Internet haben darf, aber die beiden Netze sind vom Internet getrennt bzw.
nicht von außen erreichbar, meines Erachtens ist eine DMZ genau dafür gemacht und keine so genannte "Workaround" Lösung. Aber gut das macht halt auch jeder mit sich selber ab.
Gruß
Dobby
