The Planet still being used / blocked UDP traffic

**Russell** · 05-17-2009 09:11 PM

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.

VOIPoJustin · 05-18-2009 11:57 AM

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.

**Russell** · 05-18-2009 07:36 PM

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.

**VOIPoBrandon** · 05-18-2009 04:27 PM

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

**Russell** · 05-18-2009 07:53 PM

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.

**NY Tel Guy** · 05-19-2009 09:49 AM

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?

**ferdowsi** · 05-19-2009 08:00 PM

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 ;-)

**VOIPoTim** · 05-19-2009 08:26 PM

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.

**Xponder1** · 05-20-2009 08:46 AM

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.

**fisamo** · 05-20-2009 12:52 PM

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...