Hi Mark, This is a networking issue common to UDP, since it is stateless and the kernel decides on which interface to reply, it will generally use the main (first) interface.
For example, if I setup a virtual interface in here (host ourhome): eth0 -> 192.168.2.15 eth0:0 -> 192.168.2.77 eth0:1 -> 192.168.2.78 and test with netcat: d...@ourhome:~$ nc -l -u -p 12345 (listening on all interfaces) d...@remotebox:~$ nc -u 192.168.2.78 12345 (using the eth0:1 ip). This is what I get on tcpdump: # tcpdump -nn -i xl0 udp port 12345 tcpdump: listening on xl0, link-type EN10MB 12:15:08.654902 192.168.2.10.23783 > 192.168.2.78.12345: udp 7 12:15:11.903964 192.168.2.15.12345 > 192.168.2.10.23783: udp 7 (DF) You see that I am talking to the ip .78 and the kernel is replying using the .15 (main interface ip). That's why the client doesn't get the reply from netcat. However, if I set a local ip in there, it will work properly. So, for your case to work, you need to set <local_ip> to xxx.xxx.xxx.139 and restart the manager (and the agent after). If you do that, it will use the proper interface. But note that even if you set that and the connections comes from a different network, the kernel will redirect using the configured route. *I will also look into changing the code to try getting the dst ip of the incoming packets and use that as the source of the reply... Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Thu, Mar 19, 2009 at 12:06 PM, Mark C <[email protected]> wrote: > > Daniel, > > I am pretty sure the OSSEC server is not behaving correctly. > > I set the <local_ip> on the server to xxx.xxx.150.137 (which is the IP > attached to the physical interface. This is not what I want, but I > needed to test it). > > This is a tcpdump when the server is configured for 150.137 and the > client's IP is on a DIFFERENT network. The client's IP is xxx.xxx. > 135.169: > > 10:00:50.992638 IP xxx.xxx.135.169.32856 > xxx.xxx.150.137.1514: UDP, > length 73 > 10:00:50.993992 IP xxx.xxx.150.139.1514 > xxx.xxx.135.169.32856: UDP, > length 73 > > As you can see, even when the server is told to only use its physical > interface, it responds on the IP attached to the virtual interface. > > Here is the exact same scenerio, but from a client on the SAME network > (client IP = 150.134): > > 10:03:48.669698 IP xxx.xxx.150.134.56598 > xxx.xxx.150.137.1514: UDP, > length 73 > 10:03:48.670930 IP xxx.xxx.150.137.1514 > xxx.xxx.150.134.56598: UDP, > length 73 > On Mar 19, 8:29 am, Mark C <[email protected]> wrote: >> 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 :) >
