In article ,
Armin Linder wrote:
>I do very frequently run into problems with customers running their
>internal WAN connections (company site-to-site links) through
>Router/Firewall appliances. Many of them do use a single appliance for
>Internet access and site/vpn connectivity through tunnels.

>Most of them do **claim** that they have configured the applicance to
>let all internal site-to-site traffic pass, and filter only Internet
>traffic, but I frequently find after hours of tracing packets that
>either through misconfiguration or bugs in the appliances firmware ports
>do unexpectedly get blocked.

>So my question is: is there a tool available that lets me check a WAN
>connection for blocked ports? I guess such a tool would be made of a
>sender (trying all available ports) and a receiver/echo program on a
>test machine on the far side of the connection, otherwise currently
>unused ports could not be tested,

If the equipment is properly configured to allow appropriate icmp back
inwards, then you can use something about like this:

Use nmap's -ttl option with a small ttl value -- for example,
just enough to get to the ISP. If you get back an
icmp unreachable packet, the firewall/router is blocking and
letting inside hosts know about the block. If you get back an
icmp time-exceeded then then packet made it outwards.
If you get back no response, either the firewall/router is blocking
and not letting hosts know about the block, or else incoming icmp
does not work. If you get no response to anything then it is
likely an incoming icmp issue, but if you do get back some responses,
you can make some further deductions about what is blocked where.