UDP test tool

Unanswered Question
Feb 25th, 2009

I have opened a UDP port on the access-list and would like to test the connectivity.

Would you know of any reliable UDP test tool which I can install on a client (Windows/Linux etc) and initiate a UDP request (on specific port) to the server which runs UDP service.

Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
cisco_lite Wed, 02/25/2009 - 03:55

Thanks.

The documentation link on the site is invalid. Would you know of any hping documentation.

adamclarkuk_2 Wed, 02/25/2009 - 04:09

Hi

Just google for hping3, there is loads around

and example if generating traffic with hping3 with udp is below:-

hping3 --udp -p 10000 --destport 10000 192.168.1.1

This is sending udp packets from your ip port 1000 to 192.168.1.1 port 10000

cisco_lite Wed, 02/25/2009 - 08:51

hi,

When I try

hping --icmp 1.1.1.1

I see repetition of router_get() and 100% packet loss at the end. But plain ping works.

And on doing hping to myself, I can arp_get().

What do I need to do to make it work.

adamclarkuk_2 Wed, 02/25/2009 - 09:05

Works fine for me, your install must be broken

# /usr/sbin/hping3 --icmp 4.2.2.2

HPING 4.2.2.2 (eth0 4.2.2.2): icmp mode set, 28 headers + 0 data bytes

len=46 ip=4.2.2.2 ttl=240 DF id=40353 icmp_seq=0 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40354 icmp_seq=1 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40355 icmp_seq=2 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40356 icmp_seq=3 rtt=16.6 ms

hobbe Wed, 02/25/2009 - 13:16

When ever I need to do what you are doing I use Netcat.

There are versions for both windows and linux.

realy easy to use and realy nice to test access-lists with.

you can use it both to send and recieve.

cisco_lite Wed, 02/25/2009 - 15:10

When I used NMAP, the 5555 UDP port showed as 'open|filtered'. But when I used 'hping 1.1.1.1 --udp -p 5555', I didn't get any response. Why is it so ?

I will try out Netcat as well.

hobbe Wed, 02/25/2009 - 23:21

I would guess that since udp is connectionless and you got no response back that it was NOT open, it would be shown as open|filtered in NMAP.

which means that no packets were recieved telling you that it is NOT open.

Since you get no packet back that is what Hping also is telling you.

The best way to test firewalls/access-lists IMHO is to install a sniffer on the target mashine and then test the type of communication with netcat and a scanner. The scanner to se if anything gets through and netcat to test the connection goes to the intended target mashine and back.

cisco_lite Thu, 02/26/2009 - 05:35

I tried netcat and it showed as 'open'. This is opposed to hping (no response) and nmap (open|filtered).

adamclarkuk_2 Thu, 02/26/2009 - 05:37

hing3 is not a port scanner, it's in essence a packet generator which you can use to (among other things) test firewall rules which is what you asked for is it not ?

cisco_lite Thu, 02/26/2009 - 05:44

If the firewall has blocked udp port, then Netcat shouldn't have worked. Is that correct understanding.

adamclarkuk_2 Thu, 02/26/2009 - 05:58

Not sure about the netcat output but I would trust nmap more, here is an explanation of the open|filtered

Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port

This suggests that the communication failed.

If you want real proof and have access to the firewall you can do the following.

IOS

Add a log entry to your ACL line and see if the counter goes up and if you are logging to console do sh log and you should see a denied syslog message like the following :-

%SEC-6-IPACCESSLOGP: list denied ->

if it's an ASA/PIX/FWSM you can use a similar approach or use the capture command to see if it is making it through the firewall.

hobbe Thu, 02/26/2009 - 14:55

Yes that is correct if i understand your question right.

since I am not shure i do understand exactly what you are explaining. I will give an example instead. in a windows environment.

sender(transmitter) ip 1.1.1.1

- I

Access-list

- I

reciever ip 2.2.2.2 udp port 12345

Sender is in a cmd window.

nc -u 2.2.2.2 12345

access-list 100 permit udp host 1.1.1.1 host 2.2.2.2 eq 12345

applied on the inbound of the interface connected to 1.1.1.1

reciever is in a cmd window.

nc -u -e cmd.exe -L -p 12345

this would give the result that NC after 2 enters in the senders cmd window will show up a "dos" promt of the 2.2.2.2 computer in the cmd window of 1.1.1.1

(do a ipconfig to be shure)

If the access-list is wrong and fails then nc would not have a connection.

if the access-list is correct and works it would let the udp traffic from 1.1.1.1 to 2.2.2.2 port 12345 pass and since the return traffic is not inspected it will (providing routes are correct) work just fine.

If you have a more complicated access-list I would put a monitor on the recieving port of the switch that goes to the target. then start a sniff and start hammering away with the nmap portscanner.

why sniff ?

well you want to know if the packets get there, if you only check connections then you might miss that you can have one way traffic going through.

you might not be able to get a tcp connection but still get information to a listener on the other side.

good luck

cisco_lite Fri, 02/27/2009 - 02:59

Ok. Let me get it right. Is it necessary to initiate an nc command from the receiver end if there is already an application running on it on the relevant udp port.

In my case, I have just initiated nc from sender side and expect the application on receiving end to send back the packets.

hobbe Fri, 02/27/2009 - 07:36

Actually no you do not need a sender and a reciever, but it helps out to know what you would expect back.

some applications dont send a response.

and this is especialy true for UDP applications. syslog fx. simply because its just one way communication.

Since UDP is a connectionless protocol you dont have the status of the connection in the protocol to help you know if or if not you have buggered up somewhere.

Thats why I like to use a sender AND a reciever when testing rules. especially

UDP.

It just feels better to have control of both ends.

Actions

This Discussion