I neglected to mention the IPs of the server, ovm-a

ovm-a eth0 is xxx.xxx.xxx.137

ovm-a eth0:0 is xxx.xxx.xxx.139

On Mar 18, 3:10 pm, Mark  C <[email protected]> wrote:
> Daniel,
>
> Thanks for the response!  I am humbled by the lead developer helping a
> lowly user ;)
>
> It looks like you're absolutely right.  One of my clients, named lmp-
> a, is talking to the server (named ovm-a) on the server's virtual
> interface (with the floating IP).  However, the server is replying
> from the physical interface.
>
> I thought one easy fix would be specifying both of the server's IPs as
> <server>s in the client's ossec.conf file, so that the OSSEC client
> will not drop replies coming from the server's physical interface.
>
> Anyways, here's the data:
>
> r...@ovm-a:~$ netstat -uanep
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address
> State       User       Inode       PID/Program name
> udp        0      0 127.0.0.1:161
> 0.0.0.0:*                           0          12347       4948/
> snmpd
> udp        0      0 0.0.0.0:57150
> 0.0.0.0:*                           0          10699       4079/
> rpc.statd
> udp        0      0 0.0.0.0:24278
> 0.0.0.0:*                           0          12348       4948/
> snmpd
> udp        0      0 0.0.0.0:863
> 0.0.0.0:*                           0          10691       4079/
> rpc.statd
> udp        0      0 0.0.0.0:1514
> 0.0.0.0:*                           0          75080074    1905/ossec-
> remoted
> udp        0      0 0.0.0.0:111
> 0.0.0.0:*                           0          10657       4063/
> portmap
> udp        0      0 0.0.0.0:40566
> 0.0.0.0:*                           33         75265071    24577/php
>
> r...@ovm-a:~$ route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref
> Use Iface
> xxx.xxx.xxx.0    0.0.0.0         255.255.255.0   U     0      0
> 0 eth0
> 0.0.0.0         xxx.xxx.xxx.2    0.0.0.0         UG    100    0
> 0 eth0
> 0.0.0.0         xxx.xxx.xxx.2    0.0.0.0         UG    100    0
> 0 eth0
>
> r...@ovm-a:~$ /var/ossec/bin/manage_agents -a
> Choose your action: A,E,L,R or Q: l
> ...
> Available agents:
>    ID: 001, Name: lmp-b, IP: xxx.xxx.xxx.134
>    ID: 002, Name: lmp-a, IP: xxx.xxx.xxx.133
>
> r...@ovm-a:~$ /var/ossec/bin/list_agents -a
> lmp-b-xxx.xxx.xxx.134 is available.
>
> r...@ovm-a:~$ /var/ossec/bin/list_agents -c
> lmp-b-xxx.xxx.xxx.134 is active.
>
> =============lmp-a - does NOT connect
>
> r...@lmp-a:~/tcpdump-a$ grep server /var/ossec/etc/ossec.conf
>     <server-ip>xxx.xxx.xxx.139</server-ip>
>
> r...@lmp-a:~/tcpdump-a$ less /var/log/ossec.log
> 2009/03/18 14:52:35 ossec-agentd(4101): WARN: Waiting for server reply
> (not started). Tried: 'xxx.xxx.xxx.139'.
> 2009/03/18 14:53:15 ossec-agentd: INFO: Trying to connect to server
> (xxx.xxx.xxx.139:1514).
>
> r...@lmp-a:~/tcpdump-a$ grep 1514 lmp-a.tcpdump
> 15:22:22.984876 IP xxx.xxx.xxx.133.48171 > xxx.xxx.xxx.139.1514: UDP,
> length 73
> 15:22:22.985747 IP xxx.xxx.xxx.137.1514 > xxx.xxx.xxx.133.48171: UDP,
> length 73
>
> =============lmp-b - DOES connect
>
> r...@lmp-b:~/tcpdump-b$ grep server /var/ossec/etc/ossec.conf
>     <server-ip>xxx.xxx.xxx.137</server-ip>
>
> r...@lmp-b:~/tcpdump-b$ less /var/log/ossec.log
> 2009/03/18 14:34:34 ossec-agentd: INFO: Trying to connect to server
> (xxx.xxx.xxx.137:1514).
> 2009/03/18 14:34:35 ossec-agentd(4102): INFO: Connected to the server
> (xxx.xxx.xxx.137:1514).
>
> r...@lmp-b:~/tcpdump-b$ grep 1514 lmp-b.tcpdump
> 15:03:53.837915 IP xxx.xxx.xxx.134.55838 > xxx.xxx.xxx.137.1514: UDP,
> length 73
> 15:03:53.838970 IP xxx.xxx.xxx.137.1514 > xxx.xxx.xxx.134.55838: UDP,
> length 73
>
> On Mar 18, 12:02 pm, Daniel Cid <[email protected]> wrote:
>
> > Hi Mark,
>
> > If you don't specify a local_ip in the config, it will bind to all the
> > interfaces. What I am thinking
> > is that you are having a routing issue, where ip A is receiving the
> > events from the agent, but
> > with a route configure to reply with ip B. Can you run tcpdump on both
> > ends (and netstat -uanep) to
> > see what is going on?
>
> > Thanks,
>
> > --
> > Daniel B. Cid
> > dcid ( at ) ossec.net
>
> > On Tue, Mar 17, 2009 at 10:46 AM, Mark  C <[email protected]> wrote:
>
> > > The <local_ip> I was trying was the IP attached to the eth0:0
> > > interface.  And yes, I restarted both the server and clients.
>
> > > I just tried entering 0.0.0.0.  When starting ossec:
>
> > > 2009/03/17 08:43:45 ossec-config(1237): ERROR: Invalid ip address:
> > > '0.0.0.0'.
> > > 2009/03/17 08:43:45 ossec-config(1202): ERROR: Configuration error at
> > > '/var/ossec/etc/ossec.conf'. Exiting.
> > > 2009/03/17 08:43:45 ossec-remoted(1202): ERROR: Configuration error at
> > > '/var/ossec/etc/ossec.conf'. Exiting.
>
> > > I found someone else having a similar problem:
> > >http://groups.google.com/group/ossec-list/browse_thread/thread/3cc339...
>
> > > It sounds like Daniel Cid, a developer, I presume, was going to take a
> > > look at this in Oct 2007 (v1.5) but this is still a problem.  For some
> > > reason, it looks like ossec is not looking at the incoming DST IP from
> > > the clients and using that as the SRC IP when responding.
>
> > > I am sure my situation of using a floating IP is quite common - can
> > > anyone say that they've used virtual interfaces successfully, first
> > > hand?
>
> > > On Mar 16, 7:42 pm, Christopher <[email protected]> wrote:
> > >> What IP did you specify with that option?  I would assume setting 0.0.0.0
> > >> would allow OSSEC to listen on any IP address.  You are restarting the
> > >> server after you make these changes, right?
>
> > >> On Mon, Mar 16, 2009 at 3:40 PM, Mark C <[email protected]> wrote:
>
> > >> > Oh, I tried the <local_ip> option specified here:
> > >> >http://www.ossec.net/main/manual/configuration-options/#remote_options
>
> > >> >  <remote>
> > >> >    <connection>syslog</connection>
> > >> >    <local_ip>xxx.xxx.xxx.xxx</local_ip>
> > >> >  </remote>
>
> > >> > And it did not work even after restarting.
>
> > >> > On Mar 16, 2:54 pm, Mark  C <[email protected]> wrote:
> > >> > > Hi all,
>
> > >> > > I've just installed OSSEC 2 on an Ubuntu 6.06 server 32bit system.
> > >> > > It's part of a simple cluster where there's a floating IP, eth0:0.  I
> > >> > > setup 2 agents, and during the initial setup gave them the floating
> > >> > > IP.  Here's what both saw in the logs:
>
> > >> > > 2009/03/16 14:42:11 ossec-agentd(4101): WARN: Waiting for server 
> > >> > > reply
> > >> > > (not started). Tried: 'xxx.xxx.xxx.xxx'.
> > >> > > 2009/03/16 14:42:33 ossec-agentd: INFO: Trying to connect to server
> > >> > > (xxx.xxx.xxx.xxx:1514).
>
> > >> > > I restarted the server and agents several times.
>
> > >> > > Then on one of the agents, I changed the server IP in /var/ossec/etc/
> > >> > > ossec.conf.  I restarted the agent and when I ran /var/ossec/bin/
> > >> > > list_agents -c on the server, I saw that it was connectd.
>
> > >> > > I've searched for any file on the server that might let me specify
> > >> > > what IP or interface to listen on but I can't find anything.
> > >> > > Connectivity to the virtual interface, aside from OSSEC, works 
> > >> > > without
> > >> > > any problems whatsoever.
>
> > >> > > The server and clients are on the same subnet.  There are no 
> > >> > > firewalls
> > >> > > involved.
>
> > >> > > I'm sure I'm missing something very simple :)

Reply via email to