The VNS3 network sniffer is a useful tool in diagnosing many issues, such as IPSec connections that don't pass traffic, lack of connectivity to certain hosts or subnets, and routing issues.


This guide is intended to provide you with the information necessary to use the network sniffer effectively.


Syntax:


The Network Sniffer uses tcpdump filter syntax.  Interface selection is important; underlay traffic (leaving or arriving at the VNS3 controller) traverses eth0; overlay and IPSec traffic traverses tun0.  Container network traffic traverses plugin0.


Basic example filters:


host [IP address]

This filter will capture any traffic whose source or destination is the given IP address.

Example:  "host 172.31.1.1"


net [subnet CIDR]

This filter will capture any traffic whose source or destination is within the given CIDR.

Example:  "net 172.31.0.0/22"


src [IP address]

This filter captures only traffic with a source of the given IP

Example:  "src 10.0.0.50"


dst [IP address]

This filter captures only traffic with a destination of the given IP

Example:  "dst 10.0.0.50"


port [port]

This filter captures all traffic whose source or destination port is the given port.

Example:  "port 8000"


portrange [port-port]

This filter captures all traffic whose source or destination port is between the given ports.

Example:  "portrange 1024-65535"


[protocol]

This filter captures all traffic whose protocol matches the given protocol.

Example:  "udp"


Additional features:


You can use parenthesis and logical operations such as "or", "and", and "not".


A filter such as:  "(host 172.31.1.1 or host 172.31.1.2) and tcp and dst port 3389" is valid, and will capture all RDP traffic to or from hosts 172.31.1.1 or 172.31.1.2.


Example issues:


An IPSec connection does not pass traffic, but appears to be connected.  We can enter the following filter for eth0:  "host [peer endpoint IP]"


We will now see all traffic to our peer; if this connection uses NAT-T, we will see UDP4500.  If it uses native IPSec, we will see ESP.  If we see ESP in one direction and UDP4500 in the other, we know that there is a NAT-T mismatch; we need to change that setting.


If the connection is configured properly and we see all ESP or all UDP4500, we can then check connectivity to a host by starting a ping and using the filter "host [host IP] and icmp"


If we see no ping requests, we can tell our peer to check his routes.  If we see ping requests going out to our host, but no replies coming back, we can look for routing and firewall issues.  If we see requests and replies, we can tell our peer to check his firewall rules.


Additional reading and assistance:


This page offers some more examples for tcpdump; while not all of the information is applicable to VNS3, much of it is helpful.


If you have any questions or would like assistance in diagnosing a problem, please contact our support team at support@cohesive.net or open a ticket at https://support.cohesive.net/support/tickets/new