4 Sep
2011
4 Sep
'11
1:53 a.m.
We are trying to configure Kamailio (3.1.x) as a "boarder proxy" where it acts
as the front for various carrier gateways so that internal UACs and UASs are unaware of
the carrier gateways.
Let me try to present a clear picture of our setup.
1. Kamailio has several NICs (physical or vlan). Each on a different subnet. One
subnet is internal/has routes for internal. Other subnets are private connections to
carriers or a route to public Internet.
2. All of these subnets are non-routable from Internet. In addition , the carrier
private connections are not routable internally.
3. Connection to public internet is via a FW/NAT (one-to-one NAT), which maps to one
of the interfaces.
4. All internal UAC/UAS connect on the internal subnet.
5. We are using RTPProxy (at least one instance per carrier) to relay media between
internal and carrier subnets
We are able to make this setup up work great except for one scenario. One of the carriers
is only reachable via public Internet. Due to security requirements, our Kamailio cannot
have a public IP address and must use FW/NAT. I guess this scenario is "Proxy behind
NAT" and not really encouraged. But I would like to see if there is a way to make
this work. We cannot use the "advertised_address" since it changes the IP for
every "route".
We were able to get this mostly working by doing the following
1. mhomed=1
2. Small patch in the rtpproxy module so that force_rtp_proxy actually uses the IP
address passed (public IP).
3. Using request_route_preset("publicIP")
The above "mostly" works. By that I mean, the INVITE transaction is properly
passed between internal UAS and carrier SBC and the call is setup. However, further
transactions (BYE/re-INVITE) etc do not work properly. So, far-end hangups are not
working etc.
I've searched various archives of this and other SER lists looking to see if anyone
was able to get this scenario working, but couldn't find a definitive answer. Most of
them point to using "advertised_address".
So, and ideas on how to make "Proxy behind NAT" work without using
advertised_address? Am I wasting my time?
Thanks in advance for any help you can offer.
SV.
4 Sep
4 Sep
3:12 a.m.
On 09/03/2011 05:53 PM, Sarat C. Vemuri wrote:
3.Using request_route_preset(“publicIP”)
The above “mostly” works. By that I mean, the INVITE transaction is
properly passed between internal UAS and carrier SBC and the call is
setup. However, further transactions (BYE/re-INVITE) etc do not work
properly. So, far-end hangups are not working etc.
So in other words, there is no interface to which Kamailio could be
bound on a network that both the UAC and the UAS have direct network
and transport-layer reachability to?
If I understand correctly, it sounds like the fundamental problem here
is that the Record-Route URI introduced by the proxy in handling the
initial INVITE request has to be conserved in all subsequent requests
and replies. It is a requirement to use the same route set in
sequential (in-dialog) requests such as reinvites or BYEs. It is also
mandatory for the UAS to copy the received Record-Route into the final
reply (i.e. 200 OK).
The problem is that you then have to choose the network address in the
Record-Route. If either the UAC or the UAS cannot directly reach it,
your problem arises.
Is this an accurate statement of the problem? I wanted to verify
before continuing.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
3:44 a.m.
It is feasable to what you want: kamailio behind NAT proxying traffic
from/to public internet to/from private network.
You will need to properly craft the INVITE and use proper record route headers.
Use set_advertised_address when needed:
http://kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_advertised_ad…
Also, use record_route_preset (note that there are two parameters):
http://kamailio.org/docs/modules/devel/modules_k/rr.html#id2547566
That should do it. You don't need any patches for rtpproxy.
Just use force_rtpp_proxy (and force the IP address):
http://kamailio.org/docs/modules/devel/modules/rtpproxy.html#id2546034
Note: Make sure that you understand how in-dialog requests are routed
by a proxy in order to know how to properly handle the initial INVITE.
Regards,
Ovidiu Sas
On Sat, Sep 3, 2011 at 2:53 PM, Sarat C. Vemuri <sarat.vemuri(a)fthco.com> wrote:
We are trying to configure Kamailio (3.1.x) as a
“boarder proxy” where it
acts as the front for various carrier gateways so that internal UACs and
UASs are unaware of the carrier gateways.
Let me try to present a clear picture of our setup.
1. Kamailio has several NICs (physical or vlan). Each on a different
subnet. One subnet is internal/has routes for internal. Other subnets are
private connections to carriers or a route to public Internet.
2. All of these subnets are non-routable from Internet. In addition ,
the carrier private connections are not routable internally.
3. Connection to public internet is via a FW/NAT (one-to-one NAT),
which maps to one of the interfaces.
4. All internal UAC/UAS connect on the internal subnet.
5. We are using RTPProxy (at least one instance per carrier) to relay
media between internal and carrier subnets
We are able to make this setup up work great except for one scenario. One
of the carriers is only reachable via public Internet. Due to security
requirements, our Kamailio cannot have a public IP address and must use
FW/NAT. I guess this scenario is “Proxy behind NAT” and not really
encouraged. But I would like to see if there is a way to make this work. We
cannot use the “advertised_address” since it changes the IP for every
“route”.
We were able to get this mostly working by doing the following
1. mhomed=1
2. Small patch in the rtpproxy module so that force_rtp_proxy
actually uses the IP address passed (public IP).
3. Using request_route_preset(“publicIP”)
The above “mostly” works. By that I mean, the INVITE transaction is
properly passed between internal UAS and carrier SBC and the call is setup.
However, further transactions (BYE/re-INVITE) etc do not work properly. So,
far-end hangups are not working etc.
I’ve searched various archives of this and other SER lists looking to see if
anyone was able to get this scenario working, but couldn’t find a definitive
answer. Most of them point to using “advertised_address”.
So, and ideas on how to make “Proxy behind NAT” work without using
advertised_address? Am I wasting my time?
Thanks in advance for any help you can offer.
SV.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4815
days inactive
4815
days old
2 comments
3 participants
participants (3)
-
Alex Balashov -
Ovidiu Sas -
Sarat C. Vemuri