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.
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
When I try
hping --icmp 188.8.131.52
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.
Works fine for me, your install must be broken
# /usr/sbin/hping3 --icmp 184.108.40.206
HPING 220.127.116.11 (eth0 18.104.22.168): icmp mode set, 28 headers + 0 data bytes
len=46 ip=22.214.171.124 ttl=240 DF id=40353 icmp_seq=0 rtt=16.9 ms
len=46 ip=126.96.36.199 ttl=240 DF id=40354 icmp_seq=1 rtt=16.9 ms
len=46 ip=188.8.131.52 ttl=240 DF id=40355 icmp_seq=2 rtt=16.9 ms
len=46 ip=184.108.40.206 ttl=240 DF id=40356 icmp_seq=3 rtt=16.6 ms
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.
When I used NMAP, the 5555 UDP port showed as 'open|filtered'. But when I used 'hping 220.127.116.11 --udp -p 5555', I didn't get any response. Why is it so ?
I will try out Netcat as well.
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.
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 ?
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.
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 :-
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.
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 18.104.22.168
reciever ip 22.214.171.124 udp port 12345
Sender is in a cmd window.
nc -u 126.96.36.199 12345
access-list 100 permit udp host 188.8.131.52 host 184.108.40.206 eq 12345
applied on the inbound of the interface connected to 220.127.116.11
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 18.104.22.168 computer in the cmd window of 22.214.171.124
(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 126.96.36.199 to 188.8.131.52 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.
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.
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
It just feels better to have control of both ends.