I'm not sure whether this is possible at all but i've decided to ask.
Does anyone know/tested a scenario where the Shared IP and the MGT IP's are in a different VLANs/Subnets.
Any ideas appreciated as i'm stuck and i don't really know whether it will work even if i could find a way to configure it.
I have a productive environment, where the HA RCV pair has a "log collector" interface (this is the shared IP) and an "internal SIEM management" interface in a different subnet.
It works well, but not so easy to implement.
First of all: cabling:
The first interface (eth0) must be the management and (eth1) can be the SharedIP.
Is it a new installation?
If yes, please upgrade all of the components to the latest hotfix BEFORE making HA.
Thanks for the reply, i've already configured it actually 2 days ago.
the strange thing is the it worked well on the 1st pair but on the second it's failing with different error messages.
I've ended puting all interface in the same zone and afterwards i've tried to change the IP's but then the ESM is not Updating correctly the ssh Keys for the receivers.
I'm not sure but maybe i've encountered a problem with the receiver as it just doesn't want to work.
will try couple more things tomorrow and maybe i'll end up with McAfee support as this is quite annoying already.
which version is it?
I had the same issue, but the problem of inserting the correct key to the known_hosts file is a known bug of 9.4, but it is resolved in HF7.
And also a documented bug: "Multiple HA pairs on the same network have the same MAC address." also repaired in the up to date release.
I had similar issues in the past so my first step is always to upgrade to the latest and greatest version.
Currently it's 188.8.131.5241112 i believe.
The error was some thing similar to : Could not update interface settings on device.
Could you please check, if the correct key is in the known_hosts file?
My workaround was: during the configuration i tried to ssh to the 2nd receiver with the following switch:
ssh <receiverIP> -o StrictHostKeyChecking=no
and log out (ctrl D) and ssh again.
As fast as I can.
i need to check tomorrow,
But i've checked today and it was missing if i'm not wrong there was onely 1 key for the primary receive MGT IP.
i'll try to disable it and see how it goes.
But is that going to disable the key check for the host or ?
As I understood, it is a problem of the HA config generator script.
During the configuration the receiver's key is deleted from known_host. ... but who knows why?...
And after the deletion, ESM can't connect to the 2nd receiver.
You can check is easily: during the configuration try to ssh from the ESM to the 2nd receiver without this option.
After the initial keying process you are able to ssh to this host with the password you defined in the keying process via GUI.
Log out and ssh again. Again and again. Keep trying, and after a while you can't login, because the key removed from known_hosts.
The ssh command wit this option inserts the receiver's public key to the known_host file, if it is not already in.
This option affects only the actual session, it is NOT a general setting.
If you are lucky, you are faster than the timeout defined in the retry of the communication process...
Well today i had to open a case with McAfee as it consumed a lot of time already but they never did such a setup so i have to submit HA_info.sh output.
i believe that this HA is not meant to be used in different VLANs.
Will see what will happen with the support ticket.
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center