UDP Reachability Testing

From Granizada

I have Asterisk IAX servers behind firewalls that need to peer with other IAX servers on the Internet. It would be helpful to have a quick ping command that tells me whether the service is reachable and at least responding in some manner. The firewall is configured to forward IAX packets directly to the Asterisk server.

Dan 01:16, 1 August 2007 (CST)

nmap Solution

I could use ordinary udp pings:

 # nmap -sU -p4569 firewall.example.net

But, because of the nature of UDP scanning (see 'man nmap'), this is unable to differentiate between a UDP port that has a process listening on it and a UDP port that is filtered, so it's useless. To illustrate, if I bracket the port I'm interested in (IAX, 4569) with two that I know are not listening:

 # nmap -sU -p4568-4570  firewall.example.net
 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )
 Interesting ports on 10.10.10.10:
 PORT     STATE         SERVICE
 4568/udp open|filtered unknown
 4569/udp open|filtered unknown      <--- no difference
 4570/udp open|filtered unknown

To fix this I add a payload to the UDP packets knowing from my testing that Asterisk will reply. A 700 byte payload does the trick:

 # nmap -sU --data-length 700 -p4568-4570  firewall.example.net
 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )
 Interesting ports on 10.10.10.10:
 PORT     STATE         SERVICE
 4568/udp open|filtered unknown
 4569/udp open          unknown       <--- this is what I want
 4570/udp open|filtered unknown

You'll notice Asterisk logs complaining about the invalid data.

An alternative pointed out by Gavin Sandie is the -sV flag, but in this case this is identical to --data-length because it is sending probes. For some reason Asterisk' IAX (or at least version 1.4.9 of Asterisk) is not in the nmap 4.11 database, so it just sends some data and then says it doesn't know what is at the other end. If nmap's database improves then -sV will be the best option because it should tell you something about what is the other end. And clearly, since the nmap database does have some entries, it is a more general solution. Thanks Gavin!

Caveats

There is a few seconds timeout for Asterisk to reset from the invalid data namp sent, so if you do several of these in quick succession you get false negatives. Asterisk's behaviour could well change, so I can't rely on this staying the same. And if I'm looking at some other service, it may or may not reply. Bind doesn't, for example.