The Planet still being used / blocked UDP traffic

The following is from my router log. The IP addresses generating all the traffic seem to be coming from The Planet (174.132.131.131 and 74.52.58.50), Softlayer (67.228.251.106) and Slicehost (67.23.11.26). I'm puzzled - I thought VOIPo had moved away from the Planet. Also, I'm curious about all this traffic every few seconds - and it's getting blocked anyway. Do all providers generate this much traffic? Is this normal?




2009/05/16 21:05:55 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:05:56 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:06:00 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:06:13 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:06:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:06:23 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:06:28 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:06:40 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:06:40 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:06:41 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:06:45 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:06:59 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:07:08 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:08 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:25 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:07:25 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:07:27 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:30 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:07:41 : Blocked access attempt : UDP from 208.43.97.218:46154 to MY.IP.ADDR:16448
2009/05/16 21:07:44 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:07:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:07:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:08:10 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:10 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:12 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:08:15 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:29 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:38 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:08:38 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:08:43 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:08:55 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:55 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:08:57 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:09:00 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:09:14 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:09:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:09:23 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:09:28 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:09:40 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:09:40 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:09:42 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:09:45 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:09:59 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:10:08 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:08 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:25 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:10:25 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:10:27 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:30 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:10:44 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:10:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:10:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:11:10 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:10 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:12 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:11:15 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:29 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:38 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:11:38 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:11:43 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:11:55 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:55 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:11:57 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:12:00 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:12:14 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:12:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:12:23 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:12:28 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:12:40 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:12:40 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:12:42 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:12:45 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:12:59 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:13:08 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:08 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:25 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:13:25 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:13:27 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:30 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:13:44 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:13:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:13:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:14:10 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:10 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:12 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:14:15 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:29 : Blocked access attempt : TCP from 221.192.199.36:12200 to MY.IP.ADDR:9090
2009/05/16 21:14:29 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:38 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:14:38 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:14:43 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:14:55 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:55 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:14:57 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:15:00 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:15:15 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:15:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:15:23 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:15:28 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:15:40 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:15:40 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:15:43 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:15:45 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:00 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:08 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:08 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:25 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:25 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:28 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:30 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:45 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/16 21:16:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/16 21:16:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/16 21:17:10 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/16 21:17:10 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/16 21:17:13 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/16 21:17:15 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/16 21:17:30 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061

Internet time: Sat May 16 21:17:35 2009

You need to unblock that traffic.

Quote:

---

Originally Posted by Xponder1

You need to unblock that traffic.

---

I've had VOIP for several years and multiple providers with this router and never had to forward ports or put ATAs in the DMZ. Afaik, my service is working fine. Why is the VOIPo situation different (about unblocking that traffic)?

Russell,
Your STUN server was still set to zeus (74.52.58.50).
I have changed it so that it uses the same SIP server you're on.

With regards to the other IPs (primarily 67.228.251.106, 174.132.131.131 and 67.23.11.26) - I believe these may be NAT Keep Alive packets. I'll ask Brandon to confirm this when he is available.

Quote:

---

Originally Posted by Russell

I've had VOIP for several years and multiple providers with this router and never had to forward ports or put ATAs in the DMZ. Afaik, my service is working fine. Why is the VOIPo situation different (about unblocking that traffic)?

---

These connections are related to keepalive and failover systems.

While we're not using The Planet for any core equipment now, it is still used in failover situations. If the traffic is blocked and anything on your account is routed to them in a failover or load scenario, your calls could fail. We highly recommend not blocking any VOIPo traffic since it could cause service issues or failure. You should see a connection from each SIP server that your traffic could come from every 20 seconds.

In terms of the keep alives, it is a little more aggressive than some since we had the Grandstream issue and wanted to be sure that our system had nothing to do with their constant connection losses. So it may be tweaked some later, but currently it's working extremely well.

We've found that even slowing it some so there's only a connection every minute causes a bunch of routers out there to close their NAT bindings and stop allowing traffic to come through.

Sure, that shouldn't be the case, but many new routers on the market want to micromanage all traffic as they see fit.

