[SR-Users] Help with rewriting headers for NAT manually

Chad ccolumbu at hotmail.com
Sat Jan 15 18:14:50 CET 2022


It would be great if you are right and I am simply doing something else wrong in the config file!

Here is the 200 OK (note I have enable_double_rr enabled):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
Record-Route: <sip:209.###.###.###:5060;r2=on;lr=on;ftag=gK0e16642e>
Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=gK0e16642e>
Record-Route: <sip:18.###.###.###;lr;ftag=gK0e16642e;did=6dc.283659a3>
From: <sip:+1202#######@66.###.###.###:5060>;tag=gK0e16642e
To: <sip:+1845#######@sip-us-west-2a.numberaccess.net:5060>;tag=as488a6fb4
Call-ID: 202251204_54250714 at 206.###.###.###
CSeq: 710596 INVITE
Server: Asterisk PBX 16.18.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:1845#######@10.###.###.###:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 272

v=0
o=root 153822920 153822920 IN IP4 209.###.###.###
s=Asterisk PBX 16.18.0
c=IN IP4 209.###.###.###
t=0 0
m=audio 17198 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=nortpproxy:yes


--
^C


On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> You have a different problem then.
> Having private IPs in Contact is fine. You need to lose route the
> calls (kamailio will add two Record-Route headers) and the origination
> server will set the RURI to the private IP from Contact, but it will
> send the in-dialog requests to the public IP of kamailio. This has
> nothing to do with virtual IPs.
> Maybe you have a buggy client that doesn't do proper loose routing.
> 
> -ovidiu
> 
> On Sat, Jan 15, 2022 at 11:50 AM Chad <ccolumbu at hotmail.com> wrote:
>>
>> Ovidiu,
>> Thank you again for your response.
>> One is public (an internet IP) and one is private (a 10.x ip).
>> Apparently this is a known problem with virtual IPs, it does not work.
>> When the asterisk server responds to the invite it sends a contact header with the private IP and Kamailio does not
>> rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact header and tries to
>> send the traffic to the 10.x IP (which is non-routable) and the call dies.
>> I have been trying things for a long time to fix this (years) what you are saying will not fix it because of the virtual
>> IPs.
>> If it was a normal IP it would work fine. It has something to do with the routing table and how mhomed detects networks.
>>
>> --
>> ^C
>>
>>
>> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
>>> Hello Chad,
>>>
>>> The floating IPs that you have, are they both private IPs or one
>>> private IP and the other one a public IP?
>>>
>>> If you have to two floating private IPs, then you need a config like this:
>>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
>>> listen=FLOATING_UDP_PRIVATE2
>>>
>>> In the config, before relaying the initial INVITE you need to detect
>>> the direction of the call and set $fs accordingly:
>>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
>>>       $fs = udp:FLOATING_UDP_PRIVATE1
>>> }
>>> else {
>>>       $fs = udp:FLOATING_UDP_PRIVATE2
>>> }
>>>
>>> If you have a floating private IPs and a floating public IP, then you
>>> need a config like this:
>>> listen=FLOATING_UDP_PRIVATE
>>> listen=FLOATING_UDP_PUBLIC
>>>
>>> There should be no need to force the socket, but if you do, there's no
>>> harm (actually it's better and faster).
>>>
>>> Hope this clarifies things and helps,
>>> -ovidiu
>>>
>>> On Sat, Jan 15, 2022 at 9:48 AM Chad <ccolumbu at hotmail.com> wrote:
>>>>
>>>> Ovidiu,
>>>> Thank you for your response.
>>>>
>>>> I have done that, in addition to the linux ip_nonlocal_bind I have also set the Kamailio ip_free_bind=1 and it does not
>>>> work.
>>>> Here are my relevant config lines:
>>>> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
>>>> listen=LISTEN_UDP_PUBLIC
>>>>
>>>> mhomed=1
>>>> ip_free_bind=1
>>>>
>>>>
>>>> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been using it for a long time and have
>>>> rebooted as well):
>>>> net.ipv4.ip_nonlocal_bind=1
>>>> --
>>>> ^C
>>>>
>>>>
>>>> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
>>>>> Hello Chad,
>>>>>
>>>>> You can add a listen directive to your config for the virtual IPs
>>>>> (both public and private) and then you don't need to manually modify
>>>>> any headers or use force_send_socket().
>>>>> You need to enable non local IP binding so kamailio can start on the
>>>>> server that doesn't have the virtual IP:
>>>>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
>>>>> To make the change permanent, edit your sysctl.conf file and enable it there:
>>>>> net/ipv4/ip_nonlocal_bind = 1
>>>>>
>>>>> Regards
>>>>> Ovidiu Sas
>>>>>
>>>>>
>>>>> On Sat, Jan 15, 2022 at 4:16 AM Chad <ccolumbu at hotmail.com> wrote:
>>>>>>
>>>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup.
>>>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk
>>>>>> servers (via dispatcher).
>>>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived.
>>>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic.
>>>>>> We run linux Debian 10 for the OS.
>>>>>> Also we do not use a DB at all, everything is done with local config files.
>>>>>>
>>>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like:
>>>>>> Contact: <sip:##########@10.10.10.###]:5060>
>>>>>>
>>>>>> There are 2 possible solutions to this:
>>>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and
>>>>>> fix_nated_contact work as usual.
>>>>>>
>>>>>> 2. Create a manual header rewrite system.
>>>>>>
>>>>>> If solution #2:
>>>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back
>>>>>> rewrite it back to the internal server that the call is already connected to.
>>>>>>
>>>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant
>>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something).
>>>>>>
>>>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me.
>>>>>>
>>>>>> Thank you all for your time.
>>>>>>
>>>>>> --
>>>>>> ^C
>>>>>> Chad
>>>>>>
>>>>>> __________________________________________________________
>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>>      * sr-users at lists.kamailio.org
>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>>>>> Edit mailing list options or unsubscribe:
>>>>>>      * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>>
>>>>> __________________________________________________________
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>      * sr-users at lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>>      * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
> 
> 
> 



More information about the sr-users mailing list