Is there an easy way to get the internal IP of a chatty workstation?

Oh, there are so MANY ways to do this!  Let's cover a few easy ones:

1.  Connect to the firewall, through which the traffic is passing.  It should have all KINDS of interesting records in it, log files, audit activity.  If it were a Unix-based firewall running FreeBSD in a hardened kernel, you might use a statement like this to catch the traffic in real time:  "showaudit -kH 1.2.3.4", where 1.2.3.4 is the IP address of the external web site that's being hit by your internal user.  Or if you know the time stamp at which the traffic was happening, the statement would like like "showaudit -H 1.2.3.4. /file_path_of_the_record_containing_the_time_stamp_of_the_activity".

2.  Lots of places use proxy servers to audit & filter what's allowed & what's not--and to track who's trying to go to them.  You can contact the administrator of your proxy server and ask "Who's hitting the site at 1.2.3.4?"

3.  You could create a port mirror on the switch or router that's the last hop before the firewall, then send a copy of the traffic to a laptop that's listening with Wireshark.  Then filter for the web site 1.2.3.4 that's being hit.  You'll see the IP address(es) of the device(s) hitting it.

4.  You could start up your handy Orion Netflow Traffic Analyzer, assuming you've configured your switches and routers to forward traffic to it, and filter for the external IP address.  The cool thing about NTA is it can show you more intuitive data about the traffic, what protocols are involved, what applications are involved, as well as the source(s) and destination(s).

5.  If you wanted to get down & dirty, really low-level, you could install a permanent network tap on the port between your inside network and your outside firewall, then mirror traffic off to a permanent analyzer, from which you'd generate reports.  There are lots of tools to buy that will do this, some require port mirrors, or taps, and some can be run on your firewall.  All are built to generate the information you seek.

Remember that traffic that's passed through a proxy server or firewall may have NAT / PAT applied to the traffic, so instead of showing you the actual source address of the device requesting the traffic, you'll get an erroneous report that shows the IP address of the proxy server.

I bet other folks will offer some different selections--pick the one you like & try it out.  But only if you're authorized by your employer.  This kind of analysis can get you in deep trouble--even get you fired or involved in a law suit--if you're not authorized to perform the work. 

Once you find the source, you must be ethical about the information you've learned.  Human Resources should be involved, and perhaps your Legal Department, to ensure you are doing things by the company's policy.  You don't want to be sued by the people who end up being involved in the traffic flow--especially if the destination is sensitive or embarrassing.

Yours,

Rick S.

And NPM enable the network connection and table router this node.  after  you need configuration the end points in netflow.

see more http://www.solarwinds.com/documentation/NetFlow/docs/NetFlowAdministratorGuide.pdf

When it comes to monitoring external IP addresses packet capture would be recommended. The reason is that many services now use content delivery networks (CDN) like Amazon or Akamai. Packet analysis will let you look inside the HTTP headers. On a small scale you could use Wireshark but in a corporate environment you could look at a commercial tool like LANGuardian which can integrate with Orion.

The video below shows an example of how you can use a SPAN or mirror port to monitor Internet activity

Darragh

Looks like #4 would be the quickest and more permanent.  We do have NTA.  Could you point me to the router/switch config should be for NTA?

4.  You could start up your handy Orion Netflow Traffic Analyzer, assuming you've configured your switches and routers to forward traffic to it, and filter for the external IP address.  The cool thing about NTA is it can show you more intuitive data about the traffic, what protocols are involved, what applications are involved, as well as the source(s) and destination(s).

The Netflow configuration for your equipment will be specific to the brand(s) and model(s) you are using.  You can refer to the manufacturer's configuration guides for the best solution, or open a support case if you have a support contract with them.

In simplest Cisco terms, you must enable netflow on a per-interface basis and define flow export sources and versions.

For example, on a Nexus 7xxx router:

ip flow-export source (define the source of your interface that will send Netflow information outbound)

ip flow-export version X

ip flow-export destination (x.x.x.x--define your NTA's server IP address here)

Then enable netflow on the appropriate interfaces, using appropriate ingress or egress statements (some systems can do both, some can only do one of the two--not both, etc.). Ex:

int gix/x

ip flow ingress

On a Cisco Nexus switch your config would include Netflow statements like these:

feature netflow

flow exporter (name--that you create & assign)

destination x.x.x.x (IP address of your NTA server)

transport udp (port your vendor or NTA requires)

source (define the source interface on your Nexus switch that will send traffic to NTA)

version (pick the appropriate Netflow version that's compatible with your systems)

    template data timeout (define how many seconds before the version times out)

On a Cisco 65xx L3 switch/router:

mls netflow interface

int x/x/x

   ip flow ingress

int vlan xxxx

  ip flow ingress

You can see Netflow syntax varies by device type.  I'd love to give you exactly what you'd need to copy & paste into your gear to get this going, but you'll have to learn the correct Netflow commands for your gear and your environment.  I'm sure your vendor's online documentation covers it, and hopefully you won't need to open a support case to get it going correctly.  I'm not ashamed to admit I've used TAC and the online documentation to get my Netflow working properly.

Hoping you have excellent luck!

Rick S.