[arm-allstar] Debugging port forwarding

[Joel]

Dave Miller wrote:
> I am trying to get a simple test case working to hit the correct
> party squarely on the head.
>
> I have been try to use the various online port checkers to see if I
> am open. They all show closed. Even tried a different DSL router that
> allegedly was in bridge mode. Still same results.


When you sent a UDP packets (with a scanner or an application), the receiving host will....

a) If it has a listening daemon to that port - it will pass the packet onto the daemon (Asterisk in this case). If the daemon does not respond, from the receivers end - the packet will seem to go into oblivion because no response of any sort is received.

b) If the port is closed, the host TCP stack will return a icmp port unreachable packet to tell you that "no one here is listening to that port".

Problem with "b" is that many firewalls block the return ICMP packets thinking that increases security. Back in the Windows 98 days the TCP stack was so fragile that things like malformed ICMP packets could blue-screen the computer. So everyone started blocking them. A bad idea because it breaks networking in many ways... But the bottom line is, your port forwarding could be all correct and when you probe you will get "a" above but never know if the daemon is ignoring you for some reason, or a firewall is stopping the inbound UDP packet, or the return ICMP packet.

To diagnose this - you need to sniff packets! Most distro's have tcpdump installed - if not find the package and install it...
pacman -S tcpdump

Then on the receiver side (the one you can't connect to) do (change port number if needed!)...

tcpdump -n -nn udp and port 4569

Then from the other node (the one that is trying to connect but can't) issue a connect command... Watch on the receiver to see if any packets arrive from the far end.

If nothing is arriving - then you have a problem inbound. Ideally would be to sniff packets on your routers WAN address. I've seen plenty of routers with correctly set UDP forwarding rules that still do no forward the packets... I've helped Netgear and D-Link nail bugs in their firmware that did this in the past.

73's
Joel/N7GLV