I have an Asterisk VoIP server running on an openSUSE 12.3 box.
An Snom phone is registered to the Asterisk box and will be running along fine.
Then suddenly maybe an hour or two later the registration is lost and the phone cannot re-register. Phone log says “Network failure.”
Of 6 registrations this is the only one that fails.
If I stop the server firewall and restart it then the registration from the phone is fine again.
The communication is over UDP. I have noted that when I run a UDP test with Zenmap the process can take several (5+) minutes, where the TCP test is done in seconds.
I’m trying to put these symptoms together to make some sense. It’s very puzzling. Any suggestions for further tests?
Thanks for your interest.
Indeed 5060 is used as a default port, but I have been experimenting with alternate ports to avoid logs filling with braindead brute force attempts to log in when the default port is active.
Wireshark showed that the port was open, however the port in question was not being used by Asterisk.
netstat was helpful in revealing this issue.
I’m still not sure why I was able to initially register and later not able to re-register, but I’m getting closer.
Thanks for the link, looks good, will investigate.
You didn’t describe how you were running wireshark… You might be running it incorrectly or you could be mis-reading the results(eg are you sure you’re reading a complete handshake/response or simply that traffic is arriving?)
Wireshark can be used, but it’s probably overkill and the wrong tool for simply testing whether a port is open or not.
You’ll probably get more understandable results using something like Nessus if you want to test many ports or telnet if you want to probe just one port.
tsu2: Wireshark is good for seeing what kind of packets get exchanged when one box tries to access another, that’s all I used it for.
I don’t think that telnet can tell us anything about the state of a UDP port since it is limited to TCP.
Zenmap can be helpful with UDP but it seems to take a really long time to investigate UDP ports.
One of my critical errors was using “port=xxx” where Asterisk expects “bindport=xxxx”.
Thanks for the link to Nessus, I will check it out.
If you’re simply testing for whether the firewall is the issue or not, then you don’t need to read packets…
You only need to know when that port is probed whether the message returned is denied (a firewall is blocking) or no response or some kind of empty response (the firewall is not blocking but there is no service responding) or an active response.
That’s far more easy to understand(looking for one of the three types of responses) than analyzing packets. UDP or TCP is irrelevant when simply testing the firewall.
Analyzing packets is better used for analyzing a stream or “conversation” of packets.
