Problem finally solved.

There were 2 issues that caused the problems.

1. The first problem was a bad firewall rule that used a wrong IP. The thing
that i don't understand here is why the events sending worked. I still am
puzzled a bit about that.
In short, the firewall rules on the server allowed on INPUT connections from
192.168.x.y and not from the 172.16.a.b, both IPs being on the (former :) )
broken agent. After correcting the rule, the agent now appears as active.

2. The second problem was caused by ossec-remoted which if it runs on a
machine with 2 IPs (a LAN and a VPN tunnel interface), if it is configured
to bind to all IPs (via 0.0.0.0) it will fail to communicate with the
agents, logging errors like below:
2011/04/08 13:31:36 ossec-remoted(1218): ERROR: Unable to send message to
012.
2011/04/08 13:31:39 ossec-remoted(1218): ERROR: Unable to send message to
001.
2011/04/08 13:32:26 ossec-remoted(1218): ERROR: Unable to send message to
005.

This can be fixed by forcing the binding to only one IP via the local_ip
configuration option.

Also, it's a bit dissapointing that OSSEC can't bind to multiple IPs, only
ALL or only one.

So, the problem has been solved, thank you all for your help.

On Fri, Apr 8, 2011 at 12:58 PM, Valentin Avram <[email protected]> wrote:

> Problem solved after relaxing some firewall rules on the ossec server. It
> seems it was a problem with the ip remoted uses to send the reply packets to
> the agent. For now i added all possibilities of ip combinations, so i will
> try to find the needed once and post back here. I still believe ossec uses a
> wrong ip somewhere.
>
> I also found out that local_ip configuration entry overrides any previous
> local_ip entry, so you cant listen on 2 ips from X ips on a server.
>
>

Reply via email to