• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1144
  • Last Modified:

Port Forwarding check

Hello Everyone.

My question is related to router port forwarding.

If I have a router that is "supposed" to be port forwarding certain TCP/UDP ports 6000,6100,9000,9001,30000-30031 forwarded from the WAN side to a fixed internal LAN Ip address, how can I  check that those ports are being forwarded properly?
The destination is a VoIP phone system and is not a PC.

I had an Idea that I could set up a Telnet server on a PC and put it on the destination address temporarily in place of the Voip System & set it to accept connections on the above ports.
Then go off site and manually telnet into the server on those ports, one at a time.
If I can do this, the ports must be forwarded correctly?
Maybe even do a file transfer to see if it works reliably?

Is there an easier way to do this?
Is there a program/tool that can do this type of testing?
1 Solution
Davis McCarnOwnerCommented:
If the VOIP system answers phone calls and you can use it to place calls, the port forwarding is working. Have you tried that?
CruickyAuthor Commented:
The phones work sometimes and not others. The conversation is one way only.
This is why i need to KNOW the ports are forwaded.

Thanks for the suggestion but it wasnt helpful on this occation

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Kamran ArshadCommented:

For one-way-communication, please check the below link;


For testing Port-Forwarding;

CruickyAuthor Commented:
Thank you for the "VoipUser.org" Port forward test tool. I have found that tool too but it requires the voipUser server side application to function and that appears to be always down. Unless its a Vista compatibility issue that I am not aware of. (of which there are many)

Had a look at the "voip-info.org" suggestions and while the testing various link segments is indeed a good process of elimination, it is hard to do this when its the internet infrastructure that resides between the 2 sites. Not many ISP's are willing to let you set up a packet sniffer (wireshark) inside their point of prescence building.
Sometimes it is the ISP that is the cause of lost or even blocked voip packets. For example, Telstra released an early siemens router for extensive use on their ADSL network but apparently had the firmware modified to block common voip port traffic. The block was invisible in the router config pages. One could only assume they were trying to prevent prople eroding their profit PSTN telephone call base.
All the port forwarding in that router didnt help. I ended up replacing the router and had a clear voip service working within minutes.

Thanks for your reply. It is appreciated.
CruickyAuthor Commented:
Thankyou Kechka for the port scanner suggestion.

However a port scanner is of limited use in some cases, including mine.
This is because a port scanner attempts communication on ports, up to 65535 of them.
There has to be a reply to know if anything is open.
A simple port scan may not send data that warrants a reply from the device at the other end, so the port appears closed.
In my example, a complex call setup is initiated between the 2 Voip systems on port 6000 and 2 ports in the 30000-300031 range are mutually chosen during this process for TX and RX voice paths. Only then do voice packets start to flow on these 30000 series ports.
So, inteligent 2 way coommunication is required to solicite a response on port 6000.
And sending port sniffs on ports 30000-300031 will also be ignored as there has been no call setup negotiation and certainly no valid "voice" packets in a port sniff.
Basically everything is quiet on all ports until someone says the magic words.

The only way to test properly is to have a specific "sending"  tool at one end, & a matching "listening" tool at the destination.

Luckily Ive managed to locate such a tool.
It is simple and cannot test a range of ports, only 1 at a time, but it will do the job.
see http://www.simplecomtools.com/
Their free UDP (and TCP)  test tools have a built in transmit ans recieve component.
You can set the destination IP and port, and listen at the other end on the same port for the resultant test text to appear.

I wish PingPlotter would build this functionality into their test tool, and Peter at Nessoft may be doing that after my recommendations as Im sure he would do a brillant job.
In the mean time visit the site above for the free tool, if you need something like this.

Andrew C

Featured Post

Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now