Sign in

Do I put the sensor on this inside of my private network or the outside?

For the NetWatcher™ sensor to see and understand your traffic it needs to be on the inside of your network and positioned in a location where it can see all of your internal traffic.

Specifically the sensor needs to be on the right side of the device that is doing your Network Address Translation (NAT).

You cannot use a private IP address on a network (example from graphic would be and have that device communicate with a website on the Internet (example at without doing some type of translation to convert internal addresses to external addresses.   In the graphic below the Router is doing the Network Address Translation (sometimes referred to as “Natting”).


Analogy:  In a large company mail comes to the mail room and someone in that mail room has the job of translating addresses from Joe, Large Company, some address to Office 101. To translate the address, the mail clerk looks up Joe’s office address in a table. People outside the company do not need to worry about the fact that Joe’s office is 101.  The mail clerk is doing address translation.

Network Address Translation (NAT) works on a similar principle. All your devices have internal addresses that are used, and you have one (or more) external public addresses that you can use. When an internal device talks to an external host ( for example) some device in the middle (a router for example) does a mapping between the internal and external address—This is Network Address Translation or “Natting”.   Essentially NAT results in many internal IPs being mapped to one external IP.  This has the added effect of hiding all your internal devices from the wild external world of the internet—however you should still have a firewall ("Deny all, permit by exception" policy) and a router.

More details on NAT can be found here.

So essentially we need to be able to see all the internal IP addresses (hence we need to be on the right side of the NAT).

If you did put the sensor on the outside of the firewall the number of alarms would greatly increase due to a continuous stream of scans from thousands of compromised systems.  The sheer volume of false positives and deflected/harmless attacks would be useless to try to manage.  Processing these events not only takes a lot of time, but frequently leads to overtaxed employees ignoring real security events (see the Target hack for a very public example of this problem).  To address this, we have a design philosophy that is focused on lowering the noise floor on actionable security events.  By monitoring the inside interface, we can analyze the attacks that make it through the firewall without generating alarms on the ones that the firewall is deflecting.




Powered by Zendesk