Hi, Is there any good tool to see where a port is being blocked along an ip path? e.g. if i am behind my firewall, and i try to connect to a remote server on the internet (which may also be behind a firewall), i want to know at what point its being blocked, e.g. on the firewall my side or the firewall the remote side.
Normally with a tool like ethereal on the client you would see the syn being sent but if its blocked by a firewall you wouldnt know where as you wouldnt get any reply? thanks
Perhaps tcptraceroute ?
lft (Level Four Traceroute) works for me.
-j
is there one for windows?
I assume that there must be. But I don't specifically know of anything.
Sorry I can't be more helpful.
-j
traceroute is a special implementation of PING, and PING does not access an arbitrary port. The general usage of PING and traceroute is to verify a routing path to a specific IP-ADDRESS, not a port on that host.
On the contrary, traceroute can be told to send it's UDP queries to a specific port. Thus it would be possible to see which host / firewall is blocking access. At least this is the case on Slackware Linux.
Grant. . . .
The original LBL version of traceroute written by Van Jacobson in 1987 uses UDP and defaults to ports 33434 + hop-count. In 1993, G. Malkin of Xylogics documented an _experimental_ IP version (RFC1393), that did not specify a port number, and used a somewhat different algorithm. I got rid of windoze in 1992 before microsoft invented the internet or the web or what-ever they claim to have done, so I don't know when they invented TRACERT.EXE. As microsoft follows standards (including their own) like tuna follow migrating caribou, this used the ICMP echo instead of UDP. Van Jacobson is quoted in a 1995 paper saying:
To: Craig Smith Subject: Re: Traceroute Date: Thu, 25 May 95 12:50:47 PDT From: Van Jacobson
The original ip spec (rfc791) said that you should never send an icmp error in reponse to an icmp packet. Several years later this was amended to "... in response to an icmp *error* packet" but, at the time that traceroute was written, most router vendors had implemented according to the original spec & wouldn't send an icmp time exceeded in response to an icmp echo or echo reply. I then tried using an unassigned ip protocol instead of udp but it turned out that crashed HPUX systems (remember this was ten years ago, IP was new & there were lots of flakey implementations). The only thing that worked & didn't appear to do damage was udp to a port range that wasn't (& still isn't) used very often.
ICMP was added to traceroute-1.4 _apparently_ in June 1997 (the Changelog is somewhat confusing).
There have been other implementations of traceroute - from Trumpet's TRUMPHOP.EXE to the version created by Olaf Kirch for Caldera Linux in
2000 (and now included in SuSE Linux) which lacks the UDP mode.There have also been several adaptations of the traceroute concept to TCP. Van Jacobson created 'pathchar', Michael Toren created 'tcptraceroute', Salvatore Sanfilippo created 'hping2' - and I'm sure there are lots of others as the concept is so simple.
Old guy
regardless, the application listening on said port must be willing to reply according to the ICMP protocol, which is highly unlikely.
just try it on ports 80 or 443 :)
1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated by RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)
The network stack should be listening to unused ports, and respond with a RST _unless_ your toy firewall is "stealthing" the system.
[compton ~]$ su -c /usr/sbin/tcpdump -ni eth0 17:35:15.260 arp who-has 192.0.2.96 tell 192.0.2.217 17:35:15.260 arp reply 192.0.2.96 is-at 0:c0:d1:57:1e:48 17:35:15.260 192.0.2.217.2347 > 192.0.2.96.80: S 3116127078:3116127078(0) win 512 17:35:15.260 192.0.2.96.80.80 > 192.0.2.217.2347: R 0:0(0) ack 3116127079 win 0 17:36:25.220 192.0.2.217.2348 > 192.0.2.96.443: S 116283062:116283062(0) win 512 17:36:25.220 192.0.2.96.443 > 192.0.2.217.2348: R 0:0(0) ack 116283063 win 0 ^C [compton ~]$There you go! In case you don't understand the tcpdump output, 192.0.2.217 tried to connect to ports 80 and 443 in turn on 192.0.2.96. That particular host isn't running any web services, and so sends a RST packet to the port that tried to start a three-way handshake. Normal as can be. By the way, did you notice the ARP request and reply? That's why "stealth" is a crock of crap.
Old guy
Actually it should respond with an ICMP::DESTINATION_UNREACHABLE::PORT_UNREACHABLE or not at all, but BSD Unix and some other commercial Unices got it all wrong, Windows copied it from BSD, Linux adjusted it to match BSD and Windows, and there we ended up with the RST.
ARP transists the entire internet? :-)
interesting. the prerequisite to the behavior is the absence of a service on the specified port; highly probable as cnt(clients) >> cnt(servers) :-)
thanks for the update.
Think about the hardware implementation. The CPU is doing all the work. It has to handle this network connection, the keyboard, the disk drives, the real time clock, while at the same time, it's pumping bits out to the display to make the pretty pictures, and so on. This is handled by a set of signals called hardware interrupts. The network card receives this packet - it has no idea what it is, only that it's addressed to the hardware address or a broadcast. So it pulls this chain to the CPU and demands service. The CPU may interrupt what it's doing (these things are prioritized), and grabs the packet from the NIC. Now, what to do with it? It is sent to a mini-program that figures out what the packet is for - is this a reply to something sent out earlier, or is it new? If it's new, is there some application (a server perhaps) that can handle this? If _not_ then create a reply that tells the remote system to FOAD, and hand it to the NIC to send out. NEXT!!!
If this _is_ a reply (identifiable by the combination of IP and port address and a sequence number), then hand the packet to the application that is using "that" port.
A "firewall" application stands between the NIC code and the other applications - in effect, telling the network process that it's the application that is currently using all the ports/protocols, so send everything to me (thus negating the need for the network process to send out a "nobody here" packet). Based on the firewall rules/configuration, it may them permit the packet to reach the real application, or it may emulate what the networking process would have done (rejecting the packet), or it might be configured to drop the packet into the bit bucket where it disappears forever. Outgoing packets from applications are sent to the firewall application for any desired filtering - and the packet may be sent on to the actual NIC code, rejected, or dropped on the floor. But this ONLY occurs when a firewall application is running.
Old guy
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.