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

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(a)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 &lt;ccolumbu(a)hotmail.com&gt; 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 &lt;ccolumbu(a)hotmail.com&gt; 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 &lt;ccolumbu(a)hotmail.com&gt; 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(a)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(a)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 >>> >>> >>> > > >