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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel, It is more like I made a stupid request, sorry... Kamailio is everything, but simple! I did some readings and, after rereading your e-mail, it is more like that it is easier to get my routing needs done if I have a dual homed server with a public interface and a private interface. Anyway, please consider that I am a dummy on Kamailio and that I am using the kamailio.cfg template we get from the source code as a starting point. The first step on the routing logic is to do a sanity check via “route(REQINIT)”. Just after this sanity check, the next step is to verify if the UA is NATed via “route(NATDETECT)”. Now, when calling the real routing function “route(RELAY)”, all NAT decision has already been taken earlier and all problems fixed! Now, supposing that I flagged all internal users during the authentication “route(AUTH)” using the source IP ($si), how can I then use the flag to build the following logic: Any internal to any internal -> Treat as no NATed (this is natural as Kamailio will not “see” any NAT during the internal UAs registration process); Any external to any external, follows the standard NAT detection decision (this is also natural as Kamailio can “see” who is NATed or not); Any internal to external (or vice-versa), treat as NATed (this is the challenge!); Although a dummy still, I like learning and reading… So if you have any example, documentation that can send me the link, etc., please send me. Next time I bother you I will have a more “reasonable” question to post or better, I will have found the solution myself. Cheers! Moacir
Date: Mon, 15 Oct 2012 09:10:30 +0200 From: miconda@gmail.com To: sr-users@lists.sip-router.org CC: moacirferreira@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@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,
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.
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@gmail.com To: sr-users@lists.sip-router.org CC: moacirferreira@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@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
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@gmail.com To: sr-users@lists.sip-router.org CC: moacirferreira@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@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 -
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
-
Daniel-Constantin Mierla -
Moacir Ferreira