Hi Alexey,In your example, I saw you where sending the OPTIONS to some GWs in drouting, GWs with different IPs, so the IP-based domains should work in that case.
Now, if you have a different clients behind the same IP - I guess this is a different scenario. In this case I guess you need the AVP to control the selection of the client TLS domain. But a small question - if you interact with customers, do you still generate OPTIONS (or any locally generated requests) towards the customers ? usually you act as a sip proxy for the traffic to customers and in this case the AVP will be fine (the AVP limitation is only in local route).
Let me follow up on #1642 with a small patch that will expose the AVPs to the msg sending process.
BTW, in 3.0, the TLS mgm is completely reworked with better TLS domain selection, including SNI support .
Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 03/25/2019 09:53 PM, Alexey Vasilyev wrote:
Hi Bogdan, It would be nice to get rid of these AVPs, and select client domain by destination IP, but the problem that I have only 1 destination gw IP for all customers domains. I have cloud platform, which I’d like to connect from OpenSIPS. And I have many customers with their domains. So the only way to choose client tls domain is AVP. And why not to allow manipulate AVPs in local route? I modified modules/tm/uac.c little bit, and now I can select TLS client domain with AVP from local_route. https://github.com/OpenSIPS/opensips/issues/1642 But I’m not sure about the code. And sorry, that I marked it as bug, I thought that it is normal to work with AVP variables from local_route. I have another issue, that OpenSIPS reuses TLS connections the same way as regular TCP connections, but it should not. For reusing TCP connection we check, if connection with the same dst IP:PORT exists. But for TLS it is not enough. We additionally should check, what certificate uses this connection (or what domain it is related). If on server side we have SNI, why not to have more control for client TLS side? ----- Alexey Vasilyev [email protected]25 Mar 2019, в 18:37, Bogdan-Andrei Iancu <[email protected]> написал(а): Hi Alexey, Well, the AVPs (as variables) are not visible for the TLS send operation. In local route, the actual "send" is outside the route context, so the AVP you set in the local route are not impacting the later TLS "send". On the other hand, you can select the TLS certificate to use based on the destination IP of the TLS connection (the IP of the GW, in your case). Check this https://opensips.org/html/docs/modules/2.4.x/tls_mgm.html#domains-param . And when you define the client_domain, you set the IP of your GW : modparam("tls_mgm", "client_domain", "test1=GW_IP:GW_PORT") and you do not need the local route anymore, as the test1 TLS domain will be automatically picked when sending GW_IP:GW_PORT. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 03/20/2019 02:40 PM, vasilevalex wrote:Hi all. OpenSIPS 2.4.4 I have 2 gateways in Dynamic Routing module table. For both gateways I have different sockets: address: gw1, socket: tls:<IP1>:5061 address: gw2, socket: tls:<IP2>:5061 IP1 has certificate for TLS sip.domain1.com IP2 has certificate for TLS sip.domain2.com And something like this for tls management module: loadmodule "tls_mgm.so" modparam("tls_mgm", "client_domain_avp", "tls_cli_dom") modparam("tls_mgm", "client_domain", "test1") modparam("tls_mgm","certificate", "[test1]/etc/opensips/tls/test1/fullchain.pem") modparam("tls_mgm","private_key", "[test1]/etc/opensips/tls/test1/privkey.pem") modparam("tls_mgm","verify_cert", "[test1]0") modparam("tls_mgm","require_cert", "[test1]0") modparam("tls_mgm","tls_method", "[test1]TLSv1") modparam("tls_mgm", "client_domain", "test2") modparam("tls_mgm","certificate", "[test2]/etc/opensips/tls/test2/fullchain.pem") modparam("tls_mgm","private_key", "[test2]/etc/opensips/tls/test2/privkey.pem") modparam("tls_mgm","verify_cert", "[test2]0") modparam("tls_mgm","require_cert", "[test2]0") modparam("tls_mgm","tls_method", "[test2]TLSv1") #Default domain modparam("tls_mgm","certificate", "/etc/opensips/tls/test1/fullchain.pem") modparam("tls_mgm","private_key", "/etc/opensips/tls/test1/privkey.pem") modparam("tls_mgm","verify_cert", "0") modparam("tls_mgm","require_cert", "0") modparam("tls_mgm","tls_method", "TLSv1") modparam("tls_mgm", "server_domain", "srv2=IP2:5061") modparam("tls_mgm","certificate", "[srv2]/etc/opensips/tls/test2/fullchain.pem") modparam("tls_mgm","private_key", "[srv2]/etc/opensips/tls/test2/privkey.pem") modparam("tls_mgm","verify_cert", "[srv2]0") modparam("tls_mgm","require_cert", "[srv2]0") modparam("tls_mgm","tls_method", "[srv2]TLSv1") Server part of TLS works fine. But I want OPTIONS to these gateways to be send with correct TLS certificate. local_route { if (is_method("OPTIONS")) { # Get IP for outgoing socket $var(ip_out) = $(fs{s.select,1,:}); switch($var(ip_out)) { case "IP1": $avp(tls_cli_dom) = "test1"; break; case "IP2": $avp(tls_cli_dom) = "test2"; break; } xlog("AVP for TLS: $avp(tls_cli_dom) \n"); } } So AVP for choosing client domain is set correctly during sending OPTIONS. OpenSIPS uses different sockets for sending OPTIONS, but default TLS domain for both gateways. What's wrong? ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