If we start decreasing it, we would need to structure it so that it could be increased to this level on a per-user basis and determine the appropriate number for some hyper-sensitive routers. Alot of providers simply rely on the devices to initiate the keepalives. Given the Grandstream situation, we could not rely on the devices to do anything at all.

So this will likely be redesigned in the future, but is a pretty sensitive area since we've seen a small decrease in the rate of it cause a surge in support tickets almost instantly in the past since a lot of routers begin blocking traffic or not accepting any incoming connections from a server besides the one the user is registered to causing some calls to fail.

Forwarding ports just make sure all this traffic is simply redirected directly to the ATA. Again it may not be needed for some users, but those with new routers that like to filter anything and everything run into issues without forwarding ports. Ultimately at least 95% of service issues with audio, dead air, or calls not completing that come through our helpdesk are resolved with port forwarding. That's the main reason it's one of our first recommendations.

What happens is that if a connection comes in on an audio port, sometimes the router won't accept it if it doesn't know exactly what it is.

Sounds crazy, but if everyone used a 2 year old router, all of this would be a non-issue.

Quote:

---

Originally Posted by VOIPoDylan

Russell,
Your STUN server was still set to zeus (74.52.58.50).
I have changed it so that it uses the same SIP server you're on.

With regards to the other IPs (primarily 67.228.251.106, 174.132.131.131 and 67.23.11.26) - I believe these may be NAT Keep Alive packets. I'll ask Brandon to confirm this when he is available.

---

Thanks, Dylan. I checked my logs this morning ... I'm still seeing traffic from zeus (it probably doesn't matter what STUN server I use, but since you mentioned changing it).

2009/05/17 10:34:38 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/17 10:34:38 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/17 10:34:40 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/17 10:34:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/17 10:34:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/17 10:35:03 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/17 10:35:10 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/17 10:35:18 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/17 10:35:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060

Zeus is actually a SIP server which falls in with the others. STUN runs locally on each of them.

Quote:

---

Originally Posted by Russell

Thanks, Dylan. I checked my logs this morning ... I'm still seeing traffic from zeus (it probably doesn't matter what STUN server I use, but since you mentioned changing it).

2009/05/17 10:34:38 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/17 10:34:38 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/17 10:34:40 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/17 10:34:53 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/17 10:34:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5061
2009/05/17 10:35:03 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/17 10:35:10 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/17 10:35:18 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5061
2009/05/17 10:35:23 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060

---

Quote:

---

Originally Posted by VOIPoTim

These connections are related to keepalive and failover systems.

While we're not using The Planet for any core equipment now, it is still used in failover situations. If the traffic is blocked and anything on your account is routed to them in a failover or load scenario, your calls could fail. We highly recommend not blocking any VOIPo traffic since it could cause service issues or failure. You should see a connection from each SIP server that your traffic could come from every 20 seconds.

In terms of the keep alives, it is a little more aggressive than some since we had the Grandstream issue and wanted to be sure that our system had nothing to do with their constant connection losses. So it may be tweaked some later, but currently it's working extremely well.

We've found that even slowing it some so there's only a connection every minute causes a bunch of routers out there to close their NAT bindings and stop allowing traffic to come through.

Sure, that shouldn't be the case, but many new routers on the market want to micromanage all traffic as they see fit.

If we start decreasing it, we would need to structure it so that it could be increased to this level on a per-user basis and determine the appropriate number for some hyper-sensitive routers. Alot of providers simply rely on the devices to initiate the keepalives. Given the Grandstream situation, we could not rely on the devices to do anything at all.

So this will likely be redesigned in the future, but is a pretty sensitive area since we've seen a small decrease in the rate of it cause a surge in support tickets almost instantly in the past since a lot of routers begin blocking traffic or not accepting any incoming connections from a server besides the one the user is registered to causing some calls to fail.

Forwarding ports just make sure all this traffic is simply redirected directly to the ATA. Again it may not be needed for some users, but those with new routers that like to filter anything and everything run into issues without forwarding ports. Ultimately at least 95% of service issues with audio, dead air, or calls not completing that come through our helpdesk are resolved with port forwarding. That's the main reason it's one of our first recommendations.

