# Remote Packet Forwarding to Zeek Workers
**URL:** https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677
**Category:** Zeek
**Tags:** cluster, workers, pcap
**Created:** [September 6, 2022, 3:41am UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677 "2022-09-06T03:41:27Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@BrandonT](https://community.zeek.org/u/BrandonT)
#### Post date: [September 6, 2022, 3:41am UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/1 "2022-09-06T03:41:27Z")
Hi all,
I just started working with Zeek. I have been tasked with creating a way for full packet data to be pushed to our Zeek cluster for analysis and processing on a central server, but to have the agents/nodes only running a low resource binary for capturing packets.
I’ve put something together to capture the packets on the node end and receive a compressed stream on the other end, but now I’m having trouble with pushing the packet data into Zeek for processing.
I have looked into a number of things, including the now deprecated Brocolli for intercommunication as well as the event-based scripting, however, it doesn’t seem to be a viable method to watch for all the events and then process it on the manager that way.
Another option I can think of is to capture the packet data, dump it into a PCAP and then process the PCAP manually via Zeek CLI. But, I wanted to see if there’s any other way I can do this.
Thanks all!
---
### Author:  [@awelzel](https://community.zeek.org/u/awelzel)
#### Post date: [September 19, 2022, 10:44am UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/2 "2022-09-19T10:44:22Z")
Hey Brandon,
assuming you’re using Linux, have you looked into using `tc-mirred` and a tunnel protocol (VXLAN, Geneve or ERSPAN) to tunnel mirrored traffic to your Zeek cluster?
The first link provides a fairly elaborate tutorial how to do this with `tc` and `vxlan` (examples with container, however), the second mentions GRE, Geneve, ERSPAN…
https://arthurchiao.art/blog/traffic-mirror-with-tc-and-tunneling/
https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels#erspan
More concretely around Zeek, the following mentions using vxlan for container traffic forwarding (there’s some Python code for this, too):
https://corelight.com/blog/sidecars-for-network-monitoring
On the Zeek cluster side, you’d have Zeek sniff the interface receiving the mirrored traffic or sniff the tunnel interface to receive decapsulated traffic.
None of these links will readily solve what you want to do, but hopefully provide some pointers.
Arne
---
### Author:  [@Christian](https://community.zeek.org/u/Christian)
#### Post date: [September 19, 2022, 7:21pm UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/3 "2022-09-19T19:21:38Z")
Hey Brandon,
> Another option I can think of is to capture the packet data, dump it into a PCAP and then process the PCAP manually via Zeek CLI. But, I wanted to see if there’s any other way I can do this.
If you end up considering this route further, feel free to chime in on
this ticket, which mentions a couple of related higher-layer approaches:
>
>
> Implement a PCAP-over-IP client, so that packets can be read from a TCP socket a…s an alternative to reading a pcap file or sniffing an interface.
>
> PCAP-over-IP can be used to live-stream captured packets from a remote sniffer to zeek, but the most useful use-case is probably in order to read decrypted HTTPS traffic from a TLS proxy without having to replay it to a dummy network interface. There are several downsides of replaying packets to an interface, such as requiring root privs and risk of packet loss, so reading them from a TCP socket instead is preferable.
>
> It would be nice if zeek would support the \[same TCP socket interface syntax as Wireshark/tshark\](https://wiki.wireshark.org/CaptureSetup/Pipes.md#tcp-socket).
>
> \`zeek -i TCP@192.168.1.2:57012\`
>
> Or if the TCP socket could be specified with -r:
>
> \`zeek -r TCP@192.168.1.2:57012\`
>
> Another option would be to add a custom option specifically for PCAP-over-IP:
>
> \`zeek --pcapoverip 192.168.1.2:57012\`
This too won’t immediately solve your problem, but your use case would
help us understand requirements and prioritize work.
Best,
Christian
---
### Author:  [@ZekAlfon](https://community.zeek.org/u/ZekAlfon)
#### Post date: [September 21, 2022, 2:33pm UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/4 "2022-09-21T14:33:23Z")
Hí,
I for remote sensors and dump data where I have zeek, I use ssh. Don’t know if that’s what you’re looking for.
For example. From where I have zeek, I launch the following:
`ssh selks-user@192.168.1.17 -p22 'sudo -S /usr/bin/tcpdump -ieno1 -w - not port 22' | /usr/local/zeek/bin/zeek -C -r - -e 'redef LogAscii::use_json=T;' /usr/local/zeek/share/zeek/site/local.zeek -f'not host 192.168.1.228 and not host 192.168.1.209'`
---
### Author:  [@Richard\_Bejtlich](https://community.zeek.org/u/Richard_Bejtlich)
#### Post date: [September 28, 2022, 4:22pm UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/5 "2022-09-28T16:22:47Z")
What kind of performance do you get with that setup?
Sincerely,
Richard
---
### Author:  [@ZekAlfon](https://community.zeek.org/u/ZekAlfon)
#### Post date: [September 29, 2022, 7:45am UTC](https://community.zeek.org/t/remote-packet-forwarding-to-zeek-workers/6677/6 "2022-09-29T07:45:18Z")
Hí,
It’s obviously not the best way, but it’s fast to build and decent in performance for just a remote host.