Wireshark Remote Packet Capture: rpcapd and SSH Pipe (2026)

rpcapd is failing to connect to the remote server.

The core issue is that the rpcapd daemon, which is responsible for capturing packets on a remote machine, isn’t able to establish a reliable network connection back to your local Wireshark instance. This can stem from a variety of network configuration problems, firewall rules, or even issues with the rpcapd service itself.

Common Causes and Fixes

1. rpcapd Service Not Running or Crashing

   • Diagnosis: On the remote server, check the status of the rpcapd service.

     sudo systemctl status rpcapd
     

     If it’s not active, try starting it:

     sudo systemctl start rpcapd
     

     Check the logs for rpcapd for any specific error messages.

     sudo journalctl -u rpcapd -f
     

   • Fix: Ensure the rpcapd service is enabled to start on boot and is currently running.

     sudo systemctl enable rpcapd
     sudo systemctl start rpcapd
     

     This ensures the packet capture daemon is available and ready to accept connections.

2. Firewall Blocking rpcap Port (2002)

   • Diagnosis: The default port for rpcapd is 2002. Check if this port is open on the remote server’s firewall.
     • ufw (Ubuntu/Debian):

       sudo ufw status
       

     • firewalld (CentOS/RHEL/Fedora):

       sudo firewall-cmd --list-all
       

   • Fix: Open port 2002 for TCP traffic on the remote server’s firewall.
     • ufw:

       sudo ufw allow 2002/tcp
       sudo ufw reload
       

     • firewalld:

       sudo firewall-cmd --permanent --add-port=2002/tcp
       sudo firewall-cmd --reload
       

     This allows Wireshark on your local machine to initiate a connection to the rpcapd service on the remote server.

3. Incorrect rpcapd Configuration (e.g., Binding to Wrong Interface)

   • Diagnosis: rpcapd might be configured to listen on a specific IP address that isn’t accessible from your local machine. Check the rpcapd.conf file (often located at /etc/rpcapd.conf or /usr/local/etc/rpcapd.conf). Look for a bind directive.
   • Fix: Ensure rpcapd is configured to bind to 0.0.0.0 or the specific IP address of the network interface that is reachable from your local machine. If the line is commented out or set to a specific IP, change it.

     # Example from rpcapd.conf
     bind = 0.0.0.0
     

     After modifying the configuration file, restart the rpcapd service.

     sudo systemctl restart rpcapd
     

     Binding to 0.0.0.0 makes rpcapd listen on all available network interfaces, increasing the chances it will be accessible from your client.

4. Network Address Translation (NAT) or Routing Issues

   • Diagnosis: If the remote server is behind a NAT device (like a router), your local machine might not be able to directly reach its IP address. Check your local machine’s routing table (route -n) and the remote server’s network configuration (ip a).
   • Fix: Ensure that there are appropriate routes configured or that port forwarding is set up on the NAT device to direct traffic on port 2002 from your external IP to the remote server’s internal IP. This is highly environment-specific and might involve configuring your router. If you are using the SSH pipe method, this is less of a direct concern for rpcapd itself but more for the SSH tunnel.

5. SSH Tunnel Configuration Errors (if using SSH pipe)

   • Diagnosis: If you’re piping rpcapd through SSH, verify the SSH command itself. Ensure the remote port (2002) is correctly forwarded to a local port.

     # Example SSH command
     ssh -L 2002:localhost:2002 user@remote_server_ip "rpcapd -l 127.0.0.1"
     

     Check if the SSH connection is active and if there are any errors in the SSH client’s output.
   • Fix: Correct the SSH command to ensure the local port is correctly mapped to the remote rpcapd port. The command above forwards local port 2002 to remote port 2002. Ensure rpcapd on the remote server is listening on localhost (127.0.0.1) when using this method.

     # On remote server, if rpcapd is not already running, start it like this:
     rpcapd -l 127.0.0.1
     

     This establishes a secure channel where Wireshark connects to your local port 2002, which is then securely forwarded to the rpcapd service running on the remote server’s loopback interface.

6. Incorrect rpcapd Command-line Arguments

   • Diagnosis: The rpcapd daemon needs to be started with appropriate arguments, especially when used with SSH tunnels. If you’re running it manually, check the arguments.
   • Fix: When using an SSH tunnel, it’s common to have rpcapd listen only on the loopback interface (127.0.0.1) on the remote server to receive traffic from the SSH tunnel.

     rpcapd -l 127.0.0.1
     

     If rpcapd is configured to bind to 0.0.0.0 in its config file and you’re using SSH, you might get a "bind address already in use" error if another process is using port 2002. Binding explicitly to 127.0.0.1 when using an SSH tunnel isolates it to only accept connections from the tunnel.

After resolving these, you might encounter issues with Wireshark’s interface not showing the remote capture device. This is usually resolved by restarting Wireshark or refreshing the remote capture interface list.