[SR-Users] Another NAT question

Daniel-Constantin Mierla miconda at gmail.com
Thu Nov 8 07:54:59 CET 2012


Hello,

On 11/4/12 10:52 PM, Moacir Ferreira wrote:
> Daniel,
>
> I am "reading" a lot... However, I can’t still get the “logic” to 
> overcome my problem using Kamailio routing logic. I was willing to 
> have a dual-homed Kamailo+RTPproxy on a single server, where one 
> interface goes to the Internet and another one goes to my private 
> network. However, the private network is using the RFC1918 address 
> space. Kamailio's NAT detection mechanism forces the RTPproxy between 
> two UAs if they are using RFC1918 address space even if the 2 UAs are 
> at the IP subnet that the Kamailio server is. So, if I have a 
> “private” network using RFC1918 addresses, made of several remote 
> sites, all the RTP traffic would have to go to the Kamailio/RTPproxy, 
> causing a large and undesirable traffic on the WAN links. By other 
> hand, should I don’t care about getting all my RTP LAN/WAN traffic 
> being sent to Kamailio because I am using RFC1918 address space, I 
> could not find an "workable example" of configuring a dual-homed 
> Kamailio+RTPProxy that properly sets the rtpproxy_manage flags to make 
> it work.

RTPProxy is engaged on demand, it does not do rtp relaying just because 
it finds a RFC1918 address. It is up to you when you want to call 
rtpproxy_manage() function. So if the call comes from and goes to a 
rfc1918 address, then don't execute rtpproxy_manage().

Cheers,
Daniel

>
> Looking at your IPv4/IPv6 example, we can see that it could be 
> possible to tag a SIP transaction and decide latter if it were to go 
> from external to internal, internal to internal or external to 
> external. The example is quite easy to understand because you can 
> separate IPv6 from IPv4 transactions. However, what about the private 
> address space?
>
> Any help would be really appreciated. If you can't help, what forum 
> can I post my questions and get some answers?
>
>
> Moacir
>
>
>
> > Date: Mon, 15 Oct 2012 09:10:30 +0200
> > From: miconda at gmail.com
> > To: sr-users at lists.sip-router.org
> > CC: moacirferreira at hotmail.com
> > Subject: Re: [SR-Users] Another NAT question
> >
> > Hello,
> >
> > you can detect that the call is coming from public/external interface
> > and goes to private/internal interface.
> >
> > There are couple of ways to do it, one is to set a branch flag when 
> they
> > register, saying it is from external or internal. Then based on src ip
> > ($si) or rcv io ($Ri) of the invite and the branch flag from location,
> > you decide to enforce the rtpproxy or not.
> >
> > Alternative is to look at the forced socket or destination ip after
> > lookup location and get the info from there about the message flow.
> >
> > Cheers,
> > Daniel
> >
> > On 10/13/12 11:43 PM, Moacir Ferreira wrote:
> > > Hi,
> > >
> > > I have a scenario where I got a firewall with 3 interfaces: 
> internal, DMZ and external. All the traffic from internal going to 
> external is NATed. However, the traffic between internal and DMZ is 
> NOT NATed. The external and DMZ are using public IP addresses. On the 
> DMZ I have a Kamailio server running with RTPProxy + NAT Helper.
> > >
> > > Everything works fine when public (from the internet) users (UAs) 
> are behind NAT as Kamailio will force the RTP to go via RTPProxy. 
> However, when the public user has a public IP, it will fail to 
> establish the RTP to a user who registered on Kamailio coming from the 
> internal firewall interface.
> > >
> > > The reason is that, as I don't do NAT between internal and DMZ 
> firewall interfaces, Kamailio will not RTPRroxy in between the UAs 
> because, from the way Kamailio detects NAT, they are not behind NAT. 
> So the public user UA tries to reach a private IP address. If the 
> "inside" user tries to call a public user (a user on the Internet with 
> a public IP), it works.
> > >
> > > Yes, I could do NAT in between the internal and DMZ firewall 
> interfaces. However, this would force all RTP traffic of my UAs at the 
> LAN go to Kamailio RTPProxy, an bad effect that I would like to avoid.
> > >
> > > So my question is: what would be the best approach to solve this 
> issue using Kamailio and RTPProxy in such scenario?
> > >
> > > Cheers!
> > > Moacir
> > > _______________________________________________
> > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
> list
> > > sr-users at lists.sip-router.org
> > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> > --
> > Daniel-Constantin Mierla - http://www.asipto.com
> > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> > Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - 
> http://asipto.com/u/kat
> > Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - 
> http://asipto.com/u/katu
> >

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121108/0bced917/attachment-0001.htm>


More information about the sr-users mailing list