Hi,
while testing IPv6 with customers, we fell over quite a few cases, where customers aren't reachable on inbound calls most of the time. And digging into this, we found the home router firewall as the cause for those problems.
Normally, you would think, all the NAT problems cease when switching to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration, and Kamailio would send NAT pings (those 4 bytes of UDP junk) every few seconds to keep the firewall in the NAT router open. And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router in front of SIP devices, with a firewall. And this firewall will allow outbound traffic. But after a few seconds it won't allow incoming connections anymore. And the routers I have seen so far don't have a configurable firewall where you could allow inbound traffic from our server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4 only. And the loadbalancer doesn't know anything about registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
Best Regards, Sebastian
Hi,
On Fri, Feb 27, 2015 at 9:07 AM, Juha Heinanen jh@tutpro.com wrote:
Sebastian Damm writes:
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
use tcp.
Okay, should have added: UDP, please.
Best Regards, Sebastian
On Fri, Feb 27, 2015 at 9:35 AM, Juha Heinanen jh@tutpro.com wrote:
how is it possible that a new sip phone that implements ipv6 does not implement tcp and ssl? or is it so that you don't want to use tcp?
Actually, it's the latter. Our current high availability setup reilies on anycast. And with TCP, this would mean a huge change in our setup.
Best Regards, Sebastian
On 27 Feb 2015, at 09:53, Sebastian Damm damm@sipgate.de wrote:
Actually, it's the latter. Our current high availability setup reilies on anycast. And with TCP, this would mean a huge change in our setup.
That is in fact an interesting topic. Can you please elaborate a bit more on this as I would like to see what we can do in the software to make things easier.
I had a similar discussion a while ago and it seems like failover handling is easier in UDP and we will need to fix this in order to be able to migrate more users to TLS.
I haven't tested how different clients behave in regards of TCP if the server close a connection.
/O
On Fri, Feb 27, 2015 at 9:59 AM, Olle E. Johansson oej@edvina.net wrote:
Actually, it's the latter. Our current high availability setup reilies on anycast. And with TCP, this would mean a huge change in our setup.
That is in fact an interesting topic. Can you please elaborate a bit more on this as I would like to see what we can do in the software to make things easier.
I guess I can. Maybe the presentation of Krischan from last year's Kamailio world will explain a lot: http://www.kamailio.org/events/2014-KamailioWorld/day2/17-Krischan.Udelhoven...
The setup on slide 9 is basically how our setup still looks like. We have a few loadbalancers in different data centers sharing the same IP. And depending on where the customer hits our network and how the call gets routed, the loadbalancer handling the request and the one handling the reply don't have to be the same. That's why UDP is so comfortable to work with. We don't have a state, we don't care about the number of open TCP sessions on one machine, and if one machine goes offline, OSPF makes sure, the IP is still available.
When using TCP, we would have to make sure, every request leaves our network on the same machine where it came in, because that's the machine where the TCP session is open. That would mean to have a distinct OSPF weight for each IP, so all packets always get routed to the same machine. And that would mean, we probably would have to do a DNS round robin thing to loadbalance the incoming traffic, since we wouldn't want to have all traffic coming in on only one machine.
I had a similar discussion a while ago and it seems like failover handling is easier in UDP and we will need to fix this in order to be able to migrate more users to TLS.
Yes, it for sure is a failover thing. We have a TCP and TLS server, too, but this is not HA and only for test purposes right now. We probably would use something with DNS RR, but aren't sure about how many clients we could handle on one TCP or TLS machine. In our tests, we had about 16k sessions open at the same time, but that would mean a lot of machines for all our customers.
I haven't tested how different clients behave in regards of TCP if the server close a connection.
From what I saw with snom phones connected to the TLS machine, when we
restart the Kamailio process, the clients aren't reachable for inbound calls until the next reregistration. They establish a new TCP connection for an outbound call, but this connection can't be used for inbound calls. After the next reregistration, everything is okay again.
Sebastian
Hello,
On 27/02/15 09:26, Sebastian Damm wrote:
Hi,
On Fri, Feb 27, 2015 at 9:07 AM, Juha Heinanen <jh@tutpro.com mailto:jh@tutpro.com> wrote:
Sebastian Damm writes: > Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks > in advance. use tcp.Okay, should have added: UDP, please.
I would use an extra branch flag here.
Keepalives are sent based on nat_bflag and sipping_bflag. You can set both no matter it is actually a register from a natted phone or not.
The extra flag will be set to mark it is an IPv6 device.
When doing NAT handling inside the config file, if IPv6 branch flag is set, you should not engage rtp relaying (unless it is gatewaying to IPv4) or do other nat specific fixing to headers for the callee.
Cheers, Daniel
On Fri, Feb 27, 2015 at 3:11 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
I would use an extra branch flag here.
Keepalives are sent based on nat_bflag and sipping_bflag. You can set both no matter it is actually a register from a natted phone or not.
That's the solution we tried to implement this afternoon. We saved an additional location entry on the loadbalancer (just as a proof of concept) and then set the NAT flag configured for the nathelper module. Via kamcmd I can see that the location entry is there. But I don't see any keepalives being sent out. I even set the ping_nated_only parameter to 0 so that all clients would get pings. On the proxy I can see them (for IPv4 cllients). Is there anything special? This is what I did:
modparam("registrar", "max_contacts", 50) modparam("registrar", "received_avp", "$(avp(i:801))") modparam("registrar", "default_expires", 600) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 600) modparam("registrar", "gruu_enabled", 0)
modparam("usrloc", "db_mode", 0) modparam("usrloc", "nat_bflag", 4) modparam("usrloc", "use_domain", 1) modparam("usrloc", "hash_size", 14) modparam("usrloc", "timer_interval", 180) modparam("usrloc", "timer_procs", 4)
modparam("nathelper", "received_avp", "$(avp(i:801))") modparam("nathelper", "natping_interval" , 14) modparam("nathelper", "ping_nated_only" , 0) modparam("nathelper", "sipping_bflag", 20) modparam("nathelper", "sipping_from", "natping@sipgate.de")
And then in the onreply_route I added the following:
if (is_method("REGISTER") && $rs == 200) { setbflag(4); save("location"); }
(Again, this is just a proof of concept.)
Now I would expect to see NAT pings every 14 seconds to each registered client. But I don't see any.
Does the NAT pinging work only for IPv4 maybe?
Best Regards, Sebastian
On 27 Feb 2015, at 09:07, Juha Heinanen jh@tutpro.com wrote:
Sebastian Damm writes:
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
use tcp.
What is the problem? There is no need for any keep-alived in IPv6.
/O
On 27 Feb 2015, at 09:04, Sebastian Damm damm@sipgate.de wrote:
Hi,
while testing IPv6 with customers, we fell over quite a few cases, where customers aren't reachable on inbound calls most of the time. And digging into this, we found the home router firewall as the cause for those problems.
Normally, you would think, all the NAT problems cease when switching to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration, and Kamailio would send NAT pings (those 4 bytes of UDP junk) every few seconds to keep the firewall in the NAT router open. And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router in front of SIP devices, with a firewall. And this firewall will allow outbound traffic. But after a few seconds it won't allow incoming connections anymore. And the routers I have seen so far don't have a configurable firewall where you could allow inbound traffic from our server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4 only. And the loadbalancer doesn't know anything about registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
AARGH. Now I see. Thank you. (Disregard earlier e-mail).
In all modern standards, like SIP Outbound, the need to send keep-alives has been pushed to the client. They need to open a network flow and keep it open - UDP or TCP or TCP/TLS.
As we can't trust device developers to stay up to date, we may need IPv6 keepalives.
/O
Hi Sebastian,
maybe it could be a solution to lower the registration interval for ipv6 users to ~30 seconds. This would keep the NAT pinhole open. Of course this will cause high traffic + registrar load. To reduce this, you could only require a authentication every ~20 minutes. For the registers in between you could simply send a OK.
regards, moritz
On 02/27/2015 09:04 AM, Sebastian Damm wrote:
Hi,
while testing IPv6 with customers, we fell over quite a few cases, where customers aren't reachable on inbound calls most of the time. And digging into this, we found the home router firewall as the cause for those problems.
Normally, you would think, all the NAT problems cease when switching to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration, and Kamailio would send NAT pings (those 4 bytes of UDP junk) every few seconds to keep the firewall in the NAT router open. And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router in front of SIP devices, with a firewall. And this firewall will allow outbound traffic. But after a few seconds it won't allow incoming connections anymore. And the routers I have seen so far don't have a configurable firewall where you could allow inbound traffic from our server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4 only. And the loadbalancer doesn't know anything about registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
Best Regards, Sebastian
s/NAT pinhole open/connection alive/g
On 02/27/2015 02:41 PM, Moritz Graf wrote:
Hi Sebastian,
maybe it could be a solution to lower the registration interval for ipv6 users to ~30 seconds. This would keep the NAT pinhole open. Of course this will cause high traffic + registrar load. To reduce this, you could only require a authentication every ~20 minutes. For the registers in between you could simply send a OK.
regards, moritz
On 02/27/2015 09:04 AM, Sebastian Damm wrote:
Hi,
while testing IPv6 with customers, we fell over quite a few cases, where customers aren't reachable on inbound calls most of the time. And digging into this, we found the home router firewall as the cause for those problems.
Normally, you would think, all the NAT problems cease when switching to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration, and Kamailio would send NAT pings (those 4 bytes of UDP junk) every few seconds to keep the firewall in the NAT router open. And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router in front of SIP devices, with a firewall. And this firewall will allow outbound traffic. But after a few seconds it won't allow incoming connections anymore. And the routers I have seen so far don't have a configurable firewall where you could allow inbound traffic from our server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4 only. And the loadbalancer doesn't know anything about registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
Best Regards, Sebastian
-
Daniel-Constantin Mierla -
Juha Heinanen -
Moritz Graf -
Olle E. Johansson -
Sebastian Damm