Allowed VONAGE ports through firewall...

Posts: 6 · New Forum Member Joined: Jun 04, 2005 Posts: 6

Long story short... My Vonage stopped working for some calls not others.... Noticed that when I removed an access list that allowed,
as Vonage requests, UDP port ranges 5061 5062 10000 - 20000
tftp, dns, and ntp... that I could call out to the one long distance number that I need to use on a regular basis. Email support requests not responded to and phone tech support was not helpful as the tech had a limited bag of tools. Today I pulled the Motorola out of my network stuck it in a DMZ and then allowed all udp while logging...

When I dial the number I need to get too I see the below log output..
traffic from a Vonage IP accessing port 20324.. My math puts that outside of the range of ports Vonage says to allow. So, enquiring minds want know.... What is the port list ?

Jun 5 05:53:07.804: %SEC-6-IPACCESSLOGP: list OUTSIDE_ACL permitted udp 64.192.151.152(20324) - (my ip)

whois -h whois.arin.net 64.192.151.152
Williams Communications, Incorporated WCG-BLK-5 (NET-64-192-0-0-1)
64.192.0.0 - 64.193.255.255
Vonage HOLDING CORP WLCO-TWC02142426-VONAGE-NYC (NET-64-192-151-0-1)
64.192.151.0 - 64.192.151.255

# ARIN WHOIS database, last updated 2005-06-04 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.
nguy@pegasus(nguy)$

Posts: 49 · Full Forum Member Joined: Jan 28, 2005 Posts: 49

Why not simply allow all outbound ports and protocols for the IP of your TA?

What is your concern causing you to filter outbound traffic from your TA?

Posts: 6 · New Forum Member Joined: Jun 04, 2005 Posts: 6

Actually the name of the ACL is a misnomer... It is applied on inbound traffic. I am only filtering inbound traffic.

Posts: 21 · Vonage Forum Associate Joined: May 25, 2005 Posts: 21

interesting... I wonder if this could be the cause of my problem (http://www.vonage-forum.com/ftopic6161.html) where I can call some people but not others.

I scanned my firewall logs for the times Vonage shows I made calls but was unable to find anything. Of course with all the background noise on Comcast that's not really surprising.

I'll try logging all my udp traffic tonight and see if I notice out of range traffic as well.

Posts: 134 · Vonage Forum Senior Joined: Mar 23, 2005 Posts: 134

Is your router UPNP capable? It seems as though the TA is telling the Vonage server to connect to that port for some reason. Most routers automatically allow an incoming connection on any port as long as the TA makes the request. In your case it doesn't sound like your router will do that.

Posts: 6 · New Forum Member Joined: Jun 04, 2005 Posts: 6

Let me know. how it goes. At this stage I will leave the TA in the "DMZ" with all udp allowed which seems to be fine.

Posts: 6 · New Forum Member Joined: Jun 04, 2005 Posts: 6

It is a Cisco 1750. My understanding of UPnP when it comes to routers is that the device automatically configures a static nat entry.
(ip and port) for people who do not know how to do that. So it is not really like a "permit tcp established rule" where you allow requests back in that were initiated by a host using tcp.

So that being said I think you are probably right and that is fine but
it essentially punches holes I cannot find documentation from Vonage that says "allow udp ports 5060 5061, 53, 123, 69, 53 10000-20000 oh and any other ports that the TA
happens to feel like using". It would be a lot simpler to say... You need to allow all udp traffic inbound to the device and it needs to be in a DMZ or have a firewall that is not really that great of a firewall.

Posts: 21 · Vonage Forum Associate Joined: May 25, 2005 Posts: 21

just spent a bunch of time screwing around with my firewall/natd configuration and fixed the issue I was having. Here's what I found:

First, there seems to be a lot of port unreachable icmp msgs that I was denying. Allowing this alone didn't fix it, but there's probably something in the ata to respond to these by switching a port.

Second, on the calls that weren't working, apparently my nat was oblivious to all outbound udp traffic. No idea what caused this on some calls and not others - probably some sort of failure at call initialization. the firewall then logged denied packets on sip ports as destined for my external ip and not the nat'd internal ip.

So I solved it by redirecting all UDP traffic from the interweb to my ata in my natd.conf (redirect_proto). I then allowed all Voip ports (udp) to my external ip. In a 45min phone conversation I just had w/ my parents, ipfw recorded 54 packets matching this rule (allow udp from any to me dst-port 10000-20000 in via xl1 keep-state). quite strange....

i wish i had a clearer understanding of why it was failing, but i'll settle for it working :p

Posts: 6 · New Forum Member Joined: Jun 04, 2005 Posts: 6

Agreed, it would seem that the best way to get these things to work is to hang the on a public IP with all traffic allowed Smile

Posts: 5 · New Forum Member Joined: Mar 08, 2005 Posts: 5

nickguy wrote:

Agreed, it would seem that the best way to get these things to work is to hang the on a public IP with all traffic allowed Smile

Yep, that's the philosophy that my former company had... if they couldn't figure it out, put it out there in front of that pesky firewall. I suppose if you like the idea of your hardware being hackable by anyone who happens to keep up with the various firmware vulnerability lists, that's fine. I kindof like to make it at least slightly challenging for them.

Personally, I'd like to ask the programmers to whom I've graciously handed more than 10000 ports, why they need to use additional ports outside of what they already asked for?

Considering that my single PAP2 adapter can have at most 2 lines active at a time, I can't imagine why they would need so many ports, UDP or not.