vSec/CloudGuard R80.10 failing to handle multiple vmnet3 interfaces?
First question ever, so be gentle
I have an issue with the vSec R80.10 firewall running as a traditional VM in vmware environment (no AWS/Azure here). If I use only the default 4x vmnet3 interfaces from the OVA, all works fine, but as I start adding more vmnet3 interfaces up to the maximum (of vmware) of 10, definitelly some of them fail to work. In "ethtool ethX" you will get that the ehternet speed negotiation failed and they are not sending/recieving packets.
This is weird as if I replace them with the much older E1000 interfaces, everything works fine. But these are much slower in production deployment.
Any ideas ? I found some openbsd kernel bug reports of something similar happening to certain freebsd kernels from this year, nothing for linux kernels but at least a minor pointer that this might be related the the gaia linux baseline ?
I tried on two separate ESX boxes, but both 6.5 as we are using this one everywhere. Anyone else double-checking for me before I go bother support would be welcomed.
Can't really speak with authority on why this could be the case, but I may suggest a temporary workaround:
Define built-in interfaces as trunks and create multiple subinterfaces under those.
Since single VMXNET3 interface is treated as 10G, so long as you are not looking to exceed it, you are good for 10 subinterfaces.
Incidentally, I am running number of VMs with more than 4 VMXNET3s on ESXi 6.0.0 Update 3 (Build 9239799) with no issues. Guest OS Red Hat Enterprise Linux 6 (64-bit), Compatibility ESX/ESXi 4.0 and later (VM version 7).
So this may be something specific to the 6.5 or VM version.
That is an obvious workaround, but this is a private cloud environment where we have to automate everything. And vmware has a nice API for everything, including adding/removing NICs to a VM that we are using already in the cloud orchestration engine that wants to spawn these virtual checkpoints. And Checkpoint APIs for automating trunks is lets say.... questionable as I haven't yet seen any of the new R80 REST API calls for something like this.