ich baue über IKEv2/IPsec eine Verbindung zu einem Netzwerk auf und verbinde mich mit einem SIP-Client mit der pascom TK. Nun habe ich das Problem, dass ich im Büro keine Stimme höre. Am Client kann ich die Stimme hören.
Verwendet wird ein Router der Firma Mikrotik und auch dessen IPsec-Funktion.
Was funktioniert:
Wenn ich in der pascom beim Gerät “NAT aktiviert” auf “JA” stelle, dann funktioniert es.
Ich hätte es aber gerne, ohne dass ich “NAT aktiviert” auf “JA” setzen muss.
Ich gehe davon aus, dass ich am Router etwas einstellen muss, da anscheinend ein internes NAT stattfindet? Leider bin ich etwas überfragt, was genau geändert werden muss.
@HExSM Zum Mikrotik kann ich Dir leider auch (noch) nichts sagen, den habe ich selber erst seit einigen Tagen und noch nicht einmal im Echtbetrieb, weil ich dazu alle alle Tunnel umbauen müsste.
Was mich jedoch rein für mein eigenes Verständnis interessiert ist, was Dich daran “stört”, dass Du NAT aktivieren musst? Ich meine, dafür ist die Einstellung ja schließlich da.
Und soweit ich weiß, ist das doch bei allen VPN-Tunneln so, dass da eine NAT-Regel greift. Zumindest habe ich es bisher noch keinen Tunnel gesehen, der ohne auskommt. Da ich gerne dazu lerne, bin ich auf die Antwort von denen gespannt, die sich mit Mikrotik etc. tiefgreifend auskennen und hoffe zusammen mit Dir auf eine Erklärung.
Und soweit ich weiß, ist das doch bei allen VPN-Tunneln so, dass da eine NAT-Regel greift
nein deswegen ja VPN. Du brauchst nur NAT, wenn das Telefon die TK-Anlage nicht direkt erreichen kannst. Beispiel: kann die Anlage das Telefon anpingen UND kann das Telefon die Anlage anpingen, brauchst Du KEIN NAT. Geht eines von beiden oder beides nicht, brauchst Du NAT.
nat=yes lässt den Asterisk wesentlich großzügiger mit den IP/Ports im SIP+IP Header (oder nur in einem mir gerade entfallen) umgehen, deswegen funktioniert es dann. Wie aber schon richtig erwähnt wurde, bei einem Site-to-Site VPN sollte NAT ja gerade nicht notwendig sein, ich vermute eher, dass unter IP->Firewall: Service Ports sip aktiviert ist (SIP ALG) oder du für deinen IPsec Tunnel keine NAT Regel mit Accept für diese Verbindungen hinterlegt hast und ggf eine andere NAT Regel greift und unabsichtlich NATed. Ich vermute aber eher ersteres, da bei zweiterem die Policy i.d.R. auch nicht richtig greift.
Keine Ahnung wie man hier NAT für IPsec deaktivieren kann (falls das überhaupt möglich ist).
Was mir in der Connection Table noch aufgefallen ist und den Verdacht mit dem fehlerhaften NAT bekräftigt ist, dass die REPLY-DST-ADDRESS für die RTP-Verbindung nicht passt, was wohl auch den Fehler verursacht:
versuche mal als erste NAT Regel
add action=accept chain=srcnat dst-address=192.168.2.0/24
zu hinterlegen (und auf der anderen Seite für dst-addres=192.168.1.0/24)
wenn auch das nicht hilft müsste man sich via tcpdump mal ansehen, ob überhaupt rtp vom client zur Anlage ankommt. Ich vermute in den filter regeln ist zwischen beiden Netzen alles erlaubt?
am Anfang der NAT-Tabelle hinzufüge, dann scheint es zu funktionieren. In der Connection Table wird dann aber auch nur noch der RTPC-Port angezeigt. Einen RTP-Port scheint es zumindest in der Connection Table nicht mehr zu geben.
Kannst du mir erklären was diese Regel jetzt genau macht? Laut Wiki werden bei “accept” die nachfolgenden NAT-Regeln nicht mehr ausgeführt. Heißt das jetzt, dass doch eine der anderen Regeln schuld ist? Aber die haben doch nichts mit dem RTP-Stream zu tun oder wird vielleicht die masquerade Regel angewendet, weil die IPsec-Verbindung über das WAN-Interface läuft? Das müsste ich mal noch prüfen.
da hast du mich kalt erwischt, wirklich gut erklären kann ich es leider nicht, ggf kannst du folgendes Diagramm besser deuten als ich https://wiki.mikrotik.com/wiki/File:Packet_Flow_Example_4c.png
Die SRC-NAT Table (im Postrouting) wird also schonal vor dem Prüfen der Policy durchlaufen und deine masquerade Regel greift. Dann kommt die Policy zum tragen und kapselt das Paket (bereits mit der übersetzten Quelle). In deinem Fall mit einer Policy bei der nur das Ziel mit dem remote LAN bestimmt ist, versteh ich das auch noch, aber die Policy würde auch greifen, wenn als Source-IP das lokale LAN verlangt wird. Ich denke hier wird die SRC-NAT Tabelle bereits berücksichtigt und es wird die Ursprüngliche SRC für die Policy herangezogen, sonst könnte es ja nicht funktionieren.
Ich merke mir einfach, dass ich diese accept Regeln immer im Falle eines Site-to-Site IPsecs brauche, obige Annahme ankzeptiere ich einfach, ob das der Wahrheit entspricht kann ich dir leider nicht garantieren.
deine Erklärung klingt im großen und ganzen genau so wie es im Mikrotik Forum beschrieben wurde. Vielen Dank für deine Mühe und die Lösung des Problems
