It depends on your computer, really, and the firewall software running on it. The easiest way is to use a TCP server that's already running on your network and forward to that (although that exposes that service to the outside world, so be careful with that too).

Some computers will also respond with a connection denied (without any configuration or service running at all), which we also recognize as a valid response and will show the time for. If you're using PingPlotter Pro, you can even enable its web service, port-forward to that from your firewall, and then target that port on the remote end. This would give you access to the web interface for PingPlotter Pro from outside your network, though.

For best results, you can play around with some ports / computers inside your own network while you're in that network and see what you can target.

ICMP is really easiest because almost everything responds to it - but it's not very forward able. Honestly, I'd not spend a lot of time tracing from the outside in right now.

A bit of advice when your tech shows up. Focus on the root problem (network video freezing up, bad voice over ip, or whatever) - not necessarily the PingPlotter data. The PingPlotter data helps you narrow down the problem space, but many techs are not going to give your data a huge amount of credibility if you start with that. Start with the fact that you're seeing Netflix problems, and tell them when - and *then* move to the PingPlotter data that quantifies the problems you're having. If your tech starts to try to discredit your collected data (PingPlotter), you can then always push back to the Netflix (or whatever) problems that occurred at the same time. If you only focus on the PingPlotter data, without another problem surfacing at the same time, they can relatively easily push back and discount the validity of PingPlotter data. We talk about this "technique" a bit here: http://www.nessoft.com/kb/46.

As long as you start with the root problem (bad network video) you can always fall back to that position if your PingPlotter data is questioned - and once you've re-established that PingPlotter data is just quantifying the network data and showing you that in more detail, you can move back down to the network problems using PingPlotter.

This is why I don't think it's worth *too* much to trace from the outside to the inside - that's not a use case that your technician is likely to spend a lot of time solving. It's not a bad piece of data to have, but you're probably not going to get a lot of value from it in your specific scenario (other scenarios are quite different - and I wouldn't make the same statement generally to everyone).

- Pete