netfilter/iptables und interne VoIP Gespräche - oder wie internen Traffic fürs externe IF auch dort bearbeiten
Hallo Gruppe,
Das Problem ist mir nicht neu. Man hat z.B. einen mobilen Client mal im LAN, mal im WAN, der mit Exchange sprechen soll und man nimmt natürlich für die Konfiguration einen FQDN auf die externe IP. Damit dieser Client dann im LAN auch an den benachbarten Exchange kommt, manipuliert man das DNS, so dass Anfragen von LAN an FQDN auf interne die IP aufgelöst werden.
Jetzt aber sitze ich vor VoIP/SIP. Ich habe zwei snom Telefone und als SIP-Provider die Telekom draußen. Mittels nf_conntrack_sip und nf_nat_sip funktionieren ein- und ausgehende Gespräche wunderbar. Aber von snom zu snom (LAN intern) bekomme ich zwar den Ruf aber kein Audio.
Ich beobachte und erkläre mir das so: snomA und snmoB melden sich bei TCom an, dank NAT je mit der einen WAN-IP, die ich habe. Für den Anruf sagt snomA zu TCom ich möchte mit snomB sprechen, TCom übermittelt an snomB den Wunsch und die IP von snomA. snomB nimmt an und bestätigt ggü TCom den Vermittlungswunsch, die TCom meldet snomA die IP von snomB. Fortan sollte Audio nun zwischen den IP snomA und snmoB laufen, was ja im Falle interner Gespräche nun die selbe IP ist.
Mein netfilter hat eth1 im LAN und eth0 im WAN. Nun sind die Gesprächsdaten kein forward, wie die Steuerung/Vermittlung ggü. TCom sondern INPUT an ifLAN für ipWAN. Wenn ich nun diesen INPUT akzeptiere kommt ein ICMP not reachable, weil ja auf dem Gateway nix lauscht, sondern an den anderen Teilnehmer vermittelt werden müsste - INPUT ACCEPT allein ist also doof. Aber woher soll netfilter wissen das es sich nun um traffic für einen andern LAN-Teilnehmer handelt? Dank conntrack, wird vermutlich alles für Audio an ifWAN vorbereitet sein, meine Paket verlassen aber ifLAN nie, weil der Stack wohl entscheidet, der kürzeste Weg ist im Stack (wie sollte überhaupt ein Paket auf einem if "umlenken").
Spannend ist aber, dass appliances wie WatchGuard sowas offenbar problemlos hinbekommen. Fehlt hier ein feature in netfilter oder doch nur Wissen auf meiner Seite?
Kann ich auch interne Telefonate incl. Sprache hinbekommen und wie?
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Ronny,
Am 24.07.2014 19:57, schrieb Ronny Seffner:
Hallo Gruppe,
Das Problem ist mir nicht neu. Man hat z.B. einen mobilen Client mal im LAN, mal im WAN, der mit Exchange sprechen soll und man nimmt natürlich für die Konfiguration einen FQDN auf die externe IP. Damit dieser Client dann im LAN auch an den benachbarten Exchange kommt, manipuliert man das DNS, so dass Anfragen von LAN an FQDN auf interne die IP aufgelöst werden.
Das Problem trifft doch aber nicht auf die VoIP-Telefone zu, da die TKA, also der SIP-Provider immer außerhalb ist.
Jetzt aber sitze ich vor VoIP/SIP. Ich habe zwei snom Telefone und als SIP-Provider die Telekom draußen. Mittels nf_conntrack_sip und nf_nat_sip funktionieren ein- und ausgehende Gespräche wunderbar. Aber von snom zu snom (LAN intern) bekomme ich zwar den Ruf aber kein Audio.
Wir haben zwar nicht die Telekom als SIP-Provider, aber unsere Asterisk steht auch außerhalb im RZ, damit ist das wieder vergleichbar.
Ich beobachte und erkläre mir das so: snomA und snmoB melden sich bei TCom an, dank NAT je mit der einen WAN-IP, die ich habe. Für den Anruf sagt snomA zu TCom ich möchte mit snomB sprechen, TCom übermittelt an snomB den Wunsch und die IP von snomA. snomB nimmt an und bestätigt ggü TCom den Vermittlungswunsch, die TCom meldet snomA die IP von snomB. Fortan sollte Audio nun zwischen den IP snomA und snmoB laufen, was ja im Falle interner Gespräche nun die selbe IP ist.
Ich erinnere mich schwach, daß man bei SIP diese direkte Verbindung verbieten kann und in dem Fall auch soll. Dann geht der Datenstrom zwar komplett über den Provider, aber es funktioniert. Für Details muss ich unseren VoIP-Spezi im Haus fragen, ist zu lange her, daß ich mich selbst damit beschäftigt hab.
Spannend ist aber, dass appliances wie WatchGuard sowas offenbar problemlos hinbekommen. Fehlt hier ein feature in netfilter oder doch nur Wissen auf meiner Seite?
Das läuft bei uns über eine pfsense, dort hab ich aber nichts SIP-spezifisches drin, außer daß die betreffenden Port durchgelassen werden. Aber auch das können wir ja nochmal vergleichen.
Gruß Rico
Hallo Rico,
Ich erinnere mich schwach, daß man bei SIP diese direkte Verbindung verbieten kann und in dem Fall auch soll. Dann geht der Datenstrom zwar komplett über den Provider, aber es funktioniert. Für Details muss ich unseren VoIP-Spezi im Haus fragen, ist zu lange her, daß ich mich selbst damit beschäftigt hab.
...
Das läuft bei uns über eine pfsense, dort hab ich aber nichts SIP-spezifisches drin, außer daß die betreffenden Port durchgelassen werden. Aber auch das können wir ja nochmal vergleichen.
Ich gehe ja fest davon aus, dass das ohne Konfigurationsänderung an den SIP_Clients gehen sollte. In der Regel erfordert der Einsatz eines kommerziellen Paketfilters ja auch keine Umkonfiguration. So habe ich hier eine WatchGuard, in deren Einstellungen ich nur VoIP zulassen brauche und schon funktioniert es, ganz ohne Proxies.
Ich wäre Dir wirklich dankbar, Du findest durch Erfragen das Detail, welches ich offenbar übersehe.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Gruppe,
hier steht noch eine WatchGuard als kommerzieller Paketfilter zur Verfügung, angesteckt, VoIP erlaubt und alles wäre gut - würde ich die WatchGuard einsetzen wollen. Trotz dem die WatchGuard nun keine Konfigurationsänderungen an den SIP-Clients erfordert habe ich mich mal mit Proxies um SIP beschäftigt. In einer Konstellation funktionierten dann sogar interne Gespräche, allerdings konnten dann nicht zwei Clients dieselbe Rufnummer registrieren - hilft also auch nicht.
Verwendet hatte ich siproxd sowohl transparent als auch im Client konfiguriert. Transparent war insofern problematisch, dass die erste Identität wie von Geisterhand immer wieder auf TCP und die T-Com wechselte - hier bin ich mit den SNOM wohl noch nicht firm genug. Erst als ich dann stun zusätzlich aktivierte klappte das "interne" audio.
Ich glaube aber nach wie vor, dass es mittels iptables/netfilter funktionieren sollte. Der Einsatz kommerzieller Paketfilter erfordert schließlich auch keine Proxykonfiguration an den SIP-Clients.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo nochmal,
ich hab mich ja daran festgebissen, dass Pakete an die IP des externen Interface schon am internen als INPUT deklariert werden und ich vermute, dass so CONNTRACK nicht funktionieren wird. Ich suche also eine Möglichkeit den Gesprächstraffic der beiden SIP-Clients über das ext. Interface zu bewegen. Da ich das mit netfilter offenbar nicht ninbekomme, dachte ich advanced routing dazu zu gebrauchen. Doch selbst eine Rule für Traffic von intern zur ext. IP dann mit einer Route zu versehen, die als gateway das erste Gerät beim Provider hat half mir nicht an der Situation was zu verändern (ja ich habe die Interfaceroute aus der local Tabelle dafür entfernt).
Ich hoffe noch auf Ricos ausstehende Antwort zum Angebot, das mal für sein pfsense zu erfragen, allerdings nutzt das als BSD ja wohl kein netfilter.
Hat hier wirklich keiner eine Idee?
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
lug-dd@mailman.schlittermann.de
-
Rico Koerner -
Ronny Seffner