Hi, This issue has been solved so far by fixing the policy-route, Linux created by default veryy stange policies that were missing the /28 networks completely, instead going to 127.0.0.4 via 127.0.0.1/8 network, they went via tab 2 route 127.2.0.1/8 via eth1 because of missing /28 link scope routes on tab 1 (!).
Thanks ddp+Daniel+mceith for debugging help :) On 29 heinä, 17:12, Daniel Cid <[email protected]> wrote: > Hi Jani, > > Can you paste the client.keys file from both the manager and the agent > added via authd? If both are > set with the "any" IP address, you wouldn't be getting this error. > > Also, is there any error in the agent side? That error also happens if > an IP not allowed tries to send the > events via syslog.. Could that be the case? > > Thanks, > > > > > > > > On Fri, Jul 29, 2011 at 10:55 AM, Jani Karlsson <[email protected]> wrote: > > Hi, > > > I re-added them via manage_agents using IPs and restarted manager's > > process, now both seem to be working ok, but still I get rejected > > message from authd added agents. > > Is this a bug in authd or ? > > > I can provide more details via IRC/private email if you need > > something. > > > On 29 heinä, 16:50, "dan (ddp)" <[email protected]> wrote: > >> On Fri, Jul 29, 2011 at 9:30 AM, Jani Karlsson <[email protected]> wrote: > >> > Hi, > > >> > I have restarted both agents and manager's processes several times > >> > over, the reason I want to use authd with prod is that it has way more > >> > servers then dev, > >> > so using manage_agents to do manually each agent is very labour- > >> > intensive. > > >> Understood. I was thinking we could try and troubleshoot the problem. > >> If manage_agents worked for the 2 I suggested trying, you could look > >> for differences between those 2 and the rest. It looked like you > >> exposed the keys already anyways, so you'd want to re-add them to get > >> new keys. > >> Or you could try re-adding the key to an agent or two. > > >> You could have also provided some of the manager's ossec.conf. Like > >> the remote section. > > >> You could check the agent's ossec.log for corresponding errors. > > >> > On 29 heinä, 16:24, "dan (ddp)" <[email protected]> wrote: > >> >> Have you restarted the manager's ossec processes since adding an agent? > >> >> Try removing the agents whose keys were exposed, and re-add them with > >> >> manage_agents. > > >> >> On Fri, Jul 29, 2011 at 7:34 AM, Jani Karlsson <[email protected]> wrote: > >> >> > Hi, > > >> >> > I got 2 environments, prod and dev, both running virtualized RHEL5. > >> >> > I installed agents to dev using manage_agents command but for prod I > >> >> > used the new authd-tool. > > >> >> > I am seeing weird problem in my prod environment where I registered > >> >> > those agents with authd, > >> >> > when I start ossec-remoted manually with debug I am getting: > > >> >> > 2011/07/29 14:20:49 ossec-remoted(1213): WARN: Message from x.x.x.x > >> >> > not allowed. > > >> >> > on dev everything is working ok but no matter what I put to allowed- > >> >> > ips list, prod's remoted just rejects these messages from clients. > > >> >> > server's client-keys: > > >> >> > 1034 memcache.prod.com any > >> >> > e6b246fb352621e15399e4925ac199025a5bb9e769bf8165b3918d7b6dadb171 > >> >> > 1035 www1.prod.com any > >> >> > 2451d8ba59a0f5e80d477820c1464dcbdf3d9bfade0a0f4a82922367d98e9ef1 > > >> >> > etc. those both match exactly to client's client.keys, only different > >> >> > from env to prod where things are working is that agents were > >> >> > registered with IPs and using manage_agents and prod was used authd- > >> >> > tool. Can anyone help with this weirdness? > > >> j
