Which way? From the probe to an external consumer or from an external source to the probe, for monitoring?
Either one is solvable with iptables manipulation, on the OS level. When native drivers are used, everything that can be done in OS, can be done on the AMD.
We have cases of our Field consultants setting up AMD in AWS and feeding it with packets using GRE tunnel from another machine (firewall), using iptables configuration on both source machine and the AMD. For me this looks like something adjacent to what the question refers to.
Looking at having AMD to poll from the rpcapd running on the a server. How does the GRE tunnel work as there's not much documentation around this ? Able to share more information on such GRE tunnel deployment ?
In such case the simple way could be to use the aforementioned configuration. It is comprised of the following:
We don't have an official documentation for it, as it's a field-developed solution. It's unrelated to the AMD, it's just the linux network interfaces manipulation. Our consultants may be willing to help you.
Please note though that this solution is manageable when you have a couple of servers only. When more than a couple of servers are involved, and/or enterprise-grad security and reliability is required, a more viable and manageable solution would be to use Ixia virtual taps or CloudLens (https://www.ixiacom.com/products/cloudlens-public). It's scalable, secure and doesn't force you to manually maintain it.
I like to hook up onto this thread. We are about to start a project at a customer in an ESX environment with CloudLens vTaps, and a vPacketbroker (vPB). We intend to let the packerbroker communication to the AMD, both virtual machines. If vPB and vAMD do not reside on the same ESX host, I think a GRE tunnel between the two might be a viable option. I was under the impression that it would not ne supported. I'm interested to learn how your consultants developed their solution, maybe you can hook me up with them?