What happens is that if a connection comes in on an audio port, sometimes the router won't accept it if it doesn't know exactly what it is.

Sounds crazy, but if everyone used a 2 year old router, all of this would be a non-issue.

---

I appreciate your response, Tim. Quite honestly, I feel for you guys having to provide a service where just one of the variables (the router) can behave so differently!

1) From a consumer perspective, I was quite surprised by the blast of packets from 4 different IP addresses every few seconds. Since I'd never examined the traffic with any of my previous providers I can't comment on whether this is typical or not. I'm curious as to exactly what this adds to bandwidth consumption? I realize each "probe" by itself is probably small, but cannot help but wonder what it adds up to cumulatively. Whether I port forward or not, I'm still going to have this traffic.

2) Port forwarding: as I mentioned, I like the ability to have multiple ATA's behind my router. If I port forward, wouldn't this kill the ability of my other ATA's to handle calls? In a case like this will DMZing be a better option? Or, ideally, would a device that acted like a router and ATA (like the 2102?) be the solution? Were the Grandstream's (that I keep hearing mentioned) similar devices (ATA + router)?

Quote:

---

Originally Posted by Russell

I appreciate your response, Tim. Quite honestly, I feel for you guys having to provide a service where just one of the variables (the router) can behave so differently!

1) From a consumer perspective, I was quite surprised by the blast of packets from 4 different IP addresses every few seconds. Since I'd never examined the traffic with any of my previous providers I can't comment on whether this is typical or not. I'm curious as to exactly what this adds to bandwidth consumption? I realize each "probe" by itself is probably small, but cannot help but wonder what it adds up to cumulatively. Whether I port forward or not, I'm still going to have this traffic.

2) Port forwarding: as I mentioned, I like the ability to have multiple ATA's behind my router. If I port forward, wouldn't this kill the ability of my other ATA's to handle calls? In a case like this will DMZing be a better option? Or, ideally, would a device that acted like a router and ATA (like the 2102?) be the solution? Were the Grandstream's (that I keep hearing mentioned) similar devices (ATA + router)?

---

It's not that much traffic. It just looks like it.

Russell,

Since Voipo does not use SRV records anymore, I don't think the ATA is initiating the traffic to these SIP servers. I wonder why the other SIP servers are sending packets to your router unless they think that you are registered with that server.

You might want to shutdown your router and ATA (and probably your softphone too) for 5-10 minutes until the connections clear in the "Devices" page and then see if you are getting the packets from all the SIP servers.

Quote:

---

Originally Posted by Russell

I appreciate your response, Tim. Quite honestly, I feel for you guys having to provide a service where just one of the variables (the router) can behave so differently!

1) From a consumer perspective, I was quite surprised by the blast of packets from 4 different IP addresses every few seconds. Since I'd never examined the traffic with any of my previous providers I can't comment on whether this is typical or not. I'm curious as to exactly what this adds to bandwidth consumption? I realize each "probe" by itself is probably small, but cannot help but wonder what it adds up to cumulatively. Whether I port forward or not, I'm still going to have this traffic.

2) Port forwarding: as I mentioned, I like the ability to have multiple ATA's behind my router. If I port forward, wouldn't this kill the ability of my other ATA's to handle calls? In a case like this will DMZing be a better option? Or, ideally, would a device that acted like a router and ATA (like the 2102?) be the solution? Were the Grandstream's (that I keep hearing mentioned) similar devices (ATA + router)?

---

For the longest time I have 2 PAP2Ts behind my router--no DMZ--No Port Forwarding--not the first problem. My router, of course, provides PPPoE for my DSL--router firewall disabled.

Quote:

---

Originally Posted by sr98user

Russell,

Since Voipo does not use SRV records anymore, I don't think the ATA is initiating the traffic to these SIP servers. I wonder why the other SIP servers are sending packets to your router unless they think that you are registered with that server.

You might want to shutdown your router and ATA (and probably your softphone too) for 5-10 minutes until the connections clear in the "Devices" page and then see if you are getting the packets from all the SIP servers.

---

I thought based on what Tim says it was for failover and keep-alive purposes for non-cooperative routers. This means (unless I'm special) we're all being sent these packets (no registered softphone running). Since my phone service appear to work and I'm rejecting the packets I suspect I wont be very "failover" tolerant and I must have a cooperative router. I'd be most interested in anything Brandon may have to say.

Quote:

---

Originally Posted by burris

For the longest time I have 2 PAP2Ts behind my router--no DMZ--No Port Forwarding--not the first problem. My router, of course, provides PPPoE for my DSL--router firewall disabled.

---

Burris, I'm not sure I understand what you mean by "not the first problem". Do you mean that you don't have issue #1 in my message that you quoted? I believe PPPoE provides the credentials your DSL modem needs to let a device PC or router connect to it, so I'm not sure it's germane. My gut feeling is if you disable your router's firewall you're opening yourself up to being hacked - I believe, besides allowing multiple devices access the internet, providing that firewall is another advantage of using the router - I'm no expert. Others more knowledgeable may have a comment you disabling your router firewall.

Anyway, based on Tim's response it appears it's normal for us to be sent those messages (also, see my other response).

Quote:

---

Originally Posted by Russell

Burris, I'm not sure I understand what you mean by "not the first problem". Do you mean that you don't have issue #1 in my message that you quoted? I believe PPPoE provides the credentials your DSL modem needs to let a device PC or router connect to it, so I'm not sure it's germane. My gut feeling is if you disable your router's firewall you're opening yourself up to being hacked - I believe, besides allowing multiple devices access the internet, providing that firewall is another advantage of using the router - I'm no expert. Others more knowledgeable may have a comment you disabling your router firewall.

Anyway, based on Tim's response it appears it's normal for us to be sent those messages (also, see my other response).

---

I believe that the router firewall causes problems. My third party firewall along with the NAT I believe takes good care of me. At the same time, my anti-virus scans real time.
I think that port forwarding and DMZ and keeping the ATA in front of the router is far more risky for intrusion.

Mind you, I'm no expert,but from my reading and real time experiences, I feel comfortable that my set up is ok and most important, it works.

Quote:

---

Originally Posted by burris

I believe that the router firewall causes problems. My third party firewall along with the NAT I believe takes good care of me. At the same time, my anti-virus scans real time.
I think that port forwarding and DMZ and keeping the ATA in front of the router is far more risky for intrusion.

Mind you, I'm no expert,but from my reading and real time experiences, I feel comfortable that my set up is ok and most important, it works.

---

DD-WRT is the only way to go

Quote:

---

Originally Posted by Xponder1

DD-WRT is the only way to go

---

Naw- pfSense :D;)

Quote:

---

Originally Posted by burris

I believe that the router firewall causes problems. My third party firewall along with the NAT I believe takes good care of me. At the same time, my anti-virus scans real time.
I think that port forwarding and DMZ and keeping the ATA in front of the router is far more risky for intrusion.

Mind you, I'm no expert,but from my reading and real time experiences, I feel comfortable that my set up is ok and most important, it works.

---

I think we're on the same page here. I think of the NAT function as providing the firewall since by its nature devices on the private side are hidden from the public Internet by the router and (at a naive level) only responses to solicited requests are allowed through the NAT device back to the requester.

I do agree that the measures you have in place are very reasonable. I have similar measures in place with one exception. I've put another router between my first router and my main computer.

I also agree with you about port forwarding, putting a device in the DMZ and keeping the ATA in front of the router as all those are equivalent to exposing the device on the Internet.

Quote:

---

Originally Posted by Russell

I thought based on what Tim says it was for failover and keep-alive purposes for non-cooperative routers. This means (unless I'm special) we're all being sent these packets (no registered softphone running). Since my phone service appear to work and I'm rejecting the packets I suspect I wont be very "failover" tolerant and I must have a cooperative router. I'd be most interested in anything Brandon may have to say.

---

I think Tim was talking about the keep alive packets being sent often. Of course, he can correct me if I am wrong.

But I don't think multiple SIP servers trying to talk to your adapter at the same time is normal. I don't see that kind of a behavior on my setup.

Quote:

---

Originally Posted by sr98user

I think Tim was talking about the keep alive packets being sent often. Of course, he can correct me if I am wrong.

But I don't think multiple SIP servers trying to talk to your adapter at the same time is normal. I don't see that kind of a behavior on my setup.

---

I would tend to agree. Approx 10 requests a minute is 10 * 60 * 24 * 30 request a month. Wonder how many bytes each request is. Anyone know? It'll be interesting to hear Brandon's take on this.

The keep alive requests are very small, ~1.5 bytes/request.

At 10 requests a minute, you're looking at:

1.5 bytes * 10 * 60 minutes * 24 hours = 21600 bytes (21.094 kilobytes) sent in a day, or approximately .61 megabytes per month.

Quote:

---

Originally Posted by Russell

I would tend to agree. Approx 10 requests a minute is 10 * 60 * 24 * 30 request a month. Wonder how many bytes each request is. Anyone know? It'll be interesting to hear Brandon's take on this.

---

As Justin stated quite accurately, the requests are very small and not intensive nor intrusive, as the traffic is UDP which in itself is a very lightweight protocol, unfortunately these push requests that we send are required to keep the nat pinhole open between your network and ours, otherwise as soon as your router closes its connection, calls will "fail over".
________
O530 citaro

Quote:

---

Originally Posted by VOIPoJustin

The keep alive requests are very small, ~1.5 bytes/request.

At 10 requests a minute, you're looking at:

1.5 bytes * 10 * 60 minutes * 24 hours = 21600 bytes (21.094 kilobytes) sent in a day, or approximately .61 megabytes per month.

---

While the actually request is small, do remember it gets packetized at multiple layers due to the nature of the model. UDP is lightweight (as Brandon also points out) - UDP over IP4 is 20 bytes + the data (the ~1.5 bytes you mention). Then all this becomes data to the next lower level, etc. So the actual impact is at least an order or two of magnitude more.

Quote:

---

Originally Posted by VOIPoBrandon

As Justin stated quite accurately, the requests are very small and not intensive nor intrusive, as the traffic is UDP which in itself is a very lightweight protocol, unfortunately these push requests that we send are required to keep the nat pinhole open between your network and ours, otherwise as soon as your router closes its connection, calls will "fail over".

---

I did what sr98user suggested: shut down my ATA and restarted early this morning. I still am getting traffic from 4 distinct IP addresses - as you can see about 10 per minute. I just want to be sure that what I'm experiencing is normal behavior for a single VOIPo supplied ATA.

2009/05/18 21:05:07 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:12 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:12 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:13 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:35 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:56 : Blocked access attempt : UDP from 211.99.122.18:1070 to MY.IP.ADDR:1434
2009/05/18 21:05:57 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:57 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:58 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061

Brandon, I do hear what you're saying. Just that in my particular case, as you can see, the traffic is being blocked by my router and yet all appears to work fine - I presume the router is doing it's normal function and rejecting unsolicited traffic.

My expectation is similar to that mentioned by Burris - I'd like to place my ATA behind my router and not DMZ or forward ports. If that's a reasonable expectation then isn't your typical NAT router going to reject unsolicited traffic? I understand the need to keep the pin-hole open ... presumably the pin-hole will be open for the one IP address the ATA is pinging on a regular basis and I presume it's not pinging 4 different IP addresses.

Please understand I'm not trying to be argumentative. I'm, for the most part, happy with the service. Just curious about all this blocked traffic. I'm also curious if this is standard for other providers or something peculiar to VOIPo.

F Y I Using this tool:

http://robtex.com/dns

It shows:

174.132.131.131 = The Planet
74.52.58.50 = The Planet
67.228.251.106= Voipo.net
67.23.11.26 = Slicehost.net
211.99.122.18 = nomorefunn.moensted.dk ??

Perhaps these are not all Voipo initiated?

211.99.122.18 = nomorefunn.moensted.dk ??


Yo, this is my first post. Just signed up last night. I'm not too familiar with SIP, RTP, etc but I am looking for secure communications and this looks like a decent thread to go with.... I think ;-).

Weird how that sight resolve the 211 address to a host in Denmark. It appears to be a portion of a block from the Asia Pacific (APNIC):
> 211.99.122.18
Server: e.root-servers.net
Address: 192.203.230.10

211.in-addr.arpa nameserver = NS-SEC.RIPE.NET
211.in-addr.arpa nameserver = TINNIE.ARIN.NET
211.in-addr.arpa nameserver = DNS1.TELSTRA.NET
211.in-addr.arpa nameserver = NS4.APNIC.NET
211.in-addr.arpa nameserver = NS1.APNIC.NET
211.in-addr.arpa nameserver = NS3.APNIC.NET

whois query from apnic.net has it reserved by a hotel... LOL. Whatever, I just thought it's strange because I got nomorefunn.moensted.dk from that site also. Anyway, UDP port 1434 is likely an SQL port, not related to VOIPo.
Looks like there's been a little spike on that port on May 18th:
http://isc.sans.org/port.html?port=1434
half the sources from May 17th but an additional 3,500 destinations.

Comcast hangs their ATA out on the public internet. My dad's AT&T ATA was the same. He's been using it for 4+ years that way and doesn't run into any service or billing issues other than an ATA going south after an update was pushed up to it. But their service sux and so does the $. I've been trying out Lingo the past week. They had me place it behind the my edge device and asked for UDP ports 1024-1030, 5060-5065 and 10000-20000 to be forwarded.

I'm not sure why the SOHO devices use the term DMZ when placing a host completely on the public internet. I thought a DMZ generally is - modem > router > firewall > DMZ > router > firewall > LAN (maybe with IDS in there as well), placing DNS, SMTP, WWW, FTP, etc services in DMZ and forwarding the necessary ports - in the case of SIP, I'm assuming that's forwarding of ports to accomodate the application and fault tolerance (failover).
I'm not that rich or need the enterprise infrastructure, especially since some dude from India took my job.... LOL- but I have - an edge device > DMZ > router with SPI > LAN then open up whatever ports are requested from the vendor, application, etc. As a rule I shy away from opening UDP ports but did it for a VPN concentrator well before the jobs were farmed out of "Dodge" :-). Oh, if you have a VLAN capable switch, maybe you could place your VoIP gear on their own virtual segment? I didn't bother.

I was going to ask you about encryption but I think that's out of the scope of this thread.

Anyway, I'm really excited to come on board with VoIPo because this community looks like a bunch a tweakers and I could learn from you guys as well as tweak ;-)

Quote:

---

Originally Posted by NY Tel Guy

F Y I Using this tool:

http://robtex.com/dns

It shows:

174.132.131.131 = The Planet
74.52.58.50 = The Planet
67.228.251.106= Voipo.net
67.23.11.26 = Slicehost.net
211.99.122.18 = nomorefunn.moensted.dk ??

Perhaps these are not all Voipo initiated?

---

Of those, all are ours except the 211.99.122.18 Denmark one.

We use The Planet, Softlayer, and have monitoring/backups in Rackspace/Mosso which acquired Slicehost earlier in the year.

Quote:

---

Originally Posted by Russell

I did what sr98user suggested: shut down my ATA and restarted early this morning. I still am getting traffic from 4 distinct IP addresses - as you can see about 10 per minute. I just want to be sure that what I'm experiencing is normal behavior for a single VOIPo supplied ATA.

2009/05/18 21:05:07 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:12 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:12 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:13 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:13 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:35 : Blocked access attempt : UDP from 67.228.251.106:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:53 : Blocked access attempt : UDP from 67.23.11.26:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:56 : Blocked access attempt : UDP from 211.99.122.18:1070 to MY.IP.ADDR:1434
2009/05/18 21:05:57 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:57 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5060
2009/05/18 21:05:58 : Blocked access attempt : UDP from 74.52.58.50:5060 to MY.IP.ADDR:5061
2009/05/18 21:05:58 : Blocked access attempt : UDP from 174.132.131.131:5060 to MY.IP.ADDR:5061

Brandon, I do hear what you're saying. Just that in my particular case, as you can see, the traffic is being blocked by my router and yet all appears to work fine - I presume the router is doing it's normal function and rejecting unsolicited traffic.

My expectation is similar to that mentioned by Burris - I'd like to place my ATA behind my router and not DMZ or forward ports. If that's a reasonable expectation then isn't your typical NAT router going to reject unsolicited traffic? I understand the need to keep the pin-hole open ... presumably the pin-hole will be open for the one IP address the ATA is pinging on a regular basis and I presume it's not pinging 4 different IP addresses.

Please understand I'm not trying to be argumentative. I'm, for the most part, happy with the service. Just curious about all this blocked traffic. I'm also curious if this is standard for other providers or something peculiar to VOIPo.

---

The problem your having is your router (or its firmware anyway). If it is blocking any of your VOIP related traffic you need to forward ports. It's not like someone would benefit from hacking your ATA and nothing is behind the ATA to be affected anyway.

To answer your question the answer is NO its not normal but it is your router that is causing the issue not the ATA or the service itself. VOIPo can not help you with this issue. Just because your not noticing a problem at this time does not mean that your router blocking their traffic is not causing some kind of problem.

I have a Linksys WRT54GS V6 running DD-WRT and run a SYSLOG to monitor it and my router does not block any traffic to or from the ATA at all. If it did the first thing I would do would be to either forward the ports (or you can DMZ the ATA) regardless of if I noticed a issue. It just makes since.

Since Russell indicates that the service works just fine, I'm inclined to disagree--"If it ain't broke, don't fix it." Now, if the only time a problem would crop up is if failover tried to kick in and 'misbehaved' (or kicked in when it shouldn't have), you might want to change your router's configuration. Also, if you (Russell) experience problems in the future, you have a red flag waving at you when you start your troubleshooting...

Hey... sorry about the winded post. Obviously, I had too much time on my hands.

;)

Russell,

You could use wireshark to see what kind of data goes out of your of ATA. See if the ATA is trying to talk to all the SIP servers. Do the same test by disabling the firewall. And see if there is a difference. You will need a hub to look at the traffic on your PC.

Quote:

---

Originally Posted by Xponder1

The problem your having is your router (or its firmware anyway). If it is blocking any of your VOIP related traffic you need to forward ports. It's not like someone would benefit from hacking your ATA and nothing is behind the ATA to be affected anyway.

To answer your question the answer is NO its not normal but it is your router that is causing the issue not the ATA or the service itself. VOIPo can not help you with this issue. Just because your not noticing a problem at this time does not mean that your router blocking their traffic is not causing some kind of problem.

I have a Linksys WRT54GS V6 running DD-WRT and run a SYSLOG to monitor it and my router does not block any traffic to or from the ATA at all. If it did the first thing I would do would be to either forward the ports (or you can DMZ the ATA) regardless of if I noticed a issue. It just makes since.

---

As I've said. My service appears to be working well - can make and receive calls fine. I've heard on dslreports about folks getting spam calls - wont forwarding ports open me up to it?

No one from VOIPo has stated that the traffic I'm experiencing is not normal. As previously mentioned I've run multiple ATA's of different manufacturers behind this particular router with no issue. Have you examined the packets going through your router - do you see a similar set of servers sending packets to your router?

Quote:

---

Originally Posted by fisamo

Since Russell indicates that the service works just fine, I'm inclined to disagree--"If it ain't broke, don't fix it." Now, if the only time a problem would crop up is if failover tried to kick in and 'misbehaved' (or kicked in when it shouldn't have), you might want to change your router's configuration. Also, if you (Russell) experience problems in the future, you have a red flag waving at you when you start your troubleshooting...

---

Couldn't agree more. The first thing I'll do is DMZ it.

Quote:

---

Originally Posted by sr98user

Russell,

You could use wireshark to see what kind of data goes out of your of ATA. See if the ATA is trying to talk to all the SIP servers. Do the same test by disabling the firewall. And see if there is a difference. You will need a hub to look at the traffic on your PC.

---

A good suggestion, but not sure I have the technical expertise to get to the bottom of it (besides not having that hub). But once again the friendly folk at VOIPo don't seem to feel that this traffic is abnormal